This service will be undergoing maintenance at 00:00 UTC, 2016-08-01. It is expected to last about 1 hours
Bug 985625 - (CVE-2013-4788) CVE-2013-4788 glibc: PTR_MANGLE does not initialize to a random value for the pointer guard when compiling static executables
CVE-2013-4788 glibc: PTR_MANGLE does not initialize to a random value for the...
Status: CLOSED WONTFIX
Product: Security Response
Classification: Other
Component: vulnerability (Show other bugs)
unspecified
All Linux
low Severity low
: ---
: ---
Assigned To: Red Hat Product Security
impact=low,public=20130715,reported=2...
: Patch, Security
Depends On: 990391 990481
Blocks: 985629
  Show dependency treegraph
 
Reported: 2013-07-17 19:40 EDT by Vincent Danen
Modified: 2016-02-04 01:48 EST (History)
11 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2014-06-20 05:04:55 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)
Upstream fix with regression test. (8.32 KB, patch)
2013-07-18 04:59 EDT, Carlos O'Donell
no flags Details | Diff


External Trackers
Tracker ID Priority Status Summary Last Updated
Sourceware 15754 None None None Never

  None (edit)
Description Vincent Danen 2013-07-17 19:40:39 EDT
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
Comment 2 Carlos O'Donell 2013-07-18 01:08:56 EDT
The patch looks like it should work to solve the problem. Though this is a continued reminder that static binaries are a serious security problem since they can't be easily patched.

This is going to need a regression test. We will need pointer guard macros for all machines so the test can examine the pointer guard value and compare against expected results.

Could you please immediately file an upstream issue with glibc and associate the issue with this one?
Comment 3 Carlos O'Donell 2013-07-18 04:59:31 EDT
Created attachment 775204 [details]
Upstream fix with regression test.

Attaching an upstream WIP fix with regression test.

Regression test fails without patch.

e.g.
/home/carlos/tst-ptrguard1-static --command "/home/carlos/tst-ptrguard1-static --child"
differences 0 defaults 0
pointer guard canaries are not randomized enough
nor equal to the default canary value

Regression test passes after patch.

/home/carlos/build/glibc/elf/tst-ptrguard1-static --command "/home/carlos/build/glibc/elf/tst-ptrguard1-static --child"
differences 16 defaults 0

The non-static test passes before and after the patch because the non-static case always has a random pointer guard.

This test only passes on x86-64, all other targets need to implement POINTER_CHK_GUARD to pass the test (and even build at this point).
Comment 5 Carlos O'Donell 2013-07-19 03:44:48 EDT
Upstream:
http://sourceware.org/ml/libc-alpha/2013-07/msg00367.html
Comment 6 Huzaifa S. Sidhpurwala 2013-07-31 02:21:20 EDT
Created glibc tracking bugs for this issue:

Affects: fedora-all [bug 990391]
Comment 20 Fedora Update System 2013-09-26 02:12:52 EDT
glibc-2.18-9.fc20 has been pushed to the Fedora 20 stable repository.  If problems still persist, please make note of it in this bug report.
Comment 21 Fedora Update System 2013-09-27 20:06:56 EDT
glibc-2.17-18.fc19 has been pushed to the Fedora 19 stable repository.  If problems still persist, please make note of it in this bug report.
Comment 26 Tomas Hoger 2014-06-20 05:04:55 EDT
This problem is fixed in Red Hat Enterprise Linux 7.  As this issue only affects static executables, and is not a flaw by itself, rather an issue in the implementation of the protective technology, there is currently no plan to backport this fix to glibc versions in Red Hat Enterprise Linux 6 and older.

Statement:

Red Hat Security Response Team has rated this issue as having Low security impact. This issue is not currently planned to be addressed in future updates for Red Hat Enterprise Linux 5 and 6. For additional information, refer to the Issue Severity Classification: https://access.redhat.com/security/updates/classification/ .

Note You need to log in before you can comment on or make changes to this bug.