[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
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-----
Powered by blists - more mailing lists
Please check out the
Open Source Software Security Wiki, which is counterpart to this
mailing list.
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
