Message-ID: <20040916005537.GA23205@fist.immunitysec.com>
Date: Wed, 15 Sep 2004 20:55:37 -0400
From: Bas Alberts <bas.alberts@...unitysec.com>
To: full-disclosure@...ts.netsys.com
Cc: bugtraq@...urityfocus.com
Subject: Fwd: Theo's presentation on exploit prevention


Some interesting comments on pro-active security appeared on the daily
dave just now. 

http://lists.immunitysec.com/pipermail/dailydave/2004-September/000918.html

Pasted for your convenience:

[Dailydave] Theo's presentation on exploit prevention
pageexec at freemail.hu pageexec at freemail.hu

Theo's presentation on exploit prevention or the siren [1] sang again.
lest we die in ignorance though, let's look at that song.


slides 1-2:

   we're getting lured into the belief that something genuine is going to
   happen here. we're about to learn how the OpenBSD project smartened up
   finally and copied the intrusion prevention technologies that others had
   developed in the previous few years and more! we're promised a much more
   hostile system environment and backwards compatibility, no less.

   one begins to suspect why the stupid greek sailors all died in the end.


slide 3:

   here we learn in more detail about the noble goals of this effort. it's
   not quite clear how one's supposed to not break behaviour that the apps
   depend on while still prevent the exploits from making use of the same
   behaviour... but let's not rush ahead so fast. we're going to follow
   POSIX and still do nasty nasty things to those attackers - or so the
   song promises.


slides 4-5:

   let's cut to the meat! buffer overflows. to add insult to injury, it's
   the stack based ones. oh, not THEM again. we thought we'd been past that
   for years now! while marveling at the beauty of the 1000th buffer overflow
   depiction we keep wondering when the OpenBSD Team will eventually learn
   about the clever attacker that is exploiting more than buffer overflows.

   anyway, let's look at this old buddy again. we learn that the buffer is
   ALWAYS at the same place. how nice. how secure. stuff like environment
   strings, program arguments and whatnot surely have no role in the stack
   pointer value. apparently not on OpenBSD. proactive insecurity, isn't it.

   so what shall we do about it? shift the stack by a random amount! where,
   how, how much? apparently on OpenBSD the top of the stack is what normal
   mortals consider the bottom of it... honest to god mistake, we understand
   where the real gap is. at the bottom. no pun intended.

   and then look at those failures! all due to that unbelievable 15 bits of
   randomness OpenBSD managed to cram into that space! and we learn that all
   this costs us at most one physical page of RAM. what we don't learn is
   that it also costs us 256 kB of virtual address space (or more precisely,
   whatever our admin deemed acceptable for his sense of security), but we
   have got plenty of that and as we'll see later, it's a drop in the water
   only (we're sailors, don't miss the pun!) compared to what will follow
   later. so, what is 15 bits of randomness worth really? at one attempt
   a second, it's less than half a day on average (assuming we're actually
   going for the full 15 bits and can't get away with less), for stuff that
   forks only it's even guaranteed in that time. on localhost it's a matter
   of minutes.

   and you're wondering why other vendors haven't picked it up (one wonders
   where OpenBSD picked it up from). maybe because they can count further
   than 15. what about 24, or 32 or whatever the address space reasonably
   allows? sounds better, doesn't it.


slide 6:

   here we learn about the fantastic japanese stuff (great sailors of their
   time) that many in the world, including OpenBSD, have blissfully ignored
   for... a few years at least. but now they have rediscovered the precious,
   and it's all theirs and theirs and... we get this stack overflow focus
   again. the one ring that binds them all. and we forget about information
   leaking bugs that render this and other randomization based approaches
   pretty vulnerable to attack. we also forget about localhost where we get
   unexpected help for this: the kernel (and the nice bugs in it). the best
   use of SSP is in the kernel itself. having a single canary value sitting
   like a duck for the uptime of the system is the best idea men, err, sirens
   could come up with. having it change per process and syscall crosses only
   the minds of mad sailors.


slide 7:

   we can see that SSP found a few exploitable bugs. but where are the
   advisories? surely not swept under the carpet, right?


slides 8-9:

   W^X! no, we didn't want to curse at you, honest! this pearl is the OpenBSD
   attempt at PaX a few years late ([2], [3]), and on the surface it actually
   does what it promises: separate writable (not writeable) pages from
   executable ones unless the program Wants Just That. problem is that as
   any female reader can attest, a boy Wants Just That. including those
   badass blackhats who dare to challenge the security of OpenBSD. and since
   the OpenBSD Team made it the policy to obey the program's wishes, they
   stand a chance to actually wish something very pleasant. no, not that
   (that fish is thorny, not horny), just a r00t shell or the like. but
   let's do things at their own pace.


slides 10-15:

   we've got a bunch of messy diagrams here, no wonder no sailor has ever
   found his way back from here. looks like the author got lost too and
   confused things like ctors/dtors with the C++ language constructs
   (__attribute__((constructor)) is not at all equivalent to C++ class
   constructors).

   first we see that the black sheep in the family a.k.a. the stack (it
   can't even identify its own bottom as we saw above) is executable. and
   all that because someone put the signal trampoline there. so they
   move it to its own page, adding a whole bunch of logic to the kernel
   instead of figuring out that libc could very well host it in its own
   .text, not unlike how any Linux system has been doing it for a few
   years now.

   then come other evil animals that also host writable and executable
   pages. getting rid of them is a matter of splitting them up into their
   own pages so they fall into either of the allowed categories. or change
   between them. as the runtime linker or the application (read: attacker)
   wish. not to mention that mprotect'ing the GOT/PLT on every lazily
   resolved entry must surely be a huge performance benefit and clearly
   superior to the PT_GNU_RELRO approach preferred by RedHat [4].

   last but not least we get to hear about the sad story of i386 where
   per-page non-executable rights are just an impossibility. they seriously
   mean it. look at that monster address space layout. if you consider the
   fragmentation and waste you realize that the 256 kB stack gap pales in
   comparison. while not exactly the semantics one would expect under POSIX,
   we'll happily forgive it because this implementation offers us a true
   gem. the userland code segment comes in only two sizes, and while most
   people learn early to not put all their eggs in one basket (both code
   segment descriptors in the GDT), this old adage has apparently fallen
   on the collective deaf ears of the OpenBSD Team. so what this allows our
   hypothetical attacker to do is a simple return to a 'retf' instruction
   that will further return to the injected shellcode in the all-executable
   code segment... voila, proactive security at its best.


slides 16-17:

   here we are told that i386 is not all that bad provided one uses its
   64 bit cousin and learns to program in PAE mode. apparently the latter
   is a serious challenge for the OpenBSD Team (read: they couldn't just
   lift the code from FreeBSD). so the sirens are now trying to lure the
   unsuspecting vendors into implementing yet another way of doing
   non-executable pages, as if it wasn't already messy enough.


slide 18:

   so what did W^X buy us? security! performance! compatibility! we! all!
   believe! in! sirens! obviously something's wrong here. security concerns
   were discussed above, performance numbers can be hardly argued without
   actually having them... so let's see compatibility. nothing breaks. sure,
   X didn't break either then. including its homegrown module loader that
   every non-executable page implementation ran into over time. and there're
   no OpenBSD specific defines for this reason in the X module loader code
   either. 'cos nothing broke. honest. at least it's fixed now.

   what about JIT engines like in Java? we are told that on split I-D cache
   systems they would not have worked anyway without proper use of msync and
   mprotect. weird, i386 has split caches yet it's never ever needed any of
   these to generate code at runtime. obviously the problem is not the split
   cache itself but that it's not coherent on every system (and some systems
   offer simple userland accessible primitives for flushing the caches, no
   need for expensive syscalls at all).


slides 19-20:

   this one is a true gem as well: library order randomization. we are led
   to believe that it's a worthwile effort. let's see... 'n' libraries can
   be loaded in n! order, that's a nice exponential value in 'n' (one would
   think of more than 'n' bits of extra randomness that an attacker has to
   get right). question is whether that is its true security value as well
   or not. considering that an attacker normally wants to use a single
   library in a ret-to-libc style attack (libc... get it?), we can easily
   conclude that for this purpose the load order will be 'right' once in
   every 'n' attempt. that in turn means that all this gained is log(n)
   bits of extra randomization... hardly worth a mention at all, not to
   mention its cost in code complexity and performance impact in ld.so.

   then we're shown the 'wee bit' of virtual address space that is wasted
   in library base address randomization. heavily fragmented all 256 MB of
   it. double that as the waste is mirrored above the executable limit as
   well (most if not all libraries contain both code and data). that's
   1/6th of the entire address space. a wee bit understated, indeed.


slide 21:

   confused yet? rhetorical question but see, those dumb attackers really
   are, no question about it. they're facing incredible amounts of entropy,
   they can no longer execute their payload, and worst, they are stuck at
   these classic buffer overflows! of course information leaking bugs are
   unheard of in siren land, as are non-linear overflows. and the many
   kinds of memory corruption bugs that the creative human mind comes up
   with.


slide 22:

   good old mmap randomization (3+ years in PaX), except it doesn't only
   depend on the presence of MAP_FIXED but also the address hint (non-0
   hints above p_vmspace->vm_daddr won't be randomized).


slide 23:

   there is hope! apparently someone did hear about heap overflows and
   related exploits in the OpenBSD Team. a pity they haven't actually
   delved in the fine details of it [5], else they would know that adding
   randomization within a page gives only 2-8 bits of randomness, hardly
   a challenge.


slide 24:

   this is probably the most useless security feature one can ever come
   up with. while making .rodata non-executable looks like good housekeeping
   on the surface, it's pretty useless as a security measure. the readership
   is challenged to find (or produce) a real-life bug that cannot be
   exploited except when .rodata is executable. we have yet to see one.

   we also learn the underlying concept of all these address space tweaks:
   the noble goal of least privilege. except the security-challenged OpenBSD
   Team doesn't know that memory protection rights come in pair: one set
   defines the active permissions and another the attainable ones. restricting
   the former only while leaving free reign over the latter means that it
   is possible to circumvent the former. and it wasn't until 3.4 where one
   could call mprotect() with random stack garbage as arguments and have
   the kernel still accept the protection flags it knew about and ignore
   the rest.


slide 25:

   besides the usual trashing of the quality of "Open Source" (one wonders
   if it applies to OpenBSD as well then), we note that there is a reason
   why ElectricFence is not used in production, it just kills performance
   due to the heavy address space fragmentation. and this thing is at least
   a decade old... does everything take this long to be 'discovered' in the
   OpenBSD world?


slides 26-27:

   this is a cool hack! it's not quite clear though what advantage it has
   over SSP given that they both detect the same kind of attacks. and we
   are of course forever indebted for the reference to PaX [3], in those
   hard days when the OpenBSD Team hadn't heard of us for another year or
   two. seriously. they said so therefore it must be true.


slides 28-32:

   least privilege again, this time of more mundane ones, not memory access
   rights. of the two methods, privilege revocation does actually make sense
   however privilege separation (not seperation) doesn't. for noone has a
   bugfree kernel. especially not OpenBSD that wasn't written from scratch
   by its maintainers who have often little idea what a given piece of code
   does. examples like the improper use of the i386 GDT mentioned above and
   other (sometimes not yet public) snafus clearly prove the point.

   so what does a kernel bug do? a good one will allow the skilled attacker
   to run his code with kernel privileges (say ring-0 on i386) and effectively
   circumvent anything that the OpenBSD Team have dreamt up for protection.

   in other words, it doesn't matter where you shift the buggy code, it can
   already exploit any of the kernel bugs to gain whatever privileges the
   attacker needs. put that into the second stage of a normal remote exploit
   and you're back at square one, remote root, whatever way you look at it.


slides 33-34:

   finally, we can see the difficulties facing the defenders:

   - no clear concept let alone implementation against exploits of memory
     corruption bugs (tree vs. forest problem), effectively you can never
     be sure if a given bug is exploitable under these measures and what
     kind of damage it can cause,

   - performance and compatibility information is unreliable, you're still
     best off by simply testing it yourself, that's especially important
     for 3rd party apps that might break due to the unconventional address
     space layout and memory protection semantics,

   - exploitable bugs are fixed silently, how to learn to update then?


this concludes our odyssey and for the rest of you, happy sailing!
just don't forget the earplugs when the sirens begin to sing.


[1] http://dictionary.reference.com/search?q=siren
[2] http://marc.theaimsgroup.com/?l=openbsd-tech&m=97416533704634&w=2
[3] http://stackghost.cerias.purdue.edu/stackghost/node32.html
[4] http://people.redhat.com/drepper/nonselsec.pdf
[5] http://www.blackhat.com/presentations/bh-europe-03/BBP/bh-europe-03-bbp.pdf


_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.netsys.com/full-disclosure-charter.html

Powered by blists - more mailing lists