full-disclosure - Re: Multipath-ROP: Tools available?

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>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date: Thu, 21 Jul 2011 08:04:18 -0400
From: Dan Rosenberg <dan.j.rosenberg@...il.com>
To: Stefan Esser <stefan.esser@...tioneins.de>, halfdog <me@...fdog.net>
Cc: full-disclosure@...ts.grok.org.uk
Subject: Re: Multipath-ROP: Tools available?

On Thu, Jul 21, 2011 at 3:37 AM, Stefan Esser
<stefan.esser@...tioneins.de> wrote:
> Hello,
>> 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.
> As far as I know there are no tools available for this.
>
> However I submitted a talk to HITB2011KUL about exactly this technique
> applied to iPhone exploitation. So there should be a tool for this in
> October.
> Not only covering exploiting ASLR but also ROP payloads that work
> against different devices (different library load offset by device
> class/firmware version).
>

Stefan - care to comment on how effective this is?  It seems like 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 parallel 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, I'd be very interested in looking at an implementation.

Regards,
Dan

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

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