Message-ID: <51E47470.1050806@upv.es>
Date: Tue, 16 Jul 2013 00:15:12 +0200
From: Hector Marco <hecmargi@....es>
To: bugtraq@...urityfocus.com, full-disclosure@...ts.grok.org.uk,
 oss-security@...ts.openwall.com
Subject: Re: CVE-2013-4788 - Eglibc PTR MANGLE bug


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



Due to I signed the mail without care with
the line length the mail is not very readable.

In my personal website you can find a
better format.

http://hmarco.org/bugs/CVE-2013-4788.html


Hector Marco.


On 15/07/13 20:21, Hector Marco wrote:
>
> Hi guys,
>
> The following is a bug that we found while we were working around
> stack smashing protection techniques.
>
>
> Title: CVE-2013-4788 - Eglibc PTR MANGLE bug
>
>
> 0.- Description
>
> This bug was discovered in March 2013 while we were developing the RAF SSP
> technique. The glibc bug makes it easy to take advantage of common
> errors such
> as buffer overflows allows in these cases redirect the execution flow and
> potentially execute arbitrary code.
>
>
> 1.- Impact
>
> All statically linked applications compiled with glibc and eglibc are
> affected,
> independent of the operating system distribution. Note that this problem
> is not
> solved by only patching the eglibc, but it is also necessary to
> recompile all
> static executables.  As far I know there are a lot of routers, embedded
> systems
> etc., which use static linked applications. Since the bug is from the
> beginning
> of the PTR_MANGLE implementations (years 2005-2006) there are a ton of
> vulnerable devices.
>
>
> 2.- Vulnerable packages
>
> The bug has been propagated to all the static code compiled with all
> versions,
> on all architectures, of glibc from 2.4 (06-Mar-2006) to 2.17 (Current
> version).
>
>
> 3.- Vulnerability
>
> The vulnerability is caused due to the non initialization to a random
> value (it
> is always zero) of the "pointer guard" by the glibc only when generating
> static
> compiled executables. Dynamic executables are not affected. Pointer
guard is
> used to mangle the content of sensible pointers (longjmp, signal handlers,
> etc.), if the pointer guard value is zero (non-initialized) then it is not
> effective.   An example:  Library functions like "setjmp()" or
> "longjmp()" use
> PTR_MANGLE and PTR_DEMANGLE. These macros are used to protect structures
> like
> jmp_buf. Basically consist on XOR-ing the pointer value with a random
> 32/64-bit
> value. Since the pointer guard (random value) is 0x0 the attacker can
easily
> calculate off-line the value of a target address. By overwriting the "env"
> structure with the pre-computed address the vulnerability is triggered
when
> longjmp() is called and the execution flow is redirected to attacker
> address.
>
> 4.- Exploit
>
> The bug was tested with Debian 7.1 and Ubunu 12.04 LTS and 13.04). I
already
> created a proof of concept to exploit this vulnerability for both 32
and 64
> bits x86 architectures.   The proof of concept poc-bug-mangle.c
redirect the
> execution flow to a function which prompt a shell. This exploit can be
> compiled
> for both i386 and x86_64 architectures. More architectures can be added
> easily
> by adding the correspondent defines. 
>
> Compilation for i386:
>    gcc poc-bug-mangle.c -o poc-bug-mangle -static
>
> Compilation for x86_64:
>    gcc poc-bug-mangle.c -o poc-bug-mangle_32 -static -m32
>    gcc poc-bug-mangle.c -o poc-bug-mangle_64 -static -m64
>
> Execution output:
>    box@....upv.es:~$ ./poc-bug-mangle
>    [+] Exploiting ...
>    [+] hacked !!
>    $
>
>
>
> 5.- FIX
>
> Note that the bug is not solved by only patching the eglibc, but it is
also
> necessary to recompile all static executables. I have created a non
official
> patch ptr_mangle-eglibc-2.17.patch for the gblic-2.17. 
>
> Patching glibc-2.17:
>    wget http://hmarco.org/bugs/patches/ptr_mangle-eglibc-2.17.patch
>    cd glibc-2.17
>    patch -p1 < ../ptr_mangle-eglibc-2.17.patch
>
>
> 6.- Discussion
>
> Although this bug is not exploitable by itself, the truth is that the PTR
> Mangle encryption is useless. The goal of the protection technique is not
> achieved.  This can be seen as the canary stack is set to 0x0, although
> is not
> exploitable by itself is clearly an issue. What about whether the
canary has
> been set to zero from 2006 to today ? This is what happened with the
> pointers
> protected with this mechanism.   According to Ulrich_Drepper to use
> "encryption
> pointers (instead of canaries) to protect structures like jmp_buf is at
> least
> as secure and in addition faster". Following the above and since the
> protection
> mechanism is useless from the first implementation, the number of
> potentially
> affected systems could be huge.
>
> Patch and exploit source code:
>
> http://hmarco.org/bugs/CVE-2013-4788.html
>

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with undefined - http://www.enigmail.net/

iQIcBAEBAgAGBQJR5HRrAAoJEI9kAsYMQl6imCgP/2rT+FZEASHfyB2yDmX3fe8d
EZAa/cATKZscYwZv4dsHt1qrykO0Pe6ksiaBeDyRwsbKtzT6qmxG69P4SEIE04i/
/vle5z60ywFZZGMRpzu+lcI79roVbOndrUcAXWPL66xgHG/zL/WNnSvrN0ehoRWx
VV9biXXXdPB9tmi00EKrn1iy6+CcBGGWZJ8rtxvq27wUsOkIYOzEpUH8fhgbpubs
1NsvFMpWpOjI05YsfT/9xRzJoPbbYpuQo6MgZYYgeVdY3zyxojAAq/64dUJ09UCe
CuxAgB2PSuG5FObHiI5lUBT8baXIBCOSVkz55xwkpLJ/qrqFyT3ULEn7Z331/i3q
cZ/kPldR32esuU+2su5euXlqRcegLx6Bx6zLahVo2EmsFMHB4dUHF7x8fDJFjOCv
5wZgqv5y3dglQAR/zhsvcLpJyKoJc45QuQEry++62nJABajmt5tJSwJHUcKbVP0D
i06AEiAbUI1KJvwZjpvt7aQfkBckA18YoGucUpV9e7nsxcy/Q3Q3cF5svl2jCB61
1hAPZiiLq3oRCQIcDwRjrjM2Ne+Ba5tw1EUQYAMccw+f9BdZrcA8HGCoIce9VQLY
7NSOi4RgAAgmIR0Hcu5CBKQG8GYPcEv0bBDHYrf3epO2L+8qQ1F5KASntrr45siX
Ju8aueJxxsX4knpdCIiQ
=degQ
-----END PGP SIGNATURE-----


Content of type "text/html" skipped

_______________________________________________
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