It was reported , 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.
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 .
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?
Created attachment 775204 [details]
Upstream fix with regression test.
Attaching an upstream WIP fix with regression test.
Regression test fails without patch.
/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).
Created glibc tracking bugs for this issue:
Affects: fedora-all [bug 990391]
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.
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.
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.
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/ .