Dear viewer, these subtitles were generated by a machine via the service Trint and therefore are (very) buggy. If you are capable, please help us to create good quality subtitles: https://c3subtitles.de/talk/845 Thanks!
Hello. So we're ready to start.
It's my pleasure to introduce to
you your sweatsuits and
Ali Abbasid
with taking a scalpel to
QNX, you'll get a deep dove
analysis of the QNX operating
system.
And with that, I will just
give it straight over to you.
Thanks. All right.
Thanks for that great round
of applause.
All right, so welcome, everybody, to
talk. Taking a scalpel to QNX, analyzing
and breaking exploit mitigations and
bearings on QNX, six and seven.
My name is Charles Wetzel's and I'm
currently an independent security
researcher with Midnight Blue, where I
mainly focus on embedded systems
security.
I previously worked as a security
researcher at the University of Atlanta,
where I focused on critical
infrastructure protection.
And most of this work was part of my
master's thesis at the University of
Technology.
Hi, my name is Percy.
I'm a student at Eindhoven University
of Technology and a visiting researcher
at Sharov Systems Security at Rowan
University here in Germany.
My research mostly are related to
binary security and programable logic
controller security.
All right. So we'll start this
presentation of an introduction to QNX
and discussing the general operating
system and security architecture before
moving on to discussing the pseudo random
number generators and the exploding
indignations themselves and finishing off
with some final remarks.
So what is QNX?
QNX is a Unix like Botox, compliant,
embedded, realtime operating system, its
closed source and proprietary.
It was initially released in 1982, so
it's quite old and was later acquired by
BlackBerry QNX versions up to
and including six point six hour, 32 bit
operating systems.
But as of QNX seven, which was released
in March of this year, it's a 64 bit
operating system.
Its most famously known for its use in
various mobile devices because it
underpins the BlackBerry 10 operating
system as well as the BlackBerry tablet
operating system.
But really, this is only the tip of the
iceberg of QNX usage, because especially
these days, it's far more prominent in
automotive systems, especially
in infotainment systems.
It holds more than a 50 percent of the
market share and it's set to be used in
various self-driving car initiatives.
For example, Delphi Automotive has
partnered with BlackBerry to use QNX
as the basis of its self-driving car
initiative. So that's very interesting
from a security point of view.
Second, very famous use of QNX is in
a great writers like the Sierra series,
the 12000 series, the as our series.
And I hear QNX is used to underpin
Cisco's iOS Exaro operating system,
as you can see on the right of the slide.
And that, again, makes for all the
obvious reasons, for an interesting
security target.
It's used in many, many more critical
systems. These are just two examples.
You can find it in industrial control
systems like the nuclear power plants of
Westinghouse, surface mining
control turbine controllers, and
various military systems such as oves
or military radios, anti-tank guidance
systems, medical systems, railway
safety, you name it.
So the security implications are obvious.
I'd say
last year some people might remember, we
also gave a talk which covered some of
this subject matter.
I called Wheel of Fortune and here we
focused on and issues in vehicles works
redacted address, which we can name for
NDA reasons and QNX versions
up to and including six point six.
So in this talk, we'll discuss a lot of
different stuff.
We'll discuss to discuss the new
userspace internal space beer GS of QNX
seven and focus on the explosion
mitigations of QNX six and seven, which
haven't been discussed before.
So I hereby hand the introduction to the
OS and security architecture to Alere.
So, Oisin, security architecture.
QNX is a MicroCon at through
micro Karenin.
So what it means, it means that basically
most of the components of the operating
system within the kernel will be
out of the kurnit things
which you expect to be in the kernel are
not any more there. So things
like filesystem, stuff
like device drivers,
well, protocol attacks,
all of them are actually located outside
of the kernel.
And what you will have is just really
tiny, tiny micro kernel
which have
some benefits. So for example,
the biggest one is actually
the higher reliability for the operating
system because there are less
chances for the buggy implementation,
which cause a crash in operating the
entire operating system.
But also it
will provide something we call
Lesra for hackers
to hang on. And it's because
there will be a smaller surface
for attackers to target the kernel or
the micro kernel.
So it will help some
micro kernel, generally micro
kind of operating systems to get higher
ed levels from NSA or
other cert buddies.
So that's micro
kind of. But how
then when you are putting all of these
components outside, outside of
the kernel or in a macro kernel,
how then they are actually going to
communicate, how they are going to work?
So what you will have here
like is a message
boss in the and.
Specifically, which
the functionality where
I assume a program like a like
a network communication,
so it will be very similar to the network
communication. So what you will have is
that an application in the user
space wants to communicate, let's
say, filesystem.
So how does it send
a message to the microphone
which the microphone would pass it to the
target application?
So let's say filesystem and the
filesystem respond and this message will
be then pass to the
application.
So that's the message by saying message
box basically. And the micro kind of
basically the task of micro kind of
basically is to forward
these messages to the other components.
But one interesting thing about
QNX specifically is that this
kind, this architecture combined with
something called CUNEYT and QNX,
provide a functionality where you can
have multiple, multiple channels
running and talking with each other.
So let's say they can actually Vioxx
units to microtonal can
have like a talk over
Ethernet, which
provide greater functionalities, for
example, for networking
or network communications.
Beside that, actually, QNX also supports
these calls, but it's not as big as
well. General, in Linux, which you have
more than 300 Tsiskaridze, but it's like
less than 90
and also of Unix is a
POSIX compatible meaning that
you can have those are standard Lipsy
functions, which you write in your code.
But here you are using
a specific Unix compiler
and then this compiler convert
this Lipsy functions
to message passingly
stops basically.
Regarding the memory layout, so
you will have the space and
use our space, but the only thing which
is remaining or stay at the COL
space is the MicroCon itself.
And basically also
there will be userspace separation.
So it means that there
is no possibility for some processes
within the within the user space to
just, like, touch each
other, for example, because some
of them are sensitive. So basically, QNX
provide a virtual private memory support
via a memory management unit.
But also QNX provides unique
like process access control, which
talked about the.
With respect to QNX memory
layout's, if you look at the userspace
part, there's not that much significant
difference than the stuff we know in
other operating systems.
So you will have program image and
basically el there in a micro kind
of basically loaded.
And then you have like your shared object
or dynamic libraries, which which we
will be lauded by Islamic thinkers.
However, in the current space, one thing
which is interesting is that all of the
actors like basically to address
the base address of the microgrants
starts at a static
location or a static address
and per CPU you will have
different STAC.
So now let's look at the process
management, so process
management is a little bit
different, so let's say there is
a process called Provencio, which Manit,
which is basically process manager, but
part of it is located at the microtonal,
but other part of it is located at
the USERSPACE.
So the process manager is actually
running by route's process like
the one.
And basically it
invokes the micro kind of the same
as the same way as other processes.
But the only difference here is that it
have a flag and
offering zero, which
provides zero privilege
for democracy. And I said,
uh, beside that, as we said before,
the actually support the usual politics
of stuff, sort of Spaan for all
of them are provided.
Also, as I said before, QNX actually
uses L format a file.
But here's the interesting thing is that
if the file system is on block or
oriented entity versus the code and data
are actually loaded into the
main memory y, if a file
system is actually a memory mapped
code, then it can be
in place. So basically multiple instances
of the same process share, quote, memory.
Also
provide some sandboxing, so it's
provided it's provided via our
project manager ability, similar to
lining's capabilities,
so you can obtain
capabilities before dropping routes and
also restrict certain actions even for
the user or route process.
But disabilities are like significantly
like Beeks.
So you have Dumain range,
like being locked on Luxo,
you name it. All of them are actually
similar to Linux. But hey,
here, it depends on system
integrators and how they are going to
implement it. It's not a problem of the
operating system, but it's it
will be depending on the
system integrators, how you are going to
use these these functionalities.
Also, critics actually support usually
stuff so like with respect to user
management, so you have to see passport
file shadow.
It is two groups and also usually
utilities such as logging issue
and also it support mandatory access
controls
with respect to hashing mechanism for
passports.
Well, can execs basically
support Shahd, 256
and by default 512?
However, it's actually have it backward
compatibility with Mudie five
encryption.
So which are RECURSE
or basically if one can crack
those devices which have like they're
like for let's say they could be
passwords based on modify or
DNS, then they might
be able to cracky. Then once somebody can
crack it, then they have a
long shelf life for attackers
to use it.
But well things are much better.
And Grenache seven.
So and of course Patch Kewney six
point six.
So they are basically using CDV
to uh
and with the SHA
512 as default.
So looking at the history of the
security of QNX,
majority of research actually done by
BlackBerry mobile usage, which is owner
of QNX from 2011
to 2014, and also very,
very interesting talk in 2016
by Alex Plaskett
about process communication
in QNX space and canonge calls.
I recommend you to watch that.
And Davor, also various
individual vulnerabilities from 2000 to
2008.
But the most interesting part is
the leaks from WikiLeaks
named Vol seven, which
was showing US
Central Intelligence Agency, were
interested in targeting, well,
embedded development branch of the CIA,
were interested in targeting QNX,
which they didn't do yet until 2014.
But we don't know after that.
So basically, there were no no prior
work on exploit mitigation
completely. So this will be the first
time we are going to talk about it.
And also with the Orange Report,
we talked about Premji of six point
six, but here
I will talk about seven punji
implementation, both UserSpacE and
Cairns's.
So let's look at the.
Why we are looking at you
like that?
Well, because actually peerages
is actually have a broader implication.
It's a foundation of wider
cryptographic ecosystem.
So stuff like, I don't know, like SSL,
SSL, all of them are relying on those
stuff.
And besides that, the strands of
exploit mitigation itself are also
are affected by
PR and PR and
quality.
So as your Slatyer talks about
it, you can see that how things
like, for example, is ASALA or is that
cannery's can get affected
by
punji weaknesses.
So as a recap,
we talked to about six point six
of random implementation,
so as a just as a recap.
So basically the original punji,
which was implemented last year, which we
talked about, was based on Yoro, but
not dereference Yoro, but zero one.
But the original was like
an earlier version of the.
And there were some
sketchy design issues.
And basically
the biggest part, which we talk,
for example, have a lack of completely
broken seat control or not
having basically any seat control and
also low quality time entropy
and some entropy
source selection, which was based
on system integrators.
And we show some examples of how
things can go bad system
and regulators don't care about it.
And the operating system itself doesn't
provide the proper purinergic.
However, things got much better in QNX
seven after our assessment, and they
incorporated some of our suggestions.
So right now they are actually using for
implementation.
They are actually using a new unstrapped
resources, which I talk later,
and a proper
reseat control mechanism which
wasn't didn't exist before.
And but basically
overall quiting much better and
still doesn't mean that everything is
fine. So still, there are some design
like decisions or like implementation
decisions which the system integrator
have to have to decide.
And still there can be a texture
face. But from the operating system side,
things are much better.
So let's look at things change
so you don't have to actually look at all
of them and only look at the green parts,
because that's the part which things
change first and
foremost for fixing the problem of the
time. Entropy is actually
seven. They right now provide
a seed source, citified source,
basically, which means that at about time
you can provide a
randomness file which contains
some random like basically
entropy to the operating
system at the time.
And later, once the seed get used
and exhausted at the runtime,
it can get updated.
But the point here is that
the framework have to actually provide a
framework. You have to have different,
for example, seed file.
But beside that, there is also a
user supplied sources of entropy.
So there are different kind of, you know,
supply sources which can be provided.
But the other part is still
the source, basically, which is a still
weird because they are still using, for
example, get your ID and get PID, which
is not at all random because it's just
completely static and get time of
day, which is not random.
But the only proper one is asking
for random function, which is
not that.
Regarding the Channel seven channel PR
energy, which.
Well, seven actually introduce a new
canopy orangy and
there is implementation of it as a
function called random value in the micro
kind of the QNX, and it
will it will be used or being used
as a forward ASALA, and it's
that cannery's by the microtonal.
So basically what you see here is that
you have different sources of entropy.
So, for example, clock cycle, you are
using the PID
or like the current
time in nanoseconds,
also, for example, current CPU
like wake up timer and also some random
seats which you can pass it to parent
input block which get passed
to assure 256.
Function and basically what will happen,
the ingested or the output
will be divided to eight blocks and the
first block will be used as a salt and
a second block will be used
for the like output of the random
value, the started beats.
And there will be a iteration
whenever you actually need a new
random value, which
this iteration moves each time from
location zero to one to three.
So like each time is
the location which you are choosing.
The 32 bytes will change.
Essentially a will change.
Basically, that's the Unit seven
kernel punji and now the meat of the work
actually explodes.
Mitigation Unit seven.
All right.
Um, thank you for that, Ali.
So let's start to look at the exploit
mitigations.
Um, why take a look at exploit
mitigations? Well, because the
mitigations that we're used to in the
general purpose world Windows, Linux,
because they didn't come falling from the
sky, especially not in their current
incarnations.
There's a long history of weaknesses,
bypasses and subsequent improvements, as
you can see, for example, for windows
on the bottom of the slide.
And because there is nothing like that
for QNX, that means that it's
very fruitful ground for finding
interesting stuff, which is why we took a
look at it.
So as of QNX, six point
five, as you can see in the table, there
is support for data, execution,
prevention, space layout, randomization,
stack galleries and relocation read-only.
But don't get too excited because
these are not enabled by default.
So it might just mean that you encounter
a firmer image with QNX and it's fully up
to date. But if system integrators didn't
explicitly enable support for all these
mitigations in their toolchain,
then you might be just exploiting like
it's the 90s.
You also shouldn't expect any support for
advanced mitigations like fee table
protections, contraflow integrity
or criminal code and data isolation.
So this is really just an.
Let's start off with date execution
prevention for those of you unfamiliar
with it, and it seeks to prevent the
execution of injected payloads into data
memory. And roughly speaking, you
have two main architectural styles for
a CPU.
One is the Harvard one where you have
separate, physically separate code and
data memory. And the other one is the von
Neumann one where you have shared
programing data, memory.
And in order to to prevent the execution
of injected payloads and data memory, you
effectively seek to emulate a Harvard
architecture on a Nimon one.
And typically this is done as on a
six eight sixty four on
the bottom of the slide being facilitated
by hardware support in a memory
management unit.
And here in a page table entry, you will
have a specific bit like the annex
bit, which regulates execute ability
of this particular page.
Now, QNX DBE has support for several
of these anex like flags
in the amuse at a support for
it on 86 and 64,
the support for it unarm.
It does not, however, have support for
this feature on MEPs and it has
varying support for PowerPC.
But that's PowerPC.
The big problem with QNX, Debbie, is the
fact that the defaults are insecure.
So the problem is that even if you have
hardware support here and you have a QNX
version that has support for the
B, then still the stack will be left
executable even if the heap is not.
So this is something to really check for
when you encounter a QNX firmware image.
What's more is that the typical Ganu
Stack program, Hattar, is ignored by
the program loader. So regardless of your
Linko settings or whatever, this will be
executable. Now it's possible to
make the stack not executable by
specifying explicitly a particular
flag in the microgrants startup options.
But a big problem is that this is a
system wide setting.
So if you have executables which require
for legacy or backwards compatibility
reasons and executable stack, they can
no longer be included with these
new firmware images.
So even though we reported it and we
said, you know, this is just enough rope
to hang yourself with as a system
integrator, this issue is still present
on June six and seven.
And this really is something to check for
if you encounter a QNX firmware image.
So the second mitigation is outer space,
layered randomization, and again, for
those unfamiliar with outer space,
layered randomization seeks to complicate
code reuse attacks like return oriented
programing by randomizing the memory
object addresses.
So a typical exploitation flow you can
see on the right of the slide, you find
existing code to reuse gadgets
and snippets and stitch them together a
bit like a ransom note on the top
of the slide.
Now, as seeks to prevent this
by using randomness as a means towards
the goal of memory layout secrecy.
Because if you don't know where the
various code fragments are in memory,
then you can stitch them together to form
a robot bailout.
Or at least that's the idea behind a la.
Now, QNX is lawyer is enabled
by starting the micro kernel with, again,
a dedicated flag which is not enabled by
default processes
inherited their parents ezola settings,
but it can be enabled or disabled on a
process basis. So you have a good opt out
scheme. But by default, it's
it's, uh.
Yeah, it's opt out.
So it's not an opt in scheme.
So don't look for mistakes like that.
Memory objects are randomized at a base
outdraws level. So it's not a very fine
grained form of Islam, but that goes
for most Ã¡slaug versions and
most memory objects are randomized except
for the kernel code addresses.
And how terrible that is depends on
your opinion of the usefulness of a
in general. So that's that's not the real
problem here.
Um, one problem that that is
a problem in practice is the fact that BI
is disabled by default in the toolchain.
So that means that unless you explicitly
enable it, then all the binaries you have
and you will compile, including the
system binaries won't have randomization
of of code.
And if you look at a lot of firmware
images of QNX in the wild, you'll find
that in fact, Gode memory is never
actually randomized, which greatly
reduces the usefulness of Ezola.
So in order to learn how QNX Ezola
works under the hood, we reverse engineer
the memory manager of QNX, which you
can see mapped out here, and I'll save
you all the details.
But basically, it comes down to the fact
that all of it is underpinned mostly by
calls to AMAP in the micro kernel
and our two functions that actually
regulate the randomization.
And those are marked in blue, which is
the stack randomize function on the left
and the map find the function on the
right.
And these both rely on the same random
number generator which will discuss in
this, uh, this dark.
Now, the first of the functions must find
HVA, among other things, randomize
as virtual addresses which are returned
by the NAPCO.
And it does this, as you can see on the
right of the slide, by subtracting or
adding a random value to the found
virtual address.
And there's random value is obtained by
taking the lower thirty two bits of the
random number generator result bitwise
left, shifting them by 12 and then
extracting the lower 24 bits.
And the problem already here is the fact
that the application of this Bednarski
contributes at most 12 bits of entropy
to any address randomizer
in this fashion, regardless of the
quality of the Beringia in general, which
is worse, as we'll see in a minute.
The second of these functions that
randomize well, as the name says it
randomizing start addresses when a stock
is allocated, either when the process is
started or when the new threat is
created.
It does this in the same fashion as the
previous function. By subtracting a
random value from the original stack
pointer, it takes a lower thirty two bits
of the random number generator result, as
you can see on the right of the slide.
Then bitwise left shifted by four
and then at most extracts the lower
eleven bits depending of the size of the
allocated stack.
And this contributes to do the bit and
ask again at most seven bits of entropy,
which is also worse in practice.
This is mitigated a little bit because it
is combined with the results of the
previous function, because under the
hood, of course, the stack is also
allocated using map, but in practice
this won't matter.
A lot will take a sip of
water.
So it is actually these operations
are quite optimistic because QNX
six is Alara uses a very weak
Beerenberg.
You can't really call it a beer engie
because they directly use a source of
entropy called clock cycles.
And as you can probably guess, it
maintains and retrieves a 64
bit life running cycle calendar.
And the implementation of this is
architecture specific.
So on the right of the slide, you can see
that on Zaidee six, it will simply
use the timestamp counter instruction
and for PowerPC it will use time based
facility and various other kinds of
architecture specific options.
Now, the first thing that springs to mind
is the fact that if you want to guarantee
memory, layout secrecy using a Enzler,
then you will also need to keep the
internal state of the Birinyi secret,
because that might allow people to
reproduce the Enzler settings of a given
point in time, because there is no
Beerenberg here, but just the raw entropy
source. That means that in that scenario,
clock cycles would have to be a secret
value, which of course it is not.
It can be requested with unprivileged
access. It's incorporated in a lot
of different kind of drivers in network
packets broadcasted all over the network.
So in theory, you could mount a
reconstruction attack.
But that's overkill and kind of involved,
considering the fact that it doesn't
contribute, although a lot of entropy and
another approach is much more feasible
for breaking it.
So we measured various kinds of processes
across different boot sessions and
harvested the memory object addresses.
Then we use the next entropy source
testing tool to obtain a min entropy
estimate for all of these memory object
addresses in different kind of classes.
And here it is good to realize that 256
bits of uniformly random data should
correspond to 256 bits of main
entropy. And we found that the average
min entropy of an
address on QNX six was four point forty
seven bits, with the lowest
in entropy being three bits for SHERRARD
libraries and the highest six bits for
the stack.
And this is very, very weak if you
compare it to other 32 bit operating
system. So you can see on the right of
the slide, for example, from mainline
Linux, varying between eight bits of
entropy and 19 minutes, or
for example, Linux would be Backes
patches where you vary between six
bits and even twenty seven bits.
And why is this a problem, you might ask?
Well, this is a problem because of the
potential of brute forcing.
So if you have a typical
networking demon where you have a forking
architecture and let's say that upon
every income and connection, you spawn
a new child to handle this,
this client connection and a phone call
will be called. And because of memory,
layout, inheritance, a child process
will have a copy of the parent process
memory layout, because this is applied
after a law has been applied.
That means that there is a law.
Randomization is also copied to the
child, which is static every time this
child is respond.
Now, an attacker trying to guess
the address for a certain code
address, for example, might try and
address and measure the response in
whatever way.
And if the child crashes and is
restarted, they can try the next address.
And if there is not enough entropy in the
randomization of these addresses, they
might succeed either locally or
remotely or both within a reasonable
time frame to discover the address is
needed to build.
Are a B Jane.
And does this work in practice, you'll
ask? Well, you can see on this slide that
in fact, it does.
On the left, you have a vulnerable
service which runs on the network
porch one three three seven.
It is a trivial stack buffer overflow.
It has a isela enabled.
And on the right you can see it remotely
being exploited over the network.
Brute forcing a Isaula in twenty three
seconds to.
So yes, that works in practice.
Of course, brute force is less
interesting, but memory
information leaks are even more
interesting.
Typically, you find an information leak
in the application you're targeting or
you craft one from a flexible enough
vulnerability.
But it's nicer, especially for local
vulnerabilities, to have a system wide
information leak in this case.
We'll discuss two.
But there are many, many more of this
kind in QNX,
QNX. The first information leak we
discovered is the information leak.
And this basically works by relying
on the fact that QNX, like many Unix like
operating systems, has a process file
system. And here you have dedicated
entries for each running process on the
system. And you can enter interact
with these different entries using the
deficit, the API, or you can request
information like the register values
or stack addresses and or general
memory mapping layout in general.
And as you can see on the slide,
conveniently, these entries are,
regardless of of privileges or
whatever, are willed, readable.
So that makes it very easy to
write a very simple application that
across privileged boundaries for a low,
privileged user discloses the memory
layout of the micro kernel.
On the right you can see that it is made
even more convenient by the fact that
they include in a lot of QNX releases,
the P ID and utility, which allows
to incorporate this functionality by
default.
So even if you can write your own
application and drop it on a system
to exploit this information leak, you
might just be in luck and find this
utility there to do it for you.
The second information leak we found is
residing in the debug environment
variable. This is an environment variable
which allows you to specify various
requests for debugging information.
And if you specify the all option, then
it will give you a lot of debug
information among which are the addresses
of shared libraries.
And the interesting thing is that on, for
example, Linux or DVD,
this option has privileged checking.
So if you tried to do this for a set you
idea binary and you're not a road
user, then it will
not output that information.
But on QNX, no such checks are present
and you can obtain this information
across privileged boundaries, which makes
exploding wide binaries that much
easier.
So.
After we reported some of this stuff,
they made improvements to QNX seven
and QNX seven and now has
still has disabled Azara, there's
no Casula, but they do use a new
colonel beer that Ali just discussed.
And that's good.
But it doesn't make you seven
Azle are much stronger despite
this new orangy and despite the fact that
they have a 64 bit address space,
they forgot to remove these bit markings
that are applied to the randomization
functions. So as a result, you'll still
have a theoretical upper bound of seven
bits of entropy for STAC addresses
and 12 bits for the various
virtual memory addresses, or most of them
as they are allocated.
Another interesting thing to note you can
see on the right of the slide is the fact
that Gode memory is mostly loaded in the
lower 32 bits of the space,
which also greatly reduces the potential
effectiveness of as 64 bit
operating systems.
And it did fix the debug information
leak, but unfortunately for
defenders and fortunately for attackers,
they did not completely fix the progress
info leak.
So as you can see on QNX seven above
you, you can no longer use
the ID and utility.
But if you're just writing your own
application, compiling it and interacting
directly with the events, you can still
disclose this information across
privileged boundaries.
So this is an information leak, freedom
to use.
The next litigation I'd like to discuss
our state economies, they protect against
traditional linear stock buffer overflow,
which are much more interesting on
embedded systems than they should be
for the people unfamiliar with it.
It basically works as follows.
You generate a master gunnery value using
a random number generator and again, you
keep it secret.
And you inserted between the local
variables like a local data buffer
and the safe return address on the stack.
And ideally also other stack made it
out of variables.
So when an attacker then overrides the
safe return address and upon return of
the function, traditionally you hijack
contraflow.
But here first, the safe country
is checked against the master gunnery.
And if a mismatch is detected, instead of
returning to the safe return address,
you instead invoke a violation
handler and thus prevent contraflow
hijacking.
Now, QNX uses the Duke's
text smashing protector implementation
of State Guarneris, so on the compiler
side, it's what we're used to in in
Linux or BSD, for example,
and that's mostly OK.
But on the operating system side
of the implementation, it's all custom.
And that's where the problems start
because the userspace master cannery is
generated. That program start up when
Lipsey is loaded.
Now, typically in the GC implementation,
it uses Lippe as a Spaceguard setup
function to regulate this.
And then on various platforms, they have
sometimes differing implementations.
But it's it's mostly the same
on Linux, for example, QNX.
However, it uses a custom in a googlies
function. And that's where the problem
lies because again, it uses a weak
random number generator, address entropy
from three sources.
As you can see on the bottom of the
slide. It uses, again, clock cycles.
And it combines this with a local STAC
variable address and the address of the
function itself.
Now, these last two only contribute any
entropy if a isela is enabled.
And again, even if Ezola has enabled,
their entropy relies on the clock cycles
as well.
So we decided to evaluate the kind of
women entropy across three configurations
without Isela, with a Islah,
but without position independent
executables and with a Isaula and with
position independent executables and
found mean entropy on average of the
calories to be seven point seven nine
bits. And Enzler had no noticeable
influence here.
And this is less than ideal because using
a Xperia and they should have had
at least twenty four bits of entropy.
If, like in this case, they include
one null byte in the 32 bit Ganzouri
or if they used a full generator,
should have had thirty two bits of
entropy. And again, this is a problem
because of brute force attacks against
cannery's.
And Colonel Space, however, the problems
are even worse because the micro
journalists neither loaded nor linked
against Lipsey, so the master gunnery in
the colonel cannot be generated by this
innate cookies function.
So they should have implemented a master
gunnery regeneration function in the
kernel. But they forgot to do this.
So the microgrid is protected across
various functions using state cannery's,
but the secondary is never actually
initialized.
And so there are always zero, which kind
of defeats the purpose of having
secondaries in the first place.
Now, we reported these issues through to
BlackBerry, and they're now enabled by
by default secondaries.
They also generate 64 bit
cannery's on 64 bit operating system.
And for userspace cannery's, they mix in
an alpha auxiliary vector value
based on our best practice suggestions by
taking a 64 bit random number generator
value from the kernel, appearing and
transporting it to the userspace process
to mix in would be in it gooky stuff
and the kernel space.
QNX now concatenated to 32 bit
kernel Berenger values during very early
Bhoot and creates a cannery
out of that. So basically Cannery's at
least are fully fixed now.
And that's good news for the vendors at
least.
That brings us to the final litigation
relocation, Read-Only or Roro,
the way this works, you can see on the
right of the slide is that dynamically
linked binaries use relocation to the
runtime lookup of symbols and shared
libraries.
So if you have a function during runtime
and you have it in a shared library, once
you hit that function, it will be looked
up and the address will be stored in the
global offset table.
Now, for obvious reasons, this relocation
data is a popular target for overwriting
to hijack control flow, mostly because
these addresses tend to be static
regardless of the law.
And because of the fact, obviously, that
once the control flow hits that
particular function, then you can hijack
control flow in order to mitigate this
partial Roro was invented, which works
by reordering the internal data sections
and making them precede the program data
sections and then making them read only
after relocations have been done.
So attackers during runtime can no longer
override these entries.
Now, the problem here is because
of something called lazy binding.
Lazy binding means that most of these
symbols won't be looked up at program
time, but during program runtime
and as a result, the global offset table
will remain writable during runtime.
Now you'll have to relocate
or have to relocate.
You have to make sure that this does not
happen. How do they do that?
They do it by disabling line, lazy,
binding and then making the build.
Got Read-Only a program startup.
They implemented this on QNX six, and
that's that's very nice, but the problem
is that their implementation turned out
to be broken. So as you can see on the
left is what it looks like in Debian and
what it should look like.
There you have all the internal data
sections precede the program data
sections and are covered by the Roro
Segment and made Read-Only right
on the right. You have the QNX six point
six implementation for the same
application where you can see that only
some of the internal data sections
precede the program data section and
a global offset table, which is the most
interesting of the overwriting targets,
actually does not precede the
program data section.
As a result, it's not covered by the
READ-ONLY segment.
And regardless of your settings
and your linker, you will be left
vulnerable to this attack, even if
railroader has been enabled.
And the root cause of this is the fact
that they did not do proper link or
section reordering.
In practice, it looks like this on the
left again, you have your full railroad
enabled and you can no longer ride to
global officer table entries.
On the right you have QNX, your full
railroad enabled, and you can ride to
global offset table entries.
So that's a broken mitigation right
there.
On top of that, we also found a local
bypass, although, again, the elder
debug environment variable turns out to
have an undocumented function called
imposter, which allows us
to disable Roro for whatever
reason without any privilege checks
whatsoever.
And this is very nice, of course, for
exploiting vulnerable ID binaries.
And as you saw in one of the first
slides, there are a lot of these in the
history of QNX.
So this is actually very nice in
practice.
Um, both of these issues were reported to
BlackBerry and are now fixed with patches
for QNX, six point six and seven.
So that's good news.
That brings us to the final remarks.
So we disclosed all of the issues we
discussed today to BlackBerry, most of
these issues are fixed in seven batches
are available for some of these issues
and given a six point six, as you can see
in the link in the bottom and the table,
that's displayed a word of warning,
though, due to both the fenders and
attackers. Most of these patches
will take a long time to filter down to
the original equipment manufacturers
and the end users, especially for deeply
embedded systems, which might be a couple
of of minor release versions of QNX
behind. You'll have to upgrade all the
way to QNX six point six and then apply
to patches, roll out the firmware update.
So these issues might be encountered for
a long time in the wild.
Concluding most of the mitigations
turned out to be OK on the toolchain
side, but that's mostly because they
relied on to see where the problems
were really found.
And this is not just the QNX thing, but
this is generally an embedded thing
is on the operating system side.
And why is this the case?
Because QNX cannot benefit directly
from any work that's done in
General-Purpose Operating System security
because it cannot be easily ported one to
one from Linux or Windows
to QNX because of a very different
architectural lineage.
And a result is homebrewed DIY
mitigations, which turn out to be not
as good as you'd want them to be.
And what's also really evident, if you
look at these issues and other
vulnerabilities that you find here, is
the lack of prior attention by security
researchers. A lot of vulnerabilities
feel like they're from the early 2000s
and the information leaks are really
evident of this.
And again, as a word of warning to many
people and had random number generator
design remains difficult.
Many of the Entropia issues in the
embedded world, lack of proper entropy
sources mean that the design burden
is often placed on the system
integrators, regardless of the good
intentions of operating system designers.
On a more positive finishing note, QNX
at least attempts to keep up with
general-purpose operating security, which
is more than can be said of most embedded
operating system vendors, which don't
have any explo medications whatsoever, as
I discussed in my doc at this year's
hardware conference.
And they had a very quick and extensive
vendor response, sometimes directly
integrating our feedback into our new
code.
And as a finishing note, I'd really
like to call for more attention to
embedded operating system security in
general, if we ever want to hold them to
the standards will hold our laptops,
desktops, servers and smartphones to
which we shoot for things that are
deployed in cars, critical infrastructure
and military systems.
And you can also look forward to more QNX
stuff in the future from US and
in Brussels.
Fans of Black Hat and Infiltrate.
So with that, if there's any questions,
I'd like to take them now.
So.
Thank you, Ali Abbassi,
Upworthy.
And
now we have some time for Q&A,
you can just line up on the microphones
here, here, here and back there.
I got one on Mike five.
We'll start with you.
Probably did the very first Yucel
and then Colonel Exploitation work on
QNX. I feel a bit left out
of one of your slides.
Oh, that was not my intention.
What is your name or nickname?
Thanks.
Any any other questions?
Oh, there, I guess,
for the issue where the security
wasn't set up properly for the colonel,
was that an issue or wasn't set up at all
or where something like it wasn't
persisted or reclaimed out of
thread local storage to actually be
placed in the spot for it on the
stack?
So the problem is that the
way they implemented it is they had no
initialization routine at all for the
master gunnery.
So there were references to the gallery
all across the microgrants, but it was
never actually initialized.
And because the micro kernel secondary
was located in business, which was
initialized to all zeros and very early
Bhoot, that means that it was predictably
zero all the time.
And, you know, they used it but never
initialized it. So it's very predictable.
Anybody else with questions, don't
be shy, come on.
Well,
if there aren't any questions left,
right.
Thank you very much for often talk to
your doctor
about that.