mailing list archives
Re: CVE-2013-4788 - Eglibc PTR MANGLE bug
From: Hector Marco <hecmargi () upv es>
Date: Tue, 16 Jul 2013 00:15:12 +0200
-----BEGIN PGP SIGNED MESSAGE-----
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
On 15/07/13 20:21, Hector Marco wrote:
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
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
as buffer overflows allows in these cases redirect the execution flow and
potentially execute arbitrary code.
All statically linked applications compiled with glibc and eglibc are
independent of the operating system distribution. Note that this problem
solved by only patching the eglibc, but it is also necessary to
static executables. As far I know there are a lot of routers, embedded
etc., which use static linked applications. Since the bug is from the
of the PTR_MANGLE implementations (years 2005-2006) there are a ton of
2.- Vulnerable packages
The bug has been propagated to all the static code compiled with all
on all architectures, of glibc from 2.4 (06-Mar-2006) to 2.17 (Current
The vulnerability is caused due to the non initialization to a random
is always zero) of the "pointer guard" by the glibc only when generating
compiled executables. Dynamic executables are not affected. Pointer
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
PTR_MANGLE and PTR_DEMANGLE. These macros are used to protect structures
jmp_buf. Basically consist on XOR-ing the pointer value with a random
value. Since the pointer guard (random value) is 0x0 the attacker can
calculate off-line the value of a target address. By overwriting the "env"
structure with the pre-computed address the vulnerability is triggered
longjmp() is called and the execution flow is redirected to attacker
The bug was tested with Debian 7.1 and Ubunu 12.04 LTS and 13.04). I
created a proof of concept to exploit this vulnerability for both 32
bits x86 architectures. The proof of concept poc-bug-mangle.c
execution flow to a function which prompt a shell. This exploit can be
for both i386 and x86_64 architectures. More architectures can be added
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
box () iti upv es:~$ ./poc-bug-mangle
[+] Exploiting ...
[+] hacked !!
Note that the bug is not solved by only patching the eglibc, but it is
necessary to recompile all static executables. I have created a non
patch ptr_mangle-eglibc-2.17.patch for the gblic-2.17.
patch -p1 < ../ptr_mangle-eglibc-2.17.patch
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
exploitable by itself is clearly an issue. What about whether the
been set to zero from 2006 to today ? This is what happened with the
protected with this mechanism. According to Ulrich_Drepper to use
pointers (instead of canaries) to protect structures like jmp_buf is at
as secure and in addition faster". Following the above and since the
mechanism is useless from the first implementation, the number of
affected systems could be huge.
Patch and exploit source code:
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with undefined - http://www.enigmail.net/
-----END PGP SIGNATURE-----