lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [day] [month] [year] [list]
Date: Thu, 21 Jul 2011 17:54:26 +0000
From: halfdog <me@...fdog.net>
To: Dan Rosenberg <dan.j.rosenberg@...il.com>, 
	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:
>> Out of personal interest, I am currently trying to exploit a 
>> buffer-overflow in apache using ROP. ...
> 
> I'm assuming this is an Apache local, where you've got local access 
> as some user and want to gain the privileges of the Apache process 
> (which is often unprivileged anyway?)  ...

You are right, you need something like ftp-access to the data and some
other constraints met first. Only ssl-data or other-user's basic auth
data stealing would be of interest, the other data should be available
to an ftp-like setup anyway.

>> The idea:
>> 
>> Let's assume, ....
>> 
>> 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.

No, I'm not hoping to rebuild the complete vocabulary. I hope that it is
possible, to find some "configurable" vocabulary, that e.g. uses the
content of one register as offset to the library and use the multiple
path technique to fill that configuration register. E.g. consider two
sequences separated by one page

page=a: pop eax; ret
page=b: pop pop esi; pop ebx; pop eax; ret

Stack content: [offset of lib-version a] [return address in version a]
[offset of lib-version b] [return address version b]

These two sequences will initialize eax with the liboffset value and
always jump to the correct next return address. If the next piece
contains a "configurable" words using eax, one could use it there. I
haven't searched for best patterns for "configurable" words, but at the
moment I hope that there might be enough of these.

Using some "add %esp,imm8; ret" words, one can correct the different
stack offsets, e.g. by putting that "correction" word at [return address
in version a]. I found enough of these so far.

> 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.

I guess, you are right. I'm just thinking a bit more on it and will
attempt to find enough "configurable" words and if found 3 or 4 parallel
pathes in libc.

- -- 
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)

iD8DBQFOKGeuxFmThv7tq+4RAp18AJ9O0yq0c6LVHZDWLx/hgqBZU/9mwQCeNDAq
SFHTOTisYKGI+I95+/MawRE=
=KT6W
-----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

Powered by Openwall GNU/*/Linux Powered by OpenVZ