
Dissecting QNX [pdf] - adamnemecek
https://www.blackhat.com/docs/asia-18/asia-18-Wetzels_Abassi_dissecting_qnx__WP.pdf
======
insulanian
I still have the QNX demo disk image (including GUI!) which fits on a floppy
drive.

It's a shame there's no comparable open source OS :(

~~~
wolfgke
For those who want to play around with it:

>
> [http://toastytech.com/guis/qnxdemo.html](http://toastytech.com/guis/qnxdemo.html)

> [https://winworldpc.com/product/qnx/144mb-
> demo](https://winworldpc.com/product/qnx/144mb-demo)

~~~
Fnoord
A word of caution: the first URL doesn't have TLS (HTTPS). None of the links
to the demos have either. The links on Win World PC don't have any checksums.

I actually remember using this demo floppy though, back in those days (the
other impressive Unix-like OS I used back then was BeOS). It was the first
time I stumbled upon Towers of Hanoi. Sadly the main developer of QNX passed
away.

------
Fnoord
Related 34C3 talk [1]. Not sure if there's any news in this PDF. Skimming
through the CVEs mentions 2017 but none from 2018 (34C4 was in December 2017).

[1]
[https://media.ccc.de/v/34c3-8730-taking_a_scalpel_to_qnx](https://media.ccc.de/v/34c3-8730-taking_a_scalpel_to_qnx)

~~~
dfox
The article seems to be a more academic rephrasing of said talk.

------
ahati
Anyone working on QNX based system here?

~~~
Kenji
Yes. I work with QNX6.6 daily. I also worked with QNX6.5 and QNX7.0. It's a
real blast to work with the mikrokernel. It's a really cool system, and the
kernel stability is excellent. Feels good that when a low level driver
crashes, your system just goes on as if nothing happened (except, of course,
the applications that need this driver). Speaking of drivers, the driver
situation on QNX is a bit sad, simply because there are few drivers and the
ones that exist aren't as high quality and well tested because QNX is niche.
Still, if there was a QNX environment that is as progressive as Linux Ubuntu
(concerning GUI, drivers, etc.) and OpenSource, I'd definitely use QNX as my
main OS.

~~~
na85
>QNX is niche

What is the most mainstream or perhaps "least niche" of the real time embedded
OSes?

~~~
anta40
Hmm... BlackBerry 10, perhaps? [https://help.blackberry.com/id/blackberry-
security-overview/...](https://help.blackberry.com/id/blackberry-security-
overview/latest/blackberry-security-overview-html/awi1402930370721.html)

BlackBerry nowadays is... well let's say the mobile world is basically divided
into 2 sides these days: Android and iOS :p

~~~
jjoonathan
What? BlackBerry is realtime? Why?

~~~
monocasa
So you have the option of running the baseband on the application processor to
save costs if need be, among other reasons.

~~~
ahati
You need a hypervisor for that. Qnx brought that later.

~~~
dfox
You don't. Symbian EKA2 platforms (eg. S60 3rd edition and later) used to run
baseband as userspace threads on same core as user applications. I would not
be that surprised if that was main enabler for Nokia E51/52, ie. full-featured
smartphone in executive-phone form factor (small and in the first place thin
candy-bar).

------
sidkshatriya
Opening the link in Google Chrome 68 shows the PDF front page momentarily and
then the browser shows a blank screen.

Is anybody else encountering this problem?

~~~
namdnay
[https://bugs.chromium.org/p/chromium/issues/detail?id=870404](https://bugs.chromium.org/p/chromium/issues/detail?id=870404)

------
ahati
Very insightful. QNX 7 disable aslr maybe because of ASIL support.

~~~
saagarjha
Are you talking about Automotive Safety Integrity Level? If so, how does this
have anything to do with ASLR?

~~~
kristoffer
I don't know why they disabled ASLR, but safety critical systems (and
functional safety people) tend avoid randomization...

~~~
saagarjha
Having code that behaves differently if it's loaded at different addresses
seems like a bug. So by not doing that, aren't you just masking it?

~~~
JdeBP
Presume that you are a software engineer. Your career and other people's lives
depend from your producing systems that operate safely. You also have to make
risk analyses and meet performance goals.

Your operating system executes different program images for every successive
execution of your program, picked in an unpredictable manner.

How do you prove that every possibility passes the safety tests? How do you
measure the risk of this random selection? How do you know when you have done
enough simulation?

How do you match up software randomization with the ISO 26262 concept that all
software faults are systematic and not random as (some) hardware faults are?

How do you prove that memory allocation and execution always meet performance
goals? How do you construct and perform reproducible performance tests? How do
you demonstrate that your measurements are meaningful?

Software engineering in this case involves thinking about all of these
questions and more besides.

* [https://hal.archives-ouvertes.fr/hal-01375451/document](https://hal.archives-ouvertes.fr/hal-01375451/document)

* [https://www.usenix.org/sites/default/files/conference/protec...](https://www.usenix.org/sites/default/files/conference/protected-files/enigma_slides_wetzels.pdf#page=23)

It appears (to me, at least) that the current state of the literature on ASLR
is that it is treated as a succession of theoretical arms races, which new
defence militates against which new attack, and almost no attention is paid to
the concerns of actually deploying it in a larger system; and the current
state of the literature on functional safety is simply "we will assume that
there are no randomization processes in the software" (from an actual paper
presented at ESREL 2016).

~~~
wolfgke
> It appears (to me, at least) that the current state of the literature on
> ASLR is that it is treated as a succession of theoretical arms races, which
> new defence militates against which new attack, and almost no attention is
> paid to the concerns of actually deploying it in a larger system; and the
> current state of the literature on functional safety is simply "we will
> assume that there are no randomization processes in the software" (from an
> actual paper presented at ESREL 2016).

Thanks for your explanation. To give a slightly different perspective on the
quoted paragraph: mitigations such ASLR etc. do not protect against security
bugs, they just make them more "inconvenient" to exploit. So "average script
kiddie" will probably not be able to write an exploit for them. On the other
hand, for well-founded agencies (think 3-letter agencies), these are no
serious hurdles. In this sense, mitigations do not improve security in the
sense of "less security holes". Instead their (probably unintended, though not
undesired) consequence is that mostly well-founded agencies are able to
exploit security holes. Whether this new situation is good or bad for software
security is up to the reader to think about.

~~~
0xcde4c3db
To be more specific about "more inconvenient": I believe part of the intended
effect of ASLR is to make ROP exploit attempts typicaly crash the process
instead of successfully gaining control. This (ideally) brings admin attention
to the system, which attackers generally want to avoid.

~~~
wolfgke
> To be more specific about "more inconvenient": I believe part of the
> intended effect of ASLR is to make ROP exploit attempts typicaly crash the
> process instead of successfully gaining control.

Keep in mind that before ASLR came, there was (and still is) DEP and its
claims that lots of classes of attack were now impossible. The end of this
story was that ROP was invented and hardly anything has changed, except that
ROP code is much more tedious to write (i.e. no problem for well-funded
attackers).

Now we have ASLR and you are probably right that now ROP exploits lead to
process crashes instead. But attackers have already invented new techniques
for circumventing ASLR, such as return-to-plt, GOT overwrite or GOT
dereferencing. Again making it more inconvenient for script kiddies to write
exploits, but again no problem for an attacker who can throw lots of money and
people at the problem.

~~~
reitanqild
> But attackers have already invented new techniques for circumventing ASLR,
> such as return-to-plt, GOT overwrite or GOT dereferencing. Again making it
> more inconvenient for script kiddies to write exploits, but again no problem
> for an attacker who can throw lots of money and people at the problem.

Helmets and bulletproof vests is no match for powerful rifles.

I'm a bit tired of this reasoning here on HN: If it isn't perfect it is
worthless.

I think I can see reasons why a vendor might want to avoid ASLR in safety
critical systems.

But we shouldn't talk down decent protection tecniques that will often save
us.

~~~
wolfgke
> I'm a bit tired of this reasoning here on HN: If it isn't perfect it is
> worthless.

This argument (that "If it isn't perfect it is worthless" does not hold) is
suitable for many topics in life, but in my opinion not for IT security. I can
conceive that this might be one reason, why so many people (explicitly
including politicians) make such bad decisions about IT security.

I might be somewhat paranoid regarding this topic (which is not a bad trait if
you want to work in this area), but let me give my arguments:

First: the fight for secure systems is deeply asymmetric. The attacker side
just needs one working exploit, while the defender side has to ensure that
there exists no security hole. This strong asymmetry really makes it necessary
that the security is as perfect as possible.

Second: if the device is connected to the internet, everyone/every device that
exists in the world can be an attacker. So what you are fighting against is
the whole world. Or in other words: the security of the system that you use
has to withstand the smartness of some of the smartest people in the world.

Let it be stated clearly that this fight is not hopeless as it looks based on
these arguments: for designing the security of your system, you can resort to
the knowledge of many really, really smart people, too: this is what the
various standards (e.g. for cryptography) are about. What you cannot afford is
to tolerate the slightest bit of imperfection in the security architecture of
the system.

TLDR: In security, at least "If it isn't at least nearly perfect, it is
worthless" does indeed hold.

~~~
saagarjha
Cryptography isn't perfect; someone could always guess your private key. But
that doesn't make it useless, since you're hoping that it's just sufficiently
improbable that nobody in their right mind will even try doing it.

~~~
cdcfa78156ae5
> Cryptography isn't perfect; someone could always guess your private key.

Cryptography is a branch of mathematics, and cryptographic systems can be
formally proved to have certain properties, such as being unable to derive the
private key from the content of the encrypted message. That the private key
can be guessed is a trivial observation, and a bad argument for dismissing
formal proofs. ASLR is a hack on a hack that does not tell you anything about
the formal properties of the system.

~~~
wolfgke
> Cryptography is a branch of mathematics, and cryptographic systems can be
> formally proved to have certain properties, such as being unable to derive
> the private key from the content of the encrypted message.

A small correction: All those proofs (if they exist) are relative to
complexity-theoretical conjectures that are (ideally) widely believed to be
true, but open. The only system that I am aware of where an "absolute"
security proof exists is OTP, but this is hardly suitable to use in practice.

