-----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: > [email protected]:~$ ./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-----
_______________________________________________ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
