Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 477330 (CVE-2013-4788) - <sys-libs/glibc-2.19-r1: PTR_MANGLE does not initialize to a random value for the pointer guard when compiling static executables (CVE-2013-4788)
Summary: <sys-libs/glibc-2.19-r1: PTR_MANGLE does not initialize to a random value for...
Alias: CVE-2013-4788
Product: Gentoo Security
Classification: Unclassified
Component: Vulnerabilities (show other bugs)
Hardware: All Linux
: Normal minor (vote)
Assignee: Gentoo Security
Whiteboard: A1 [glsa cleanup]
Depends on: 518364
  Show dependency tree
Reported: 2013-07-18 19:05 UTC by Agostino Sarubbo
Modified: 2015-03-08 14:53 UTC (History)
2 users (show)

See Also:
Package list:
Runtime testing required: ---

glibc-rh985625-CVE-2013-4788.patch (glibc-rh985625-CVE-2013-4788.patch,16.30 KB, patch)
2014-07-27 19:08 UTC, Andrey Ovcharov
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Agostino Sarubbo gentoo-dev 2013-07-18 19:05:07 UTC
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].


@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.
Comment 1 GLSAMaker/CVETool Bot gentoo-dev 2013-10-06 23:31:14 UTC
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.
Comment 2 SpanKY gentoo-dev 2014-02-18 19:23:08 UTC
i've cherry picked this into the glibc-2.18 patchset
Comment 3 Andrey Ovcharov 2014-07-27 19:08:48 UTC
Created attachment 381676 [details, diff]
Comment 4 SpanKY gentoo-dev 2014-08-05 03:52:54 UTC
Comment on attachment 381676 [details, diff]

(In reply to Andrey Ovcharov from comment #3)

we don't deal in random patches ... just links to the upstream git repo
Comment 5 Yury German Gentoo Infrastructure gentoo-dev 2015-03-03 03:38:40 UTC
Maintainer(s), please drop the vulnerable version(s).

Added to an existing GLSA Request.
Comment 6 GLSAMaker/CVETool Bot gentoo-dev 2015-03-08 14:53:55 UTC
This issue was resolved and addressed in
 GLSA 201503-04 at
by GLSA coordinator Kristian Fiskerstrand (K_F).