From ${URL} : It was reported [1],[2] that glibc and eglibc suffer from a flaw due to the PTR_MANGLE implementations. As described by the reporter: 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. 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. 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. A patch is available from the reporter, but is not yet applied upstream as far as I know [3]. [1] http://hmarco.org/bugs/CVE-2013-4788.html [2] http://www.openwall.com/lists/oss-security/2013/07/15/5 [3] http://hmarco.org/bugs/patches/ptr_mangle-eglibc-2.17.patch @maintainer(s): after the bump, in case we need to stabilize the package, please say explicitly if it is ready for the stabilization or not.
CVE-2013-4788 (http://nvd.nist.gov/nvd.cfm?cvename=CVE-2013-4788): The PTR_MANGLE implementation in the GNU C Library (aka glibc or libc6) 2.4, 2.17 and earlier, and Embedded GLIBC (EGLIBC) does not initialize the random value for the pointer guard, which makes it easier for context-dependent attackers to control execution flow by leveraging a buffer-overflow vulnerability in an application and using the known zero value pointer guard to calculate a pointer address.
i've cherry picked this into the glibc-2.18 patchset
Created attachment 381676 [details, diff] glibc-rh985625-CVE-2013-4788.patch
Comment on attachment 381676 [details, diff] glibc-rh985625-CVE-2013-4788.patch (In reply to Andrey Ovcharov from comment #3) we don't deal in random patches ... just links to the upstream git repo
Maintainer(s), please drop the vulnerable version(s). Added to an existing GLSA Request.
This issue was resolved and addressed in GLSA 201503-04 at http://security.gentoo.org/glsa/glsa-201503-04.xml by GLSA coordinator Kristian Fiskerstrand (K_F).
