full-disclosure - Re: MySQL (Linux) Heap Based Overrun PoC Zeroday

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <CAH8yC8=2YqD5i1pubwyofzkRVAgL2FhN74mwZ4WerQ89gH9YEA@mail.gmail.com>
Date: Sun, 2 Dec 2012 17:19:16 -0500
From: Jeffrey Walton <noloader@...il.com>
To: king cope <isowarez.isowarez.isowarez@...glemail.com>
Cc: full-disclosure@...ts.grok.org.uk
Subject: Re: MySQL (Linux) Heap Based Overrun PoC Zeroday

On Sun, Dec 2, 2012 at 10:40 AM, king cope
<isowarez.isowarez.isowarez@...glemail.com> wrote:
> When you look into the heap and stack overrun the first obstacle to
> exploit the bugs is that MySQL does not allow all plain 0 to 255
> characters, this means the exploiter would have to use unicode
> translation in order to exploit the bugs (therefore these are PoCs
> only by now). If the exploiter managed to execute code on default
> installs without your mentioned protections it might be possible to
> circumvent them, to be honest I didn't have a look into these
> optimizations and protections, it's hard enough to exploit it without
> these restrictions applied.
No problem, thanks. Rodrigo pointed out a RO GOT (-z,relro) meant the
GOT would be safe, but other areas were still vulnerable on the heap
overflow. I think I'd take a hardened GOT and make the attacker move
on to the next weak area.

Its really a shame that high risk applications (such as those that
take input from the Internet) are still failing in these ways in 2012.
There's a lot of platform security available (and other hardening
techniques), but folks chose not to use them. It's  disappointing the
various security teams have not improved the situation (they are the
folks who should know, and should take a defensive posture).

Jeff

> 2012/12/1 Jeffrey Walton <noloader@...il.com>:
>> Hi Kingcope,
>>
>> # As seen below $edx and $edi are fully controlled,
>> # the current instruction is
>> # => 0x83a6b24 <free_root+180>:   mov    (%edx),%edi
>> # this means we landed in a place where 4 bytes can be controlled by 4 bytes
>> # with this function pointers and GOT entries can be rewritten to
>> execute arbritrary code
>>
>> Out of curiosity, is this exploitable when using hardened toolchain
>> settings? Specifically, -z,noexecheap, -z,now, and -z,relro? For
>> no-exec heaps., you need to be on Gentoo or other platforms which
>> offer the remediation.
>>
>> Jeff
>>
>> On Sat, Dec 1, 2012 at 4:26 PM, king cope
>> <isowarez.isowarez.isowarez@...glemail.com> wrote:
>>> (see attachment)
>>>
>>> Cheerio,
>>>
>>> Kingcope

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