Date: Sat, 23 Jul 2011 04:27:08 +0000
From: halfdog <me@...fdog.net>
To: Dan Rosenberg <dan.j.rosenberg@...il.com>
Cc: full-disclosure@...ts.grok.org.uk
Subject: Re: Multipath-ROP: Tools available?

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Dan Rosenberg wrote:
> On Thu, Jul 21, 2011 at 3:15 AM, halfdog <me@...fdog.net> wrote:
>> ... Multipath-ROP: Try to find different ROP-instruction blocks
>> that are separated by the ASLR memory randomization unit size, e.g.
>> 1 page on linux. Without the knownledge of ASLR state, this will
>> represent different ROP-programs. The idea is to find a set of
>> input data set that corresponds to a set of instruction pathes,
>> that all lead to the same result, e.g. the jump to one de-ASLRed
>> memory address. Hence using this technique, it is possible to do
>> multiple memory guesses in one program run, increasing the odds
>> against ASLR (decreasing the entropy of ASLR). ... Does someone
>> know about this method? If there are no tools available for that, I
>> would like to create one, that uses markov-chains for library 
>> analysis and that should support multiple CPU-archs.
>> 
> 
> It's a good idea, but my first thought is the likelihood of 
> significantly reducing entropy seems pretty low.  Of course, a tool 
> would have far more exhaustive coverage in finding such gadgets as 
> compared to my preliminary manual inspection of a few sample
> binaries, but depending on the size of the binary, I'd expect you to
> only find a small handful of instances of parallel ROP gadgets.  And
> when you only find a few instances, it doesn't really do any good at
> all, because unless you can find parallel instruction sequences for
> the entire ROP vocabulary needed for your exploit, you'll still have
> a dependency on one particular guessed base.
> 
> Even if given the benefit of the doubt and you actually manage to
> find two series of instructions sequences that perform your entire
> ROP payload, you've only succeeded in reducing entropy by a single
> bit, which will give you a statistical advantage over not doing it
> but still leave you with an exploit that is unlikely to succeed on
> one attempt.  If you have many attempts (such as in Apache, I'm
> assuming), then it's probably still easier to construct a single ROP
> payload and brute force the base instead.
> 
> On the other hand, if you do decide to implement this (or wait for 
> Stefan's version), I'd be very interested in its performance.

I tried to create a minimalistic implementation that still needs massive
manual work, but could be a start. If found a target sequence in libc,
so that 5 different library load offsets all lead to storage of the
library load offset in %ebp and jump of to the next de-aslred address
(only 4 out of 5, I'm to tired to do the 5th address also) - currently
all set to 0x41414141 for debugging. A better analyzer could perhaps
improve the number of targets and alternative execution pathes.

See
http://www.halfdog.net/Security/2011/ReturnOrientedProgrammingTechniques/

- -- 
http://www.halfdog.net/
PGP: 156A AE98 B91F 0114 FE88  2BD8 C459 9386 feed a bee
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFOKk04xFmThv7tq+4RAunpAJ4uGyOsPei2Kn/irogQR6bOQugyPgCfQPBk
HgDARYX+Po3QPYsjs2SFlMw=
=6UkK
-----END PGP SIGNATURE-----

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/

Powered by blists - more mailing lists