Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date: Tue, 16 Jul 2013 00:15:12 +0200
From: Hector Marco <>
Subject: Re: CVE-2013-4788 - Eglibc PTR MANGLE bug

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.

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
> 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
> address.
> 4.- Exploit
> 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
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:
>$ ./poc-bug-mangle
>    [+] Exploiting ...
>    [+] hacked !!
>    $
> 5.- FIX
> 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. 
> Patching glibc-2.17:
>    wget
>    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:

Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with undefined -


Powered by blists - more mailing lists

Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.

Powered by Openwall GNU/*/Linux - Powered by OpenVZ