Dissecting QNX

Jos Wetzels1,2,3 , Ali Abbasi3,4

1
Midnight Blue
2
Eindhoven University of Technology (TU/e)
3
University of Twente (UT)
4
Ruhr-University Bochum (RUB)

T
his work concerns a dissection of QNX: a pro- addition, it is deployed in highly sensitive embedded
prietary, real-time operating system aimed systems such as industrial automation PLCs, medical
at the embedded market. QNX is used in devices, building management systems, railway
many sensitive and critical devices in different in- safety equipment, Unmanned Aerial Vehicles (UAVs),
dustry verticals and while some prior security re- anti-tank weapons guidance systems, the Harris
search has discussed QNX, mainly as a byproduct Falcon III military radios, Caterpillar mining control
of BlackBerry mobile research, there is no prior systems, General Electric turbine control systems and
work on QNX exploit mitigations and secure ran- Westinghouse and AECL nuclear powerplants.
dom number generators. In this work, carried out
as part of the master’s thesis of the first author, we The interest of high-profile actors in QNX-based
present the first reverse-engineering and analysis systems is evidenced by a series of documents from
of the exploit mitigations, secure random number the United States Central Intelligence Agency (CIA)
generators and memory management internals of obtained and released by WikiLeaks under the name
QNX versions up to and including QNX 6.6 and the ’Vault 7’. These documents show an interest on part
brand new 64-bit QNX 7.0 released in March 2017. of the CIA’s Embedded Development Branch (EDB) of
We uncover a variety of design issues and vulnera- the Engineering Development Group (EDG) (which
bilities which have significant implications for the develops and tests exploits and malware used in covert
exploitability of memory corruption vulnerabilities operations) in targeting QNX [65].
on QNX as well as the strength of its cryptographic
ecosystem. In this work, we focus primarily on QNX’s ’binary
security’ ie. its hardening against memory corruption
exploitation, as well as the quality of its secure random
1 Introduction number generators.
More precisely, this work makes the following novel
QNX [17] is a proprietary, closed-source, Unix-like contributions:
real-time operating system with POSIX support aimed
primarily at the embedded market. Initially released
in 1982 for the Intel 8088 and later acquired by • It presents the first reverse-engineering of the
BlackBerry, it forms the basis of BlackBerry OS, proprietary, closed-source QNX OS to document
BlackBerry Tablet OS and BlackBerry 10 used in the internals of its memory manager, exploit
mobile devices as well as forming the basis of Cisco’s mitigations (eg. NX memory, ASLR, stack canaries,
IOS-XR used in carrier-grade routers such as the RELRO) and secure random number generators
CRS, the 12000 and the ASR9000 series. QNX also (both the kernel PRNG and /dev/random),
dominates the automotive market [61] (particularly covering all QNX versions as of writing (ie. ≤ 6.6
telematics, infotainment and navigation systems) and and the newly released QNX 7.0).
is found in millions of cars from Audi, Toyota, BMW,
Porsche, Honda and Ford to Jaguar and Lincoln. In • It presents the first analysis of the exploit
 Dissecting QNX

mitigations and secure RNGs on QNX ≤ 6.6 and for hundreds of POSIX utilities, common networking
7.0 and uncovers a variety of design issues and technologies (IPv4/IPv6, IPSec, FTP, HTTP, SSH,
vulnerabilities which have significant implications etc.) and dynamic libraries. As opposed to the
for the exploitability of memory corruption monolithic kernel architecture of most general-purpose
vulnerabilities on QNX as well as the strength of OSes, QNX features a microkernel which provides
its cryptographic ecosystem. minimal services (eg. system call and interrupt
handling, task scheduling, IPC message-passing, etc.)
• As a result of this work, we disclosed the un- to the rest of the operating system which runs as
covered issues to the vendor and cooperated in a team of cooperating processes as illustrated in
drafting patches to help protect system end-users. Figure 1. As a result, only the microkernel resides
in kernelspace with the rest of the operating system
and other typical kernel-level functionality (drivers,
Given that there is, as discussed in Section 2.1, protocol stacks, etc.) residing in userspace next to
no prior work on QNX’s mitigations, secure ran- regular user applications albeit separated by privilege
dom number generators or memory management boundaries. In QNX the microkernel is combined with
internals, we consider this work a significant con- the process manager in a single executable module
tribution to the state of the art in understanding called procnto. QNX libc converts POSIX function
QNX security as well as QNX OS internals more broadly. calls into message handling functions which pass
messages through the microkernel to the relevant pro-
In Section 2 we present an brief overview of QNX’s cess. As of writing, the latest QNX release is version 7.0.
OS architecture, its security architecture and its mem-
ory management internals. We discuss the result of our
reverse-engineering and analysis of the exploit mitiga-
tions of QNX versions up to and including 6.6 in Section Process
M anager
PS File
M anager H FS File
U DF File
M anager
N FS File
M anager Flash File
M anager
3 and those of QNX version 7.0 in Section 4. In Section
M anager
Q N X N eutrino
5 we present the results of our reverse-engineering and M icrokernel

analysis of the secure random number generators of

Software Bus

QNX versions ≤ 6.6 and 7.0. Finally, in Section 6 we

Character
present our concluding remarks.
N etwork
GU I M anager M queue CI FS File M anager
M anager M anager Application M anager
Application

2 QNX Overview Figure 1: QNX Microkernel Architecture [60]

2.1 Security History

Most elements of the QNX system architecture (such
Most of the relatively scarce public research available as the messaging layer, process & resource manage-
on QNX security has been the byproduct of research ment, filesystem and networking functionality, etc.)
into BlackBerry’s QNX-based mobile operating systems are well described in prior work [42] and since this
such as Tablet OS, BlackBerry OS and BlackBerry work focuses on memory corruption we will only dis-
10 [3, 13–15, 66] most of which has not focussed on cuss QNX memory management and the security ar-
QNX itself. Recent work by Plaskett et al. [1, 42] has chitecture in ’broad strokes’.
focussed on QNX itself, particularly security of the Inter-
Process Communication (IPC), message passing and
Persistent Publish Subscribe (PPS) interfaces as well 2.3 Security Architecture
as kernel security through system call fuzzing. When As a Unix-like operating system QNX inherits a large
it comes to specific vulnerabilities the work done by part of the Unix security model, primarily in the
Julio Cesar Fort [27] and Tim Brown [19] stands out in form of user groups and associated permission-based
particular and the MITRE CVE database [25] reports, access controls. QNX is certified to Common Criteria
as of writing, 34 vulnerabilities most of which are setuid ISO/IEC 15408 Evaluation Assurance Level (EAL) 4+.
logic bugs or memory corruption vulnerabilities. The certification report [21] indicates that the Target
of Evaluation (TOE) boundary encompasses only the
2.2 OS Architecture procnto system process (ie. the microkernel and
process manager) and libc.
QNX supports a wide range of CPU architectures
and features a pre-emptible microkernel architec- QNX features a strong separation between kernel-
ture with multi-core support ensuring virtually any and userspace running everything except for the
component (even core OS components and drivers) microkernel and process manager in kernelspace
can fail without bringing down the kernel. QNX by assigning it to the procnto process which runs
itself has a small footprint but support is available as root with PID 1. Other OS components run as

Page 2 of 22
 Dissecting QNX

their own root processes in userspace next to non-OS U ser Process 1 U ser Process 2 U ser Process 3 System Process
processes. Separation between OS processes and
non-OS processes comes down to a combination procnto
of enforcement of user permissions and additional
sandboxing capabilities [54]. If a non-OS process
is run as root, the only way to wall it off from the 0 3.5G 0 3.5G 0 3.5G 3.5G 4G
wider OS is by restricting its capabilities. On the other
hand, capabilities can be assigned on a granular level Figure 2: QNX Private Virtual Memory [53]
allowing or disallowing access to system actions and
resources meaning for many processes there is no need
to run as root to perform their functionality. Security
separation between userspace and kernelspace is
also mediated in this fashion which does mean, Architecture Start End
however, that there is no ’absolute isolation’ of the Userspace
microkernel and a root user without significant x86 0x00000000 0xBFFFFFFF
capability restrictions (as is the default for most OS AArch32 0x00000000 0x7FFFFFFF
processes) can easily pivot into the microkernel by MIPS 0x00000000 0x7FFFFFFF
means of common kernel calls, access to sensitive PPC 0x40000000 0xFFFB0000
devices (eg. /dev/mem) or installation of Interrupt SuperH 0x00000000 0x7BFF0000
Service Routines (ISRs). Kernelspace
x86 0xC0000000 0xFFFFFFFF
As such one should not confuse the safety guarantee AArch32 0x80000000 0xFFFFFFFF
that the crashing of one component does not lead to MIPS 0x80000000 0xFFFFFFFF
a crash of the entire system with a security guarantee PPC 0x00000000 0x3FFFFFFF
that the compromise of one component could not lead SuperH 0x80000000 0xCFFFFFFF
to the compromise of the entire system. If no explicit
capability restrictions are put in place by system inte- Table 1: QNX ≤ 6.6 Address Boundaries
grators, nothing prevents a compromise of a process
with the right privileges or capabilities from leading to
arbitrary kernelspace code execution. Architecture Start End
Userspace
x86 0x00000000 0xBFFFFFFF
2.4 Memory Management x86-64 0x00000000 0x0000007FFFFFFFFF
QNX offers a full-protection memory model placing AArch32 0x00000000 0x7FFFFFFF
each process within its own private virtual memory by AArch64 0x00000000 0x0000007FFFFFFFFF
utilizing the MMU as shown in Figure 2. On QNX every Kernelspace
process is created with at least one main thread (with x86 0xC0000000 0xFFFFFFFF
its own, OS-supplied stack) and any subsequently x86-64 0x0000008000000000 0xFFFFFFFFFFFFFFFF
created thread can either be given a customly allocated AArch32 0x80000000 0xFFFFFFFF
stack by the program or a (default) system-allocated AArch64 0x0000008000000000 0xFFFFFFFFFFFFFFFF
stack for that thread. QNX’s virtual memory provides
permission capabilities and the memory manager Table 2: QNX 7.0 Address Boundaries
ensures inter-process memory access is mediated
by privilege as well as capability checks [54]. QNX
handles typical memory objects such as stacks, the Architecture Libc Addr.
heap, object memory (eg. video card memory mapped QNX ≤ 6.6
into userspace), shared libraries, etc. and has support x86 0xB0300000
for shared- and typed memory [57, 59]. The relevant AArch32 0x01000000
memory manager internals are described in detail in MIPS 0x70300000
Section 3.2. PPC 0xFE300000
SuperH 0x70300000
For QNX versions up to and including 7.0, we illus- QNX 7.0
trate QNX user- and kernel-space address boundaries, x86 0xB0300000
derived from reverse-engineering, in Tables 1 and 2. x86-64 0x0000000100000000
On QNX systems where ASLR is not enabled, libc AArch32 0x01000000
is loaded by default at the addresses illustrated in AArch64 0x0000000100000000
Table 3. For QNX versions up to and including 6.6
on x86, the default user- and kernel-space layouts Table 3: QNX Default Libc Load Addresses
when ASLR is disabled are illustrated in Figures 3 and 4

Page 3 of 22
 Dissecting QNX

0xBFFFFFFF generator as they are implemented in QNX versions up

(...)
to and including 6.6. QNX supports a variety of exploit
shared libraries mitigations as outlined in Table 4 and the compiler-
0xB0300000 and linker parts of these mitigations rely on the fact
(...) that the QNX Compile Command (QCC) uses GCC as its
shared objects back-end [16]. On the operating system side of things,
0x40100000 however, the mitigation implementations are heavily
(...) customized as we will see in this section.
heap
We can also see from Table 4 that while basic mitiga-
(...) tions (ESP, ASLR, SSP, RELRO) are supported, this is
.bss not the case for more modern ones (eg. CFI, Kernel
.data Data & Code Isolation, etc.) which are becoming
.text
program image the norm in general purpose operating systems such as
0x08048000 Windows or Linux. While some of these mitigations
thread stack 1 (eg. CFI, CPI, Vtable Protection) are mostly imple-
mented in the compiler and several libraries, it is cur-
(...)
rently not clear to what degree they are (in)compatible
thread stack n with QNX’s design.

(...) Mitigation Support Since Default

system ESP X 6.3.2 ×
0x00000000
ASLR X 6.5 ×
SSP X 6.5 ×1
Figure 3: QNX ≤ 6.6 Userspace Memory Layout (x86) RELRO X 6.5 ×1
NULL-deref Protection × n/a n/a
Vtable Protection × n/a n/a
0xFFFFFFFF
(...) CFI × n/a n/a
L1 pagetable
CPI × n/a n/a
map to self Kernel Data Isolation2 × n/a n/a
0xFFC00000
Kernel Code Isolation3 × n/a n/a
syspage, GDT ,
FPU stub, etc.
0xFF400000 Table 4: QNX ≤ 6.6 Exploit Mitigation Overview
1
Startup Default QNX Momentics IDE Settings, 2 eg. UDEREF / SMAP
allocations 0xFEC00000 / PAN, 3 eg. KERNEXEC / SMEP / PXN

normal kernel
mapping OR We disclosed all discovered issues to the vendor and
4m pagetable as a result fixes and improvements based on our sug-
for kernel code gestions were included in QNX 7.0 as documented in
& data
0xF0000000 Section ??.
first 256M of
phys. mem
0xE0000000 3.1 Executable Space Protection
normal kernel
mapping Executable Space Protection (ESP), also referred
0xD0400000 to as Data Execution Prevention (DEP), NX memory
temp. map to
zero L2 or WˆX memory, is a mitigation that seeks to prevent
pagetables 0xD0000000 attackers from executing arbitrary injected payloads
through a Harvard-style code and data memory
message pass
temp. map separation on Von Neumann processors by rendering
0xC0000000
data memory non-executable and ensuring code
memory is non-writable. ESP can be implemented by
Figure 4: QNX ≤ 6.6 Kernelspace Memory Layout (x86) either relying on hardware support (eg. the x86 NX
bit or ARM XN bit) or by means of software emulation.
QNX has support for hardware-facilitated ESP among
3 QNX ≤ 6.6 Exploit Mitigations most of the architectures which support it since version
6.3.2 as shown in Table 5.
In this section we will present the results of our
reverse-engineering and subsequent analysis of Insecure ESP Default Policy (CVE-2017-XXXX):
QNX’s exploit mitigations and secure random number While QNX supports ESP for several architectures, its

Page 4 of 22
 Dissecting QNX

Architecture Support memory objects (eg. code, stack, heap, etc.) and
x86 X(requires PAE on IA-32e) rendering them hard to guess.
ARM X
MIPS × QNX has ASLR support since version 6.5 (not
PPC 400 X supported for QNX Neutrino RTOS Safe Kernel 1.0)
PPC 600 X but it’s disabled by default. QNX ASLR can be enabled
PPC 900 X on a system-wide basis by starting the procnto
microkernel with the -mr option [55] and disabled
Table 5: QNX ≤ 6.6 Hardware ESP Support with the -m∼r option. A QNX child process normally
inherits its parent’s ASLR setting but as of QNX 6.6
ASLR can also be enabled or disabled on a per-process
implementation is dangerously weakened due to inse- basis by using the on utility [51] (with the -ae and -ad
cure default settings. As a result, the stack (but not the options respectively). Alternatively, one can use the
heap) is always executable regardless of the presence SPAWN_ASLR_INVERT or POSIX_SPAWN_ASLR_INVERT
of hardware ESP support. As the documentation [55] flags with the spawn and posix_spawn process
states, the QNX microkernel, and process manager exe- spawning calls. To determine whether or not a process
cutable (procnto) has a memory management startup is using ASLR, one can use the DCMD_PROC_INFO [49]
option relating to stack executability (available as of command with the devctl [50] device control call
QNX 6.4.0 or later): and test for the _NTO_PF_ASLR bit in the flags member
of the procfs_info structure.
• -mx: (Default) Enable the PROT_EXEC flag for
system-allocated threads (the default). This As shown in Table 6, QNX ASLR randomizes the base
option allows gcc to generate code on the stack - addresses of userspace and kernelspace stack, heap
which it does when taking the address of a nested and mmap’ed addresses as well as those of userspace
function (a GCC extension). shared objects (eg. loaded libraries) and the executable
image (if the binary is compiled with PIE [16]). It does
• -m˜x: Turn off PROT_EXEC for system-allocated not, however, have so-called KASLR support in order
stacks, which increases security but disallows tak- to randomize the kernel image base address. The QNX
ing the address of nested functions. You can Momentics Tool Suite development environment (as
still do this on a case-by-case basis by doing an of version 5.0.1, SDP 6.6) does not have PIE enabled
mprotect() call that turns on PROT_EXEC for the by default and indeed after an evaluation with a
required stacks. customized version of the checksec [34] utility we
found that none of the system binaries (eg. those in
Since the first option is the default, any QNX system
/bin, /boot, /sbin directories) are PIE binaries in a
which starts procnto without explicit -m˜x settings
default installation.
will have an executable stack, regardless of hardware
ESP support or individual binary GNU_STACK [35] set-
tings. The rationale behind this decision seems to have Memory Object Randomized
been a desire for backwards compatibility with binaries Userspace
which require executable stacks which has caused sim- Stack X
ilar issues on Linux in the past [33]. This backwards Heap X
compatibility is enforced on a system-wide (rather than Executable Image X
on an opt-out, per-binary basis) as confirmed by the Shared Objects X
fact that the QNX program loader does not parse the mmap X
GNU_STACK header of binaries. The problem with the Kernelspace
QNX approach here is that this setting is applied on a Stack X
system-wide basis and has an insecure default, putting Heap X
the secure configuration burden on system integrators. Kernel Image ×
mmap X
3.2 Address Space Layout Randomiza-
Table 6: QNX ≤ 6.6 ASLR Memory Object Randomization Sup-
tion port
When developing exploits, attackers rely on knowledge
of the target application’s memory map for directing We reverse-engineered QNX’s ASLR implementation
write and read operations as well as crafting code-reuse (as illustrated in Figure 5) and found that it is
payloads. Address Space Layout Randomization ultimately implemented in two function residing in
(ASLR) [31] is a technique which seeks to break the microkernel: stack_randomize and map_find_va
this assumption by ensuring memory layout secrecy (called as part of mmap calls). QNX uses the Executable
via randomization of addresses belonging to various and Linking Format (ELF) binary format and pro-

Page 5 of 22
 Dissecting QNX

cesses are loaded from a filesystem using the exec*,

posix_spawn or spawn calls which invoke the program
loader implemented in the microkernel. If the ELF Listing 1: QNX 6.6 vmm_mmap Routine
binary in question is compiled with PIE-support, the i n t vmm_mmap(PROCESS * prp , u i n t p t r _ t
program loader will randomize the program image vaddr_requested , s i z e _ t size_requested ,
base address as part of an mmap call. When a loaded i n t prot , i n t f l a g s , OBJECT * obp ,
program was linked against a shared object, or a u i n t 6 4 _ t b o f f , unsigned
shared object is requested for loading dynamically, alignval ,
the runtime linker (contained in libc) will load it unsigned preload , i n t fd , void **
into memory using a series of mmap calls. A stack is vaddrp , s i z e _ t * s i z e p ,
p a r t _ i d _ t mpart_id )
allocated automatically for the main thread (which
{
involves an allocation of stack space using mmap)
...
and has its base address (further) randomized by a
call to stack_randomize. Whenever a new thread create_flags = flags ;
is spawned, a dedicated stack is either allocated
(and managed) by the program itself or (by default) ...
allocated and managed by the system in a similar
fashion. Userspace and kernelspace heap memory i f ( prp−>f l a g s & _NTO_PF_ASLR )
allocation, done using functions such as malloc, c r e a t e _ f l a g s |= MAP_SPARE1 ;
realloc and free, ultimately relies on mmap as well.
In kernelspace, a dedicated stack is allocated for each r = map_create ( . . . , c r e a t e _ f l a g s ) ;
}
processor using a call to _scalloc and thus relies on
mmap. As such, all ASLR randomization can be reduced
to analysis of stack_randomize and map_find_va: Listing 2: QNX 6.6 map_create Routine
i n t map_create ( s t r u c t map_set * ms , s t r u c t
U serspace ASLR
map_set * r e p l , s t r u c t mm_map_head *mh,
u i n t p t r _ t va , u i n t p t r _ t s i z e ,
u i n t p t r _ t mask , unsigned f l a g s )
program image
loader_load main stack heap
base
loader_load
{
...
T hreadT LS thread stack(s) shared object elf_load
image base

i f ( f l a g s & ( MAP_FIXED|IMAP_GLOBAL) ) {
thread_specret dlopen
...
} else {
stack_randomize _heap_alloc load_object
r e p l −> f i r s t = NULL ;
memmgr.mmap
va = map_find_va (mh, va , s i z e ,
mask , f l a g s ) ;
vmm_map init_objects
i f ( va == VA_INVALID ) {
r = ENOMEM;
ClockCycles map_find_va kernel heap kernel stack(s)
goto f a i l 1 ;
}
Kernelspace
ASLR }

Figure 5: QNX ≤ 6.6 ASLR Memory Object Graph ...

}
map_find_va: As shown in Listings 1, 2 and
3, the QNX memory manager’s vmm_mmap handler
function invokes map_create and passes a dedicated Listing 3: QNX 6.6 map_find_va Routine
mapping flag (identified only as MAP_SPARE1 in older u i n t p t r _ t map_find_va ( s t r u c t mm_map_head *
QNX documentation) if the ASLR process flag is mh, u i n t p t r _ t va , u i n t p t r _ t s i z e ,
set. map_create then invokes map_find_va with u i n t p t r _ t mask , unsigned f l a g s )
these same flags, which randomizes the found virtual {
address with a randomization value obtained from the
sz_val = s i z e − 1;
lower 32 bits of the result of the ClockCycles [46]
kernel call. This 32-bit randomization value is then ...
bitwise left-shifted by 12 bits and bitwise and-masked
with 24 bits resulting in a value with a mask form of i f ( f l a g s & MAP_SPARE1 )
0x00FFF000, ie. a randomization value with at most {
12 bits of entropy. uint64_t clk_val = ClockCycles () ;

Page 6 of 22
 Dissecting QNX

unsigned i n t r n d _ v a l = ( (_DWORD) unsigned i n t size_mask ;

c l k _ v a l << 12) & 0xFFFFFF ;
rnd_sp = new_sp ;
i f ( f l a g s & MAP_BELOW )
{ i f ( thp−>p r o c e s s −>f l a g s &
start_distance = start − _NTO_PF_ASLR )
best_start ; {
i f ( s t a r t != b e s t _ s t a r t ) s t a c k _ s i z e = thp−>un . l c l . s t a c k s i z e
{ >> 4 ;
i f ( rnd_val > if ( stack_size )
start_distance ) {
r n d _ v a l %= size_mask = 0x7FF ;
start_distance ; i f ( s t a c k _ s i z e <= 0x7FE )
s t a r t −= r n d _ v a l ; do { size_mask >>= 1 ; }
} while ( size_mask >
} stack_size ) ;
else
{ rnd_sp = ( new_sp − ( (
end_distance = best_end − C l o c k C y c l e s ( ) << 4) &
sz_val − start ; size_mask ) ) & 0xFFFFFFF0 ;
i f ( b e s t _ e n d − s z _ v a l != }
start ) }
{ return rnd_sp ;
i f ( rnd_val > }
end_distance )
r n d _ v a l %= Weak ASLR Randomization (CVE-2017-3892):
end_distance ; As observed above, the randomization underlying
s t a r t += r n d _ v a l ; mmap has a theoretical upper limit of 12 bits of
} entropy and the additional randomization applied to
}
userspace stacks introduces at most 7 bits of entropy,
}
combining into at most 19 bits of entropy with a
stack_randomize: Userspace processes have a main mask of form 0x00FFF7F0. Addresses with such
stack and a dedicated stack for each subsequently low amounts of entropy can be easily bruteforced
spawned thread. The main stack is allocated by the (especially locally) and while ASLR on 32-bit systems
program loader using an mmap call and subsequently is generally considered inherently limited [7] one
has its start address randomized by stack_randomize should remember that these are upper bounds, ie. they
called as part of a ThreadTLS call. Dedicated thread express the maximum possible introduced entropy.
stacks are spawned by the thread_specret routine Given that these upper bounds already compare
which allocates them with an mmap call (invoked as part rather unfavorably against the measurements of
of a call to procmgr_stack_alloc) and subsequently actual ASLR entropy in eg. Linux 4.5.0, PaX 3.14.21
randomizes their start address with stack_randomize. and ASLR-NG 4.5.0 as per [7], this does not bode well.
This function, as shown in reverse-engineered form
in Listing 4, checks whether a process has the ASLR All QNX ASLR randomization draws upon Clock-
flag set and if so it generates a sizemask (between Cycles as the sole source of entropy. The QNX
0x000 and 0x7FF). A randomization value is drawn ClockCycles [46] kernel call returns the current
from the lower 32 bits of the result of a ClockCycles value of a free-running 64-bit cycle counter using a
kernel call which are then bitwise left-shifted by 4 different implementation per architecture as outlined
bits and have the sizemask applied to them. The in Table 7. Even though QNX’s usage of ClockCycles
resulting value is subtracted from the original stack seems to provide 32 bits of ’randomness’, it is an
pointer value and bitwise and-masked with 28 bits. ill-advised source of entropy due to its inherent
This results of a randomization value with a mask regularity, non-secrecy, and predictability.
form of 0x000007F0, ie. an upper limit of 7 bits of
entropy for the maximum value of size_mask = 0x7FF.
Architecture Implementation
x86 RDTSC
Listing 4: QNX 6.6 stack_randomize Routine ARM Emulation
MIPS Count Register
u i n t p t r _ t s t a c k _ r a n d o m i z e ( const THREAD *
const thp , u i n t p t r _ t new_sp ) PPC Time Base Facility
{ SuperH Timer Unit (TMU)
u i n t p t r _ t rnd_sp ;
size_t stack_size ; Table 7: QNX ClockCycles Implementations

Page 7 of 22
 Dissecting QNX

In order to demonstrate this, we evaluated the value is not considered secret and in fact it leaks ev-
entropic quality of QNX ASLR randomized addresses erywhere (both to local users as well as via network
of several userspace memory objects. We did this with services). As a result, an attacker in posession of the
a script starting 3000 ASLR-enabled PIE processes per current clock cycle counter value could reconstruct the
boot session and running 10 boot sessions, collecting clock cycle counter value (in a fashion analogous to the
30000 samples per memory object in total. We used work in [36]) at the time of memory object random-
the NIST SP800-90B [41] Entropy Source Testing (EST) ization. Given the current clock cycle counter value
tool [38] in order to evaluate the entropic quality and an estimate on memory object initialization times,
of the address samples by means of a min entropy an attacker can deduce the clock cycle counter value
estimate, illustrated in Table 8. Min entropy is a at randomization time for a given memory object and
conservative way of measuring the (un)predictability reconstruct it as:
of a random variable X and expresses the number of
(nearly) uniform bits contained in X , with 256 bits of
uniformly random data corresponding to 256 bits of clockt = clockc − ((timec − timet ) ∗ cycless )
min entropy.
where clockt , clockc , timet and timec are the target
and current clock cycle counter and timestamp values
Memory Object Min Entropy (8 bits per symbol) and cycless is the number of cycle increments per
Stack 1.59986 second.
Heap 1.00914
Executable Image 0.956793 procfs Infoleak (CVE-2017-3892): The proc
Shared Objects 0.905646 filesystem (procfs) is a pseudo-filesystem on Unix-
like operating systems that contains information
Table 8: QNX 6.6 ASLR Userspace Memory Object Min Entropy
about running processes and other system aspects
via a hierarchical file-like structure. This exposure
From Table 8 we can see that, on average, a QNX of process information often includes ASLR-sensitive
randomized userspace memory object has a min information (eg. memory layout maps, individual
entropy of 1.11785975. This means that it has a little pointers, etc.) and as such has a history as a source for
more than 1 bit of min entropy per 8 bits of data. If we local ASLR infoleaks [12, 44, 62] with both GrSecurity
extrapolate this to the full 32 bits of a given address and mainline Linux [26, 64] seeking to address
this means that the stack, heap, executable image procfs as an infoleak source. On QNX procfs [48]
and shared object base addresses have min entropy is implemented by the process manager component
values of 6.39944, 4.03656, 3.827172 and 3.622584 of procnto and provides the following elements for
respectively, with an average of 4.471439 bits of min each running process:
entropy. This compares very unfavorably with the
entropy measurements for various Linux-oriented
ASLR mechanisms in [7]. • cmdline: Process command-line arguments.
• exefile: Executable path.
On QNX, as is the case with many operating systems, • as: The virtual address space of the target process
child processes inherit the memory layout of parent mapped as a pseudo-file.
processes. As a result when attacking forked or
pre-forked applications an attacker can guess an ASLR These procfs entries can be interacted with like files
address, after which the target child crashes and is and subsequently manipulated using the devctl [50]
restarted with an identical memory layout allowing API to operate on a file-descriptor resulting from
the attacker to make another guess and so on. This opening a procfs PID entry. Since process entries
facilitates both brute-force attacks and malicious child in QNX’s procfs are world-readable by default, this
processes attacking siblings in Android Zygote-style means a wide range of devctl-based information
models [23]. Given this memory layout inheritance, retrieval about any process is available to users
the fact that QNX ASLR provides only limited entropy regardless of privilege boundaries. For example, the
and has no active relocation (ie. memory object QNX pidin [52] utility, which makes use of procfs
locations are never re-randomized), QNX ASLR is to provide a wide range of process inspection and
highly susceptible to brute-force attacks. debugging options, easily allows any user to obtain
stackframe backtraces, full memory mappings and
Finally it should be noted that ClockCycles is not program states for any process. This effectively
a secure random number generator and by drawing di- constitutes a system-wide local information leak
rectly from its output the clock cycle counter value acts allowing attackers to circumvent ASLR. It should be
analogous to a random number generator’s internal noted this issue is not due to the availability of any
state. Contrary to a secure random number genera- particular utility (such as pidin) but rather results
tor’s internal state, however, the clock cycle counter from a fundamental lack of privilege enforcement on

Page 8 of 22
 Dissecting QNX

procfs. failure handler.

LD_DEBUG Infoleak (CVE-2017-9369): The QNX’s QCC implements the GCC SSP scheme [43]
LD_DEBUG [37] environment variable is used on some and supports all the usual SSP flags (strong, all, etc.).
Unix-like systems to instruct the dynamic linker to Since the compiler-side of the QNX SSP implementa-
output debug information during execution. On tion is identical to the regular GCC implementation,
QNX there are no cross-privilege restrictions on this the master canary is stored accordingly and canary
environment variable, leading to a (local) information violation invokes the __stack_chk_fail handler.
leak that can be used to circumvent ASLR. Since there
are no privilege checks (akin to the ’secure-execution Insecure User Canary Generation (CVE-2017-
mode’ [63] offered by some Linux distributions) on XXXX): For userspace applications, this handler is
this environment variable, a local attacker can execute implemented in QNX’s libc. On the OS-side, reverse-
setuid binaries with higher privileges using dynamic engineering of libc shows us that violation handler
linker debugging settings (eg. LD_DEBUG=all) in (shown in cleaned-up form in Listing 5) is a wrapper
order to output sensitive information (eg. memory for a custom function called _ssp_fail which writes
layout, pointers, etc.). This issue is similar to CVE- an alert message to the /dev/tty device and raises
2004-1453 [22] affecting certain versions of GNU glibc. a SIGABRT signal. QNX generates its master canary
value once upon program startup (during loading of
ASLR Correlation Attack (CVE-2017-3892): libc) and it is not renewed at any time. Instead of the
ASLR randomization of memory object base addresses regular libssp function __guard_setup, QNX uses a
can prove to be insufficient if different memory objects custom function called __init_cookies (shown in
are correlated. In such a case an attacker in the Listing 6) invoked by the _init_libc routine in order
posession of one address can determine the location to (among other things) generate the master canary
of others by means of applying a static (or minimally value.
varying) offset, rendering even the most limited
information leaks very powerful.
Listing 5: QNX 6.6 Stack Canary Failure Handler (Userspace)
During our evaluation we found a partial correla- void _ _ s t a c k _ c h k _ f a i l ( void )
tion attack on QNX’s ASLR implementation, affecting {
both PIE and non-PIE binaries. The offset from the pro- i f ( ( f d = open ( " / dev / t t y " , 1) ) != −1)
gram image base to the base address of the first loaded w r i t e ( fd , " *** s t a c k smashing
shared library (libc) is of the mask form 0x00FFF000 d e t e c t e d *** " ) ;
with at most 12 bits being randomized. We evaluated r a i s e ( SIGABRT ) ;
the entropic quality of this offset value in order to deter- }
mine the feasibility of correlation attacks by collecting
300 offset samples per boot session and running 10 Listing 6: QNX 6.6 Userspace Canary Generation
boot sessions, making for 3000 samples total. Using
void _ i n i t _ c o o k i e s ( void )
the NIST Entropy Source Testing (EST) tool [38] we
{
determined the min entropy of these offset values to
void * s t a c k v a l ;
be 0.918311, making for less than 1 bit of min entropy
per 8 bits of data, which corresponds to 1.3774665 ts0 = ( ClockCycles () & 0 x f f f f f f f f ) ;
bits of min entropy for the 12 affected variable bits can0 = ( t s 0 ^ (((& s t a c k v a l ) ^ (
in the offset. Given that this is well below an exhaus- _ i n i t _ c o o k i e s ) ) >> 8) ) ;
tive search, this makes a variation of the offset2lib [6] _ s t a c k _ c h k _ g u a r d = can0 ;
attack feasible.
ts1 = ( ClockCycles () & 0 x f f f f f f f f ) ;
can1 = (((& s t a c k v a l ) ^ can0 ) >> 8) ;
3.3 Stack Smashing Protector _ a t e x i t _ l i s t _ c o o k i e = ( can1 ^ t s 1 ) ;
Stack Smashing Protector (SSP) [43] is a so-called
ts2 = ( ClockCycles () & 0 x f f f f f f f f ) ;
stack canary scheme which seeks to prevent the _ a t q e x i t _ l i s t _ c o o k i e = ( can1 ^ t s 2 ) ;
exploitation of stack buffer overflows by inserting
a secret and unpredictably random canary value in _ s t a c k _ c h k _ g u a r d &= 0 x f f 0 0 f f f f ;
between the local stack variables and the stackframe }
metadata (eg. saved return address, saved frame
pointer). Any attempt at stack smashing which seeks As shown in Listing 6, QNX canaries have a
to overwrite such metadata also ends up corrupting terminator-style NULL-byte in the middle and are
the canary value which is, upon function return, generated using a custom randomization routine
compared against the original master value so that (slightly resembling the "poor man’s randomization
when a mismatch is detected the SSP will invoke a patch" included in some Linux distributions for

Page 9 of 22
 Dissecting QNX

performance purposes [28, 29]) rather than drawing it Settings Min Entropy (8 bits per symbol)
from a secure random number generator. The custom No ASLR 1.94739
randomization routine draws upon three sources: ASLR, no PIE 1.94756
ASLR + PIE 1.94741

• _init_cookies: This is the function’s own address Table 9: QNX 6.6 Stack Canary Min Entropy
and as such, the only randomization it introduces
is derived from ASLR’s effect on shared library
On top of entropy issues, ClockCycles is not a
base addresses which means that if ASLR is
secure random number generator, as we discussed
disabled (or circumvented) this is a static value.
before with ASLR, and as such similar reconstruction
attacks could be mounted against QNX canaries.
• stackval: This is an offset to the current stack
pointer and as such, the only randomization it
Absent Kernel Canary Generation (CVE-2017-
introduces is derived from ASLR’s effect on the
XXXX): When it comes to kernelspace stack canary
stack base which means that if ASLR is disabled
protection, the QNX microkernel (in the form of the
(or circumvented) this is simply a static value.
procnto process) also features an SSP implemen-
tation covering a subset of its functions. Since the
• ClockCycles: The lower 32 bits of the result of
kernel neither loads nor is linked against libc (and
a ClockCycles() call are used to construct the
canary violations need to be handled differently), SSP
master canary value.
functionality is implemented in a custom fashion here.
Reverse-engineering of the microkernel showed that it
Since it includes a terminator-style NULL-byte, the
has a custom __stack_chk_fail handler (illustrated
QNX master canary value has a theoretical upper limit
in Listing 7) but no master canary initialization routine.
of 24 bits of entropy. However, all entropy in QNX
As a result, QNX never actually initializes the kernel
stack canaries is ultimately based on invocations of
master canary value and hence its value is completely
the ClockCycles kernel call. If ASLR is enabled,
static and known to the attacker (0x00000000),
the stackval address gets randomized when the
rendering QNX kernel stack canary protection trivial
main thread is spawned during program startup and
to bypass.
the _init_cookies address gets randomized when
libc gets loaded by the runtime linker. The ts0
value is generated when _init_cookies is called by Listing 7: QNX 6.6 Stack Canary Failure Handler (Ker-
_init_libc which is invoked upon application startup nelspace)
(but after libc is loaded). void _ _ s t a c k _ c h k _ f a i l ( void )
{
The first problem with using ClockCycles as a k p r i n t f ( " *** s t a c k smashing d e t e c t e d
source of randomness is the limited entropy provided i n p r o c n t o *** " ) ;
and thus the degree to which the canary is unpre- __asm{ i n t 0x22 } ;
dictable and the size of the search space. In order }
to evaluate the entropic quality of QNX’s canary
generation mechanism, we collected canary values
for three different process configurations: No ASLR, 3.4 Relocation Read-Only
ASLR but no PIE and ASLR with PIE. We used a
script starting 785 instances of each configuration per QNX supports Relocation Read-Only (RELRO), a
boot session and repeated this for 10 boot sessions, mitigation that allows for marking relocation sections
collecting 7850 samples per configuration in total. as read-only after they have been resolved in order to
We then used the NIST Entropy Source Testing (EST) prevent attackers from using memory corruption flaws
tool [38] in order to obtain min entropy estimates to modify relocation-related information (such as Pro-
for the sample sets as illustrated in Table 9. Based cedure Linkage Table (PLT) related Global Offset
on these observations we can conclude that a) QNX Table (GOT) entries using GOT-overwriting [20]).
canary entropy is far less than the hypothetical upper RELRO comes in two variants: partial and full, with
bound of 24 bits, being on average 7.78981332 bits for the former protecting non-PLT entries and the latter
a 32-bit canary value and b) ASLR plays no significant protecting the entire GOT. RELRO is implemented
contributing role to the overall QNX canary entropy. partially in the toolchain and partially in the operating
system.
Due to the absence of any canary renewal func-
tionality [5], regular as well as byte-for-byte [67] In most RELRO implementations, the compiler first
brute-force attacks are feasible against QNX, especially stores constants requiring dynamic relocation in a
considering the low entropic quality of the canaries. dedicated section (typically named .data.rel.ro)
before the linker creates a PT_GNU_RELRO program

Page 10 of 22
 Dissecting QNX

segment (itself enclosed in a PT_LOAD segment) to

cover the sections in question. For full RELRO the
linker also emits the BIND_NOW flag. On the operating
system side of the implementation the dynamic linker
will, upon encountering a PT_GNU_RELRO segment,
mark the relevant pages as read-only after dynamic
relocation. If the BIND_NOW flag is specified all
relocations are applied immediately upon program
startup. A proper RELRO implementation requires at
least the following: Figure 6: Debian Linux RELRO Example

• A linker which reorders relocation sections so

that they are grouped together, properly aligned
for memory permission marking and precede the
program data sections.

• A linker which emits a GNU_RELRO segment

covering all relocation sections as well as (for full
RELRO) a BIND_NOW flag.
Figure 7: QNX 6.6 RELRO Example
• A dynamic linker which parses a binary for the
GNU_RELRO segment and upon encountering it
linker. QNX has a custom debugging option dubbed ’im-
properly marks contained sections as read-only
poster’ which, among other things, disables RELRO.
after applying relocations as well as immediately
Since there are no privilege checks on this debug set-
applying all relocations upon encountering a
ting, a low-privileged user could leverage it to target
BIND_NOW flag.
setuid binaries belonging to higher-privileged users in
order to bypass any RELRO protections and thus ease
• Any disabling of RELRO functionality should be
exploitation.
mediated by privilege checks.

We uncovered the following issues violating the

above: 4 QNX 7.0 Exploit Mitigations
Broken RELRO (CVE-2017-3893): The QNX 7, released in January 2017, is the successor to
GNU_RELRO segment emitted by QNX’s QCC QNX 6.6 and comes with support for 64-bit architec-
linker only covers relocation up until the .data section tures such as ARM v8 or Intel x86-64. It comes with
but mistakenly the section order is not properly a host of new security features such as secure boot,
adjusted so that internal data sections (eg. .got) integrity measurement, mandatory access control,
precede program data sections (eg. .data). As a host-based anomaly detection, granular sandboxing
result, the most security-critical relocation section (the and secure software updates.
PLT-related elements of the GOT) are not included
in the GNU_RELRO segment and are thus not made In this section we will document the results of our
read-only after relocation. reverse-engineering and analysis of QNX 7.0’s exploit
mitigations and secure random number generators and
For example, on Debian Linux a full RELRO binary the degree to which they differ from and improve upon
will look as pictured in figure 6. There we can see their predecessors in QNX 6.6 and earlier. Table 10
the GNU_RELRO segment covers the area from provides an overview of QNX 7.0’s exploit mitigations
0x08049ed8 to 0x0804a000 which includes .got. and their default settings.
On QNX, however, the same full RELRO binary
looks as pictured in figure 7. There we can see 4.1 Executable Space Protection
the GNU_RELRO segment covers the area from
0x08049f2c to 0x804a000 which does not include Despite our disclosure of the insecure default settings,
.got and thus allows us to violate RELRO with eg. a it turns out they have not been fixed in QNX 7 and
GOT-overwriting attack. as such, the stack (but not the heap) is executable
by default. In order to enable non-executable stacks
Local RELRO Bypass (CVE-2017-3893): On Unix- system integrators have to start procnto with the
like systems the LD_DEBUG environment variable -m˜x flag. Unfortunately there is no way to guarantee
is used to pass debugging settings to the dynamic per-binary backwards compatibility in this case as the

Page 11 of 22
 Dissecting QNX

Mitigation Support Default The ASLR randomization underlying calls to mmap

ESP X × is now being handled by the kerext_valloc and
ASLR X × vm_region_create functions as part of a rewritten
SSP X X1 memory manager. As shown in Listings 9 and 10 in
RELRO X X1 both cases all entropy is drawn from random_value.
NULL-deref Protection × n/a In the former case the full 32 bits of entropy could be
Vtable Protection × n/a absorbed on a 64-bit system while in the latter case
CFI × n/a the bitmasking imposes a theoretical upper limit of 12
CPI × n/a bits.
Kernel Data Isolation2 × n/a
Kernel Code Isolation3 × n/a
Listing 9: QNX 7 kerext_valloc Snippet
Table 10: QNX 7 Exploit Mitigation Overview void k e r e x t _ v a l l o c ( void * data )
1
Default QNX Momentics IDE Settings, 2 eg. UDEREF / SMAP {
/ PAN, 3 eg. KERNEXEC / SMEP / PXN ...

i f ( s i z e _ v a l != obj−>s i z e )
GNU_STACK ELF header is not parsed. {
randomized_addr = ( obj−>addr + (
random_value ( ) << 12) % ( obj−>
4.2 Address Space Layout Randomiza- size − size_val )) & 0
tion xFFFFFFFFFFFFF000 ;
}
QNX 7 ASLR remains disabled by default and does
not provide KASLR support for kernel image base ...
randomization. }

ASLR Randomization: As shown in Listing 8, QNX

7’s stack_randomize routine remains identical to Listing 10: QNX 7 vm_region_create Snippet
that of QNX 6.6 save for replacing ClockCycles as signed _ _ f a s t c a l l v m _ r e g i o n _ c r e a t e (
the entropy source with random_value. However, the vm_aspace_t * as , vm_mmap_attr_t * a t t r )
issue of the entropy being theoretically limited to an {
upper bound of 7 bits as a result of the application of ...
the bitmasking remains.
r n d _ v a l = ( random_value ( ) << 12) & 0
xFFF000 ;
start_distance = start − best_start ;
Listing 8: QNX 7 stack_randomize Routine
i f ( s t a r t != b e s t _ s t a r t )
u i n t p t r _ t s t a c k _ r a n d o m i z e ( const THREAD * {
const thp , u i n t p t r _ t new_sp ) i f ( s t a r t _ d i s t a n c e < rnd_val )
{ r n d _ v a l %= s t a r t _ d i s t a n c e ;
u i n t p t r _ t rnd_sp ; s t a r t −= r n d _ v a l ;
size_t stack_size ; }
unsigned i n t size_mask ;
...
rnd_sp = new_sp ; }
s t a c k _ s i z e = thp−>un . l c l . s t a c k s i z e >> 4 ;
if ( stack_size ) Curiously, however, QNX 7’s memory manager
{ restricts initial randomized mapping of userspace
si ze _ma sk = 0x7FF ; stack, heap and executable image objects to the lower
i f ( s t a c k _ s i z e <= 0x7FE ) 32 bits of the address space while restricting shared
{ libraries to the lower 36 bits.
do
si ze _mask >>= 1 ;
while ( s t a c k _ s i z e < size_mask ) ;
Information Leaks: While the LD_DEBUG Infoleak
} (CVE-2017-9369) has been fixed in QNX 7, the
procfs Infoleak (CVE-2017-3892) is still very much
rnd_sp = ( new_sp − ( ( random_value ( ) << present with only some restrictions imposed on
4 & size_mask ) ) & 0 it. In QNX 7 procfs has been slightly modified so
xFFFFFFFFFFFFFFF0 ; that interaction with processes now goes through
} the /proc/*/ctl pseudo-file. While the /proc/*
return rnd_sp ; directories have stronger permission settings and the
} pidin tool no longer allows for direct disclosure of

Page 12 of 22
 Dissecting QNX

sensitive address information from higher-privileged c0 = _ _ r d t s c ( ) ^ ( ( ( unsigned _ _ i n t 6 4 )

processes, /proc/*/ctl remains world-readable for _ i n i t _ c o o k i e s ^ ( unsigned _ _ i n t 6 4 )&
all process entries and accessible to the devctl API. As s t a c k v a l ) >> 8) ^ a u x i l _ v a l ;
such, a local attacker is still able to disclose sensitive _ s t a c k _ c h k _ g u a r d = ( void * ) c0 ;
address information across privilege boundaries. c1 = ( ( unsigned _ _ i n t 6 4 )&s t a c k v a l ^ c0 )
>> 8 ;
While capability-based sandboxing might limit the
_ a t e x i t _ l i s t _ c o o k i e = ( void * ) ( c1 ^
exposure of certain processes this is not configured to __rdtsc () ) ;
be the case by default. BYTE_OFFSET_6 ( _ s t a c k _ c h k _ g u a r d ) = 0 ;
_ a t q e x i t _ l i s t _ c o o k i e = ( void * ) ( c1 ^
We have left correlation attack evaluation for QNX 7 __rdtsc () ) ;
to future work. }

Upon reverse-engineering the loader_load routine

4.3 Stack Smashing Protector in the QNX microkernel as shown in Listing 12 we can
SSP is enabled by default in QNX Momentics 7.0.0 and see AT_RANDOM is filled with a concatenation of two
generates 64-bit canaries on 64-bit systems. 32-bit values drawn from the random_value kernel
PRNG (discussed below in Section 5.2).
Userspace Canary Generation: The new
_init_cookies routine in QNX 7 is shown in
Listing 11 where we can see that _stack_chk_guard Listing 12: QNX 7 AT_RANDOM Generation
is formed by the XOR sum of rdtsc, the code address a u x i l _ p o i n t e r −>a _ t y p e = AT_RANDOM;
of _init_cookies, the stack address of stackval a u x i l _ p o i n t e r −>a_un . a _ v a l = ( unsigned
and the value stored in auxil_val. This approach is i n t ) random_value ( ) ;
similar to the one in QNX 6.6 save for the introduction i f ( interp_name [ 7] & 8 )
of auxil_val which is a 64-bit value drawn from {
the AT_RANDOM ELF auxiliary vector entry. ELF a u x i l _ p o i n t e r −>a_un . a _ v a l |=
auxiliary vectors [30] are a mechanism to transfer OS random_value ( ) << 32;
information to user processes via the program loader. ...
}
This approach was integrated into QNX 7.0 based on
our suggestions to the vendor.
Kernelspace Canary Generation: The absent ker-
nelspace canary generation vulnerability affecting QNX
Listing 11: QNX 7 Userspace Canary Generation 6.6 and prior has been fixed in QNX 7. During early
void _ i n i t _ c o o k i e s ( ) boot in kernel_main, prior to kernel kickoff, the ker-
{ nelspace master canary is drawn from a concatena-
auxv_t * a u x i l ; tion of two 32-bit random values drawn from the
int auxil_type ; random_value kernel PRNG as shown in Listing 13.
__int64 a u x i l _ v a l ;
unsigned _ _ i n t 6 4 c0 ;
unsigned _ _ i n t 6 4 c1 ; Listing 13: QNX 7 Kernelspace Canary Generation
char s t a c k v a l ; c a l l i n _ i n i t () ;
mdriver_check ( ) ;
a u x i l = auxv ; * (_DWORD * )&i n k e r n e l = 0xD00 ;
a u x i l _ t y p e = a u x i l −>a _ t y p e ; c0 = random_value ( ) ;
i f ( auxil_type ) c1 = random_value ( ) ;
{ _ s t a c k _ c h k _ g u a r d = ( void * ) ( ( c1 << 32)
while ( a u x i l _ t y p e != AT_RANDOM ) | c0 ) ;
{ k e r _ e x i t _ k i c k o f f ( p e r c p u _ p t r−>data .
++a u x i l ; ker_stack ) ;
a u x i l _ t y p e = a u x i l −>a _ t y p e ;
i f ( ! a u x i l −>a _ t y p e )
goto END_AUXV ;
}
a u x i l _ v a l = a u x i l −>a_un . a _ v a l ;
}
4.4 Relocation Read-Only
else
{ The RELRO vulnerability we reported has been fixed in
END_AUXV : QNX 7 with QCC observing proper ELF section order-
a u x i l _ v a l = 0LL ; ing and full RELRO being enabled by default in QNX
} Momentics 7.0.0.

Page 13 of 22
 Dissecting QNX

5 QNX Secure Random Number security mechanisms.

Generators • No Blockcipher Applied To Output: As opposed
to Yarrow-160, Yarrow 0.8.71 does not apply a
5.1 /dev/random in QNX ≤ 6.6 block cipher (eg. in CTR mode) to the Yarrow
Many mitigations require a source of secure random- internal state before producing PRNG output and
ness and ideally this is provided by the operating instead simply outputs the internal state directly
system itself. As such, the security of the OS random which results in a significantly weaker design than
number generator is of crucial importance to the that of Yarrow-160.
security of exploit mitigations as well as the overall In addition, the QNX Yarrow implementation di-
cryptographic ecosystem. As prior work has shown [2, verges from Yarrow 0.8.71 as well in the following
4, 9, 10], embedded random number generation aspects:
suffers from a variety of issues with far-reaching
consequences and as such we reverse-engineered and • Mixes PRNG Output Into Entropy Pool: As part
analyzed the QNX OS random number generator. of its various entropy collection routines, QNX
Yarrow mixes PRNG output back into the entropy
QNX provides an Operating System Cryptographically pool. For example in the high performance
Secure Random Number Generator (OS CSPRNG) counter entropy collection routine (as per the
exposed through the Unix-style /dev/random and snippet in Listing 14) we can see PRNG output is
/dev/urandom interfaces, both of which are non- drawn from QNX Yarrow, used as part of a delay
blocking in practice. The OS CSPRNG is implemented routine and subsequently mixed (via a xor opera-
as the random service [56] which runs as a userspace tion with the result of a ClockCycles call) back
process started by the /etc/rc.d/startup.sh script. into the entropy pool. This construction deviates
On QNX versions up to and including 6.6 the CSPRNG from all Yarrow designs and is ill-advised in the
underlying the random service is based on the absence of further security analysis or justification.
Yarrow CSPRNG [8] (which is also used by iOS, Mac
OS X, AIX and some BSD descendants) rather than its
recommended successor Fortuna [11]. Listing 14: QNX Yarrow HPC Entropy Collection Snippet
i f ( Yarrow )
{
R andom Bits
Boottime Entropy
Collection
yarrow_output ( Yarrow , ( u i n t 8 _ t * )&
r da t a , s i z e o f ( r d a t a ) ) ;
R untime Entropy yarrow_output PR N G State yarrow_create
t i m e o u t = ( r d a t a & 0x3FF ) + 10;
}
Collection

yarrow_input yarrow_do_sha1 yarrow_make_new_state

delay ( timeout ) ;
clk = ClockCycles () ;
Entropy Pool
clk = clk ^ rdata ;

Figure 8: Simplified QNX 6.6 Yarrow Design i f ( Yarrow )

y a r r o w _ i n p u t ( Yarrow , ( u i n t 8 _ t * )&
clk , sizeof ( c l k ) , pool_id , 8
The QNX Yarrow implementation (as illustrated );
in Figure 8), however, is not based on the refer-
ence Yarrow-160 [8] design but instead on an older • Absent Reseed Control (QNX < 6.6): In all QNX
Yarrow 0.8.71 implementation by Counterpane [24] versions prior to 6.6 reseed control is completely
which has not undergone the security scrutiny Yarrow absent. While the required functionality was
has seen over the years and differs in the following key implemented, the responsible functions are never
aspects: actually invoked, which means that while entropy
is being accumulated during runtime it is never
• Single Entropy Pool: While Yarrow-160 has actually used to reseed the state and thus only
separate fast and slow entropy pools, Yarrow boottime entropy is actually ever used to seed the
0.8.71 only has a single entropy pool. The two QNX Yarrow state in versions prior to 6.6.
pools were introduced so that the fast pool could
provide frequent reseeds of the Yarrow key to • Custom Reseed Control (QNX 6.6): In QNX
limit the impact of state compromises while the 6.6 there is a custom reseeding mechanism
slow pool provides rare, but very conservative, integrated into the yarrow_do_sha1 and
reseeds of the key to limit the impact of entropy yarrow_make_new_state functions (as illus-
estimates which are too optimistic. Yarrow trated in Listings 15 and 16) which are called
0.8.71’s single pool does not allow for such upon PRNG initialization and whenever output

Page 14 of 22
 Dissecting QNX

is drawn from the PRNG (which means it is also done before reseeding the state from the entropy pool
constantly called during entropy accumulation thus potentially allowing for low-quality entropy to
due to the above mentioned output mixing determine the entire state.
mechanism). In both cases, a permutation named
IncGaloisCounter5X32 is applied to the entropy In order to evaluate the QNX Yarrow PRNG output
pool before the pool contents are mixed into quality we used two test suites: DieHarder [18]
a SHA1 state which eventually becomes the and the NIST SP800-22 [40] Statistical Test
Yarrow internal state. Contrary to Yarrow design Suite (STS) [39]. DieHarder is a random number
specifications, no entropy quality estimation is generator testing suite, composed of a series of
done before reseeding. statistical tests, "designed to permit one to push a weak
generator to unambiguous failure" [18]. The NIST
Listing 15: QNX 6.6 yarrow_do_sha1 function Statistical Test Suite (STS) consists of 15 tests
void yarrow_do_sha1 ( yarrow_t * p , developed to evaluate the ’randomness’ of binary
yarrow_gen_ctx_t * ctx ) sequences produced by hardware- or software-based
{ cryptographic (pseudo-) random number generators
SHA1Init (& sha ) ; by assessing the presence or absence of a particular
statistical pattern. The goal is to "minimize the
I n c G a l o i s C o u n t e r 5 X 3 2 ( p−>pool . s t a t e )
;
probability of accepting a sequence being produced by
sha . s t a t e [ 0] ^= p−>pool . s t a t e [ 4 ] ; a generator as good when the generator was actually
sha . s t a t e [ 1] ^= p−>pool . s t a t e [ 3 ] ; bad" [40]. While there are an infinite number of
sha . s t a t e [ 2] ^= p−>pool . s t a t e [ 2 ] ; possible statistical tests and as such no specific test
sha . s t a t e [ 3] ^= p−>pool . s t a t e [ 1 ] ; suite can be deemed truly complete, they can help
sha . s t a t e [ 4] ^= p−>pool . s t a t e [ 0 ] ; uncover particularly weak random number generators.

SHA1Update(&sha , c t x−>i v , 20) ; QNX Yarrow passed both the DieHarder and
SHA1Update(&sha , c t x−>out , 20) ; NIST STS tests but this only tells us something about
SHA1Final ( c t x−>out , &sha ) ;
the quality of PRNG output, leaving the possibility
}
open that raw noise / source entropy is (heavily)
biased which can result in predictable PRNG outputs
Listing 16: QNX 6.6 yarrow_make_new_state function as well as attackers being able to replicate PRNG
void yarrow_make_new_state ( yarrow_t * internal states after a reasonable number of guesses.
p , yarrow_gen_ctx_t * ctx , uint8_t As such we reverse-engineered and evaluated the QNX
* state ) random service’s boot- and runtime entropy sources.
{
f o r ( i = 0 ; i < 20; i++) Boottime Entropy Analysis: When random is ini-
c t x−>i v [ i ] ^= s t a t e tialized it gathers initial boottime entropy from the
following sources (as illustrated in Figure 9) which are
SHA1Init (& sha ) ;
fed to the SHA1 hash function to produce a digest used
I n c G a l o i s C o u n t e r 5 X 3 2 ( p−>pool . s t a t e )
to initialize the PRNG initial state:
;
sha . s t a t e [ 0] ^= p−>pool . s t a t e [ 4 ] ; • ClockTime [47]: The current system clock time.
sha . s t a t e [ 1] ^= p−>pool . s t a t e [ 3 ] ;
sha . s t a t e [ 2] ^= p−>pool . s t a t e [ 2 ] ; • ClockCycles [46]: The current value of a free-
sha . s t a t e [ 3] ^= p−>pool . s t a t e [ 1 ] ; running 64-bit clock cycle counter.
sha . s t a t e [ 4] ^= p−>pool . s t a t e [ 0 ] ;
• PIDs: The currently active process IDs by walking
SHA1Update(&sha , c t x−>i v , 20) ; the /proc directory.
SHA1Final ( c t x−>out , &sha ) ;
}
• Device Names: The currently available device
names by walking the /dev directory.
While all the above discussed divergences are
at the very least ill-advised, the reseeding control In order to evaluate random’s boottime entropy
issues constitute a clear security issue. In the case quality we used the NIST SP800-90B [41] Entropy
of absent reseeding control, it eliminates Yarrow’s Source Testing (EST) tool [38] to evaluate
intended defense against state compromise as well as boottime entropy by means of a min entropy estimate.
greatly increasing system susceptibility to the so-called We collected random’s boottime entropy from 50
"boottime entropy hole" [10] that affects embedded different reboot sessions on the same device (by
systems. In the case of the QNX Yarrow 6.6 custom instrumenting yarrow_init_poll and logging the
reseeding control no entropy quality estimation is collected raw noise) and using NIST EST determined

Page 15 of 22
 Dissecting QNX

that the average min-entropy was 0.02765687, which program image base addresses, register values,
is far less than 1 bit of min-entropy per 8 bits of flag values, task priority, etc.) for every currently
raw noise. In addition to the boottime entropy of active process.
individual boot sessions being of low quality, the
static or minimally variable nature of many of the • High-Performance Clock Timing: This source
boottime noise sources (identical processes and draws entropy from the PRNG (using the
devices available upon reboot, real-time nature of yarrow_output function), initiates a delay (in
QNX limiting jitter between kernel calls thus reducing milliseconds) based on the PRNG output, invokes
ClockCycles entropy, etc.) results in predictable and ClockCycles and xors the result against the
consistent patterns across reboots. earlier obtained PRNG output and feeds this into
the entropy pool.

• Library Hardware Entropy Source (Un-

ClockTime ClockCycles /proc PIDs /dev N ames
documented): This undocumented entropy
source (invoked using command-line param-
eter -l) allows a user to specify a dynamic
library to supply entropy collection callback
SH A1 functions named entropy_source_init and
entropy_source_start. In order to be used the
library has to export a symbol named cookie with
Q N X Yarrow
Initial State
the NULL-terminated value RNG (0x524E4700).
Based on debugging information it seems this is
to allow for drawing from a hardware random
Figure 9: QNX Yarrow Boottime Entropy Collection number generator as an entropy source.

Another boottime entropy issue with QNX’s random • User-Supplied Input (Undocumented): In QNX
service is the fact that the service is started as a process 6.6 the random service has a write-handler made
by startup.sh. As a result, the CSPRNG is only avail- available to users via the kernel resource manager
able quite late in the boot process and many services (in the form of handling write operations to the
which need it (eg. sshd) start almost immediately after. /dev/(u)random interfaces) which takes arbitrary
Since random only offers non-blocking interfaces, this user inputs of up to 1024 bytes per write opera-
means that one can draw as much output from the tion and feeds it directly into the entropy pool by
CSPRNG as one wants immediately upon availability passing it to the yarrow_input operation. Write
of the device interface. Hence, many applications operations of this kind are restricted to the root
which start at boot and require secure random data user only.
have their ’randomness’ determined almost completely
by the (very low quality) boottime raw noise since After initialization, random starts a thread for each
there is little time for the QNX random service to entroy source which will gather entropy and store it
gather runtime entropy before being queried thus am- in the entropy pool. Contrary to our analysis of QNX
plifying the impact of the "boot-time entropy hole" [10]. random’s boottime entropy, we did not perform a run-
time entropy quality evaluation because during our
Runtime Entropy Analysis: The QNX random ser- contact with the vendor they had already indicated
vice leaves the choice and combination of runtime en- the current design would be overhauled in upcoming
tropy sources (as illustrated in Figure 10) up to the patches and future releases as a result of our findings.
person configuring the system with the following op- In addition, in all QNX versions except for 6.6 runtime
tions: entropy is accumulated but not used due to the pre-
viously mentioned absent reseeding control. We did
• Interrupt Request Timing: Up to 32 different have the following observations however:
interrupt numbers may be specified to be used as
an entropy source. The entropy here is derived • Entropy Source Configuration: Configuring
from interval timing measurements (measured by runtime entropy sources is entirely left to system
the ClockTime kernel call) between requests to a integrators. Since the entropic quality of certain
specific interrupt. sources (eg. interrupt request timings or system
information polling) varies depending on the
• System Information Polling: This source col- particular system, it is non-trivial to pick suitable
lects entropy from system information via the sources.
procfs [48] virtual filesystem in /proc. This
information is composed of process and thread • System Information Entropy Source: System
information (process and thread IDs, stack and information polling gathers raw noise from

Page 16 of 22
 Dissecting QNX

currently running processes (in the form of unsigned i n t new_dig_idx ;

process and thread debug info). A significant unsigned int result ;
number of the fields in the process and thread uint32_t keypad [ 8 ] ;
debug info structures, however, are largely static sha256_t shout ;
values (eg. uid, flags, priority, stack and program
i f ( dig_idx > 7 )
base in the absence of ASLR, etc.) with most
{
randomness derived from time-based fields keypad [0 ] = s a l t ^ C l o c k C y c l e s ( ) ;
(starttime, runtime) or program state (ip, sp). keypad [1 ] = a c t i v e s [ get_cpunum ( ) ] ;
keypad [2 ] = s a l t ^ q t i m e p t r −>nsec ;
• Interrupt Request Timing Entropy Source: In- keypad [3 ] = pid_unique ^ s a l t ;
terrupt request timing gathers raw noise from in- keypad [4 ] = wakeup_timer ;
terrupt invocation timings. As such this means keypad [5 ] = k e r n e l _ e x i t _ c o u n t ;
that if integrators choose to specify interrupts that keypad [6 ] ^= random_seed ;
are rarely or never invoked, barely any runtime s h a 2 5 6 _ i n i t (& shout ) ;
entropy is gathered using this source. Interrupt in- sha256_add(& shout , keypad , 0x20u ) ;
vocation frequency can be very system specific and sha256_done(& shout , d i g e s t ) ;
result = digest [0];
picking the right interrupts is not trivial. The QNX
if ( ! salt )
documentation explicitly recommends to "mini- salt = digest [0];
mize the impact of [interrupt request timing over- new_dig_idx = 1 ;
head] by specifying only one or two interrupts from }
low interrupt rate devices such as disk drivers and else
input/serial devices" [56], an advice which would {
result in less entropy being accumulated from this new_dig_idx = d i g _ i d x + 1 ;
source. Furthermore, it seems that if for whatever r e s u l t = digest [ dig_idx ];
reasons the random service cannot attach to an }
interrupt, the interrupt entropy gathering thread d i g _ i d x = new_dig_idx ;
fails silently and no entropy is gathered for that return r e s u l t ;
}
interrupt at all.

H igh Performance System Information

Clock Source Polling Source SysSrandom() random_seed

yarrow_output /proc info yarrow_output

actives[get_cpunum()]

ClockCycles()
delay ClockCycles SH A1 delay wakeup_timer
PR N G Input Block
pid_unique
ClockTime kernel_exit_count
yarrow_output yarrow_input

qtimeptr->nsec
interrupt invoked
ClockTime U ndocumented
>= N times? entropy_source_start dev_random_write
Sources

Interrupt Request Initial Value: 0 Salt PR N G State

Timing Source

if salt = 0 Block #0 Block #dig_idx

Figure 10: QNX Yarrow Runtime Entropy Collection

If dig_idx > 7 If dig_idx <= 7

O utput:
5.2 QNX 7.0 Kernel PRNG R andom Value
(32-bit)

QNX 7 has a new kernel PRNG for generation of secure Figure 11: QNX Kernel PRNG
random numbers implemented in the microkernel’s
random_value function. As shown in Listing 17 and Kernel PRNG entropy is drawn from a combination
illustrated in Figure 11, the kernel PRNG consists of a of the following values:
256-bit seed block fed through SHA256 to produce a
digest from which 32-bit random numbers are drawn
iteratively before reseeding after exhausting the entire • salt: A salt value which starts out as 0 and then
digest. gets filled with the first non-zero 32 bits of every
newly generated digest.

Listing 17: QNX 7 Kernel PRNG • ClockCycles: The current clock cycle counter
unsigned i n t random_value ( ) value.
{

Page 17 of 22
 Dissecting QNX

• actives[get_cpunum()]: The currently active Seedfile Source fortuna_pseudorand

thread on this CPU. System Information

fortuna_save_state seedfile Polling Source

• qtimeptr->nsec: The current time in nanosec- H igh Performance fortuna_load_state

/proc info fortuna_pseudorand

onds.
Clock Source

SH A256 delay
fortuna_pseudorand

• pid_unique: The currently active PID. delay ClockCycles

ClockTime

• wakeup_timer: The timer wakeup value [45]. fortuna_pseudorand fortuna_add add_entropy PR N G state

• kernel_exit_count: Counter keeping track of

interrupt invoked ClockTime
>= N times? entropy_source_start dev_random_write arc4random()

the number of kernel exit operations. Interrupt Request

Timing Source
Library Source
U ser-Supplied
getpid()

Source
gettimeofday()

• random_seed: Random seed user-supplied via

SysSrandom [58] kernel calls. This kernel
Reseed Source getuid()

call can only be made by processes with the

PROCMGR_AID_SRANDOM ability. Figure 12: QNX 7 Fortuna Entropy Collection

Of these sources, pid_unique and • High-Performance Clock Timing: This source

actives[get_cpunum()] have a limited range is identical to the one in the QNX 6.6 random
of possible values and none of the sources ex- implementation.
cept for wakeup_timer, kernel_exit_count and
random_seed can be considered secret. Some sources • Library Hardware Entropy Source: This source
(eg. ClockCycles, kernel_exit_count) are also is identical to the one in the QNX 6.6 random
likely to have greatly reduced ranges during boot-time. implementation.

Finally, note that all sources are truncated to • User-Supplied Input: Anything written to the
32-bit values when stored in the seed block, that /dev/(u)random device is immediately absorbed
random_seed is only initialized when system integra- into the PRNG state and, if seedfile state persis-
tors utilize it and that the final block (keypad[7]) is tence is enabled, the state is saved as well. It
never initialized. As such, in many cases the theoretical is possible to shield this functionality with the
maximum of the entropy contained within the seed -m mode option specifying permissions but by
block would be reduced to 192 bits. A full evaluation default the interface is world-writable which
of the entropic quality of the QNX 7 kernel PRNG is could possibly present an avenue for reseeding
left to future work. attacks.

• Seedfile Source: If specified, QNX 7 Fortuna

5.3 /dev/random in QNX 7.0 can load and save entropy from and to a 128-byte
Following our advisory on the QNX Yarrow PRNG, seedfile (done after writing to /dev/(u)random
the QNX 7 random service was redesigned to use or automatically after 8192 reseedings). This file
Fortuna instead. While the design and interface of is owned by root with user read/write permissions
the random service remains mostly the same, QNX only.
7 uses a customized version of the Heimdal [32]
Fortuna implementation as illustrated in Figure 12. • Reseed Source: Reseed control is integrated into
the fortuna_bytes and fortuna_init routines
and thus checked periodically. It is implemented
The QNX 7 Fortuna implementation no longer
as shown in Listing 18. This routine is not likely
has dedicated boot- and runtime entropy collection
to provide high quality reseed entropy consid-
routines and draws upon the following entropy sources:
ering that pid and uid do not change for the
random service and that arc4random reads from
/dev/random (creating a circular reseed loop) and
• Interrupt Request Timing: This source is
uses the broken RC4 cipher.
identical to the one in the QNX 6.6 random
implementation.
Listing 18: QNX 7 fortuna_reseed
• System Information Polling: This source is #de f i ne INIT_BYTES 128
identical to the one in the QNX 6.6 random
implementation. int fortuna_reseed ()
{

Page 18 of 22
 Dissecting QNX

u i n t 3 2 _ t buf [ INIT_BYTES / s i z e o f ( Component Issues Affected

uint32_t ) ]; ESP Disabled by default ≤ 7.0
int i ; ASLR Disabled by default1 ≤ 7.0
i n t entropy_p = 0 ; ASLR No KASLR1 ≤ 7.0
ASLR Weak Randomization1 ≤ 6.6
i f ( ! init_done ) ASLR No Re-Randomization1 ≤ 7.0
abort () ;
ASLR procfs Infoleak1 ≤ 7.0
f o r ( i = 0 ; i < s i z e o f ( buf ) / s i z e o f ( buf
ASLR LD_DEBUG Infoleak3 ≤ 6.6
[ 0 ] ) ; i++) ASLR Correlation Attack1 ≤ 6.6
buf [ i ] = arc4random ( ) ; SSP Disabled by default ≤ 6.6
SSP Weak Randomization ≤ 6.6
add_entropy (& m a i n _ s t a t e , ( void * ) buf , SSP No Re-Randomization ≤ 7.0
s i z e o f ( buf ) ) ; SSP No Kernel Canaries ≤ 6.6
entropy_p = 1 ; RELRO Disabled by default2 ≤ 6.6
RELRO Broken RELRO2 ≤ 6.6
pid_t pid = getpid () ; RELRO LD_DEBUG Bypass2 ≤ 6.6
add_entropy (& m a i n _ s t a t e , ( void * )&pid ,
OS CSPRNG Ill-Advised Design ≤ 6.6
sizeof ( pid ) ) ;
OS CSPRNG Absent Reseed Control < 6.6
struct timeval tv ; OS CSPRNG Low Boottime Entropy ≤ 6.6
g e t t i m e o f d a y (& tv , NULL) ;
add_entropy (& m a i n _ s t a t e , ( void * )&tv , Table 11: QNX Mitigation & RNG Issues Overview
1
sizeof ( tv ) ) ; CVE-2017-3892, 2 CVE-2017-3893, 3 CVE-2017-9369

uid_t u = getuid () ;
add_entropy (& m a i n _ s t a t e , ( void * )&u ,
gations as they have evolved in the general purpose
sizeof (u) ) ; world, the fact that it is a proprietary OS outside
of the Linux, Windows and BSD lineages means
return entropy_p ; that they cannot trivially port mitigations, patches
} and improvements from these operating systems.
In addition, the relative lack of attention to QNX
Due to the elimination of dedicated boottime en- by outside security researchers is evident from the
tropy harvesting and its rapid startup time, QNX 7 degree to which certain vulnerabilities and issues
Fortuna is likely to suffer from the "boottime entropy (such as the local information leaks or the "poor man’s
hole" (unless system integrators explicitly enable seed- randomization patch" design for ASLR/SSP) resemble
files / state persistence) but we leave a full analysis of older vulnerabilities on other Unix-like systems.
entropic quality to future work. Finally, our findings re-confirm the notion that secure
random number generation and especially integrating
suitable entropy sources is an issue that continues to
6 Conclusion plague the embedded world. The impact of this goes
beyond affecting the quality of exploit mitigations and
We reverse-engineered and analyze the exploit has consequences for the wider security ecosystem as
mitigations and secure random number generators a whole.
of QNX ≤ 6.6 and 7.0 and found and reported a
myriad of issues of varying degrees of severity. Table It is our hope that this work inspires other security
11 presents an overview of the analyzed mitigations researchers to further investigate the security and OS
and RNGs, their issues and what versions are affected internals of QNX and other closed-source embedded
by them. Note that we have left proper RNG entropy operating systems.
quality and ASLR correlation attack evaluation of QNX
7’s to future work and as such we can neither confirm
nor rule out issues in this regard. Bibliography
We can see that despite our disclosure of the issues [1] Alex Plaskett et al. QNX: 99 Problems but a Mi-
affecting QNX 6.6 and subsequent fixes being drafted crokernel ain’t one! 2016.
for the bulk of them, some of them remained in QNX
[2] Daniel J. Bernstein et al. “Factoring RSA keys
7.0. Regardless, General Availability (GA) patches
from certified smart cards: Coppersmith in the
are available for all issues affecting QNX ≤ 6.6 in
wild”. In: ASIACRYPT (2013).
Table 11 (naturally excluding those affecting QNX 7.0).
[3] Daniel Martin Gomez et al. BlackBerry PlayBook
One striking observation is that while QNX clearly Security: Part one. 2011.
attempts to keep up with at least basic exploit miti-

Page 19 of 22
 Dissecting QNX

[4] David Kaplan et al. “Attacking the Linux PRNG [20] c0ntex. How to hijack the Global Offset Table
on Android & Embedded Devices”. In: Black Hat with pointers for root shells. url: http://www.
Europe (2014). url: https://www.blackhat. infosecwriters.com/text_resources/pdf/
com/docs/eu- 14/materials/eu- 14- Kedmi- GOT_Hijack.pdf.
Attacking - The - Linux - PRNG - On - Android - [21] Communications Security Establishment
Weaknesses - In - Seeding - Of - Entropic - Canada. EAL 4+ Evaluation of QNX Neutrino®
Pools-And-Low-Boot-Time-Entropy.pdf. Secure Kernel v6.4.0. 2009. url: https :
[5] Hector Marco-Gisbert et al. “Preventing brute / / www . commoncriteriaportal . org / files /
force attacks against stack canary protection epfiles/neutrino-v640-cert-eng.pdf.
on networking servers”. In: 12th IEEE Interna- [22] Silvio Cesare. CVE-2004-1453. 2004. url: http:
tional Symposium on Network Computing and / / www . cve . mitre . org / cgi - bin / cvename .
Applications (NCA) (2013). cgi?name=CVE-2004-1453.
[6] Hector Marco-Gisbert et al. “On the Effective- [23] Colt. Android OS - Processes and the Zygote! url:
ness of Full-ASLR on 64-bit Linux”. In: DeepSec http://coltf.blogspot.nl/p/android-os-
(2014). processes-and-zygote.html.
[7] Hector Marco-Gisbert et al. “Exploiting Linux [24] Counterpane. Yarrow 0.8.71. url: https : / /
and PaX ASLR’s weaknesses on 32- and 64-bit www.schneier.com/code/Yarrow0.8.71.zip.
systems”. In: BlackHat Asia (2016).
[25] CVE Details. QNX CVEs. url: https : / / www .
[8] John Kelsey et al. “Yarrow-160: Notes on the De- cvedetails . com / vulnerability - list /
sign and Analysis of the Yarrow Cryptographic vendor_id-436/QNX.html.
Pseudorandom Number Generator”. In: Sixth
[26] Jake Edge. proc: avoid information leaks to
Annual Workshop on Selected Areas in Cryptog-
non-privileged processes. 2009. url: https://
raphy (1999).
patchwork.kernel.org/patch/21766/.
[9] Keaton Mowery et al. “Welcome to the Entropics:
[27] Julio Cesar Fort. QNX Advisories. url: https://
Boot-Time Entropy in Embedded Devices”. In:
packetstormsecurity . com / files / author /
IEEE Security and Privacy (2013).
3551/.
[10] Nadia Heninger et al. “Mining Your Ps and
[28] Hagen Fritsch. Buffer overflows on linux-x86-64.
Qs: Detection of Widespread Weak Keys in Net-
2009.
work Devices”. In: USENIX Security Symposium
(2012). [29] Hagen Fritsch. Stack Smashing as of Today.
2009.
[11] Niels Ferguson et al. Practical Cryptography. Wi-
ley, 2003. [30] Manu Garg. About ELF Auxiliary Vectors. url:
http : / / articles . manugarg . com /
[12] Tavis Ormandy et al. Linux ASLR Curiosities.
aboutelfauxiliaryvectors.
2009. url: https://www.cr0.org/paper/to-
jt-linux-alsr-leak.pdf. [31] Hector Marco Gisbert. “Cyber-security protec-
tion techniques to mitigate memory errors
[13] Zach Lanier et al. Voight-Kampff’ing The Black-
exploitation”. In: (2015). url: https : / /
Berry PlayBook. 2012.
riunet . upv . es / bitstream / handle /
[14] Zach Lanier et al. No Apology Required: Decon- 10251 / 57806 / Marco % 20 - %20Cyber -
structing BB10. 2014. security % 20protection % 20techniques %
[15] Alexander Antukh. Dissecting Blackberry 10 – 20to % 20mitigate % 20memory % 20errors %
An initial analysis. 2013. 20exploitation . pdf ? sequence = 1 &
[16] BlackBerry. Using compiler and linker defenses isAllowed=y.
(BlackBerry Native SDK for PlayBook OS). url: [32] Heimdal. The Heimdal Kerberos 5, PKIX, CMS,
http : / / developer . blackberry . com / GSS-API, SPNEGO, NTLM, Digest-MD5 and, SASL
playbook / native / reference / com . qnx . implementation. url: http://www.h5l.org/.
doc . native _ sdk . security / topic / using _ [33] Alejandro Hernandez. A Short Tale About exe-
compiler_linker_defenses.html. cutable_stack in elf_read_implies_exec() in the
[17] BlackBerry. QNX. 2017. url: http://www.qnx. Linux Kernel. url: http : / / blog . ioactive .
com/content/qnx/en.html. com / 2013 / 11 / a - short - tale - about -
[18] Robert G. Brown. Dieharder: A Random Number executablestack-in.html.
Test Suite. url: https://www.phy.duke.edu/ [34] Tobias Klein. checksec. url: http : / / www .
\~rgb/General/dieharder.php. trapkit.de/tools/checksec.html.
[19] Tim Brown. QNX Advisories. url: https : / / [35] Gentoo Linux. Hardened/GNU stack quickstart.
packetstormsecurity . com / files / author / url: https : / / wiki . gentoo . org / wiki /
4309/. Hardened/GNU_stack_quickstart.

Page 20 of 22
 Dissecting QNX

[36] Matt Miller. “Reducing the Effective Entropy of [51] QNX Software Systems. On. url: http : / /
GS Cookies”. In: Uninformed Vol. 7 (2007). www.qnx.com/developers/docs/660/index.
[37] Bojan Nikolic. The LD_DEBUG environment vari- jsp ? topic = %2Fcom . qnx . doc . neutrino .
able. url: http : / / www . bnikolic . co . uk / utilities%2Ftopic%2Fo%2Fon.html.
blog/linux-ld-debug.html. [52] QNX Software Systems. pidin. url: http : / /
[38] NIST. NIST Entropy Source Testing (EST) tool. www . qnx . com / developers / docs / 660 /
url: https : / / github . com / usnistgov / index.jsp?topic=/com.qnx.doc.neutrino.
SP800-90B_EntropyAssessment. utilities/topic/p/pidin.html.
[39] NIST. NIST Statistical Test Suite (STS). url: [53] QNX Software Systems. Private virtual memory.
http : / / csrc . nist . gov / groups / ST / url: http : / / www . qnx . com / developers /
toolkit / rng / documentation \ _software . docs / 660 / index . jsp ? topic = %2Fcom . qnx .
html. doc.neutrino.sys_arch%2Ftopic%2Fproc_
Private_virtual_memory.html.
[40] NIST. “NIST SP800-22: A Statistical Test Suite
for Random and Pseudorandom Number Gener- [54] QNX Software Systems. Procmgr abilities. url:
ators for Cryptographic Applications”. In: NIST http://www.qnx.com/developers/docs/6.
(2010). 6.0.update/#com.qnx.doc.neutrino.prog/
topic/process_Procmgr_abilities.html.
[41] NIST. “NIST SP800-90B: Recommendation for
the Entropy Sources Used for Random Bit Gen- [55] QNX Software Systems. Procnto. url: http://
eration”. In: NIST (2016). www.qnx.com/developers/docs/660/index.
jsp ? topic = %2Fcom . qnx . doc . neutrino .
[42] Alex Plaskett. QNX Security Architecture. 2016. utilities/topic/p/procnto.html.
[43] Paul Rascagneres. Stack Smashing Protector. [56] QNX Software Systems. Random. url: http://
2010. www.qnx.com/developers/docs/660/index.
[44] Fermin J. Serna. “The info leak era on software jsp ? topic = %2Fcom . qnx . doc . neutrino .
exploitation”. In: Black Hat US (2012). utilities/topic/r/random.html.
[45] QNX Software Systems. Clock and timer services. [57] QNX Software Systems. Shared memory. url:
url: http : / / www . qnx . com / developers / http://www.qnx.com/developers/docs/7.0.
docs / 7 . 0 . 0 / index . html # com . qnx . 0/index.html#com.qnx.doc.neutrino.sys_
doc . neutrino . sys _ arch / topic / kernel _ arch/topic/ipc_Shared_memory.html.
CLOCKANDTIMER.html. [58] QNX Software Systems. SysSrandom(), SysSran-
[46] QNX Software Systems. ClockCycles(). url: dom_r(). url: http : / / www . qnx . com /
http : / / www . qnx . com / developers / docs / developers / docs / 7 . 0 . 0 / index . html #
660 / index . jsp ? topic = %2Fcom . qnx . com . qnx . doc . neutrino . lib _ ref / topic /
doc . neutrino . lib _ ref % 2Ftopic % 2Fc % s/syssrandom.html.
2Fclockcycles.html. [59] QNX Software Systems. Typed memory. url:
[47] QNX Software Systems. ClockTime(), Clock- http : / / www . qnx . com / developers / docs /
Time_r(). url: http : / / www . qnx . com / 7.0.0/index.html#com.qnx.doc.neutrino.
developers/docs/660/topic/com.qnx.doc. sys_arch/topic/ipc_Typed_memory.html.
neutrino . lib _ ref / topic / c / clocktime . [60] QNX Software Systems. QNX Neutrino RTOS:
html. System Architecture. 2014. url: http : / /
[48] QNX Software Systems. Controlling processes via support7 . qnx . com / download / download /
the /proc filesystem. url: http : / / www . qnx . 26183 / QNX _ Neutrino _ RTOS _ System _
com / developers / docs / 660 / index . jsp ? Architecture.pdf.
topic = %2Fcom . qnx . doc . neutrino . prog % [61] QNX Software Systems. 50 Million Vehicles and
2Ftopic%2Fprocess_proc_filesystem.html. Counting: QNX Achieves New Milestone in Auto-
[49] QNX Software Systems. DCMD_PROC_INFO. motive Market. 2015. url: http://www.qnx.
url: http : / / www . qnx . com / developers / com/news/pr_6118_3.html.
docs / 660 / index . jsp ? topic = %2Fcom . qnx . [62] Julien Tinnes. Local bypass of Linux ASLR
doc . neutrino . cookbook % 2Ftopic % 2Fs3 _ through /proc information leaks. 2009. url:
procfs_DCMD_PROC_INFO.html. http : / / blog . cr0 . org / 2009 / 04 / local -
[50] QNX Software Systems. devctl. url: http:// bypass - of - linux - aslr - through - proc .
www.qnx.com/developers/docs/660/index. html.
jsp?topic=%2Fcom.qnx.doc.neutrino.lib_ [63] Ubuntu. ld.so, ld-linux.so - dynamic linker/loader.
ref%2Ftopic%2Fd%2Fdevctl.html. 2017. url: http://manpages.ubuntu.com/
manpages/xenial/man8/ld.so.8.html.

Page 21 of 22
 Dissecting QNX

[64] Ubuntu. /proc/pid/maps protection. 2017. url:

https : / / wiki . ubuntu . com / Security /
Features#proc-maps.
[65] Gerrit De Vynck. CIA Listed BlackBerry’s Car Soft-
ware as Possible Target. 2017. url: https://
www.bloomberg.com/news/articles/2017-
03 - 08 / cia - listed - blackberry - s - car -
software-as-possible-target-in-leak.
[66] Ralf-Philipp Weinmann. BlackberryOS 10 From
a Security Perspective. 2013.
[67] Adam ’pi3’Zabrocki. “Scraps of notes on remote
stack overflow exploitation”. In: Phrack (2010).

Page 22 of 22