Monorail Project: project-zero Issues People Development process History Sign in
New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.
Issue 96 glibc off-by-one NUL byte heap overflow in gconv_translit_find
Starred by 8 users Reported by cevans@google.com, Aug 21 2014 Back to list
Status: Fixed
Owner:
Email to this user bounced
Closed: Sep 2014
Cc:



Sign in to add a comment
Comment 1 by cevans@google.com, Aug 21 2014
A did some analysis of some of different possibilities that occur with a single NUL byte overflow into the glibc malloc metadata. Some well-commented little test programs are attached. They all evade the glibc metadata hardening runtime checks to either crash at an attacker-controlled address. Or in one case, the malloc API is confused, in a way that defeats ASLR, to returning multiple pointers to the same actual memory.

At the risk of sounding like a cliche, "the possibilities are endless". I didn't go in to detail on the additional code paths available to the attacker, such as:
- malloc consolidation
- corrupting in to the "top" chunk
- corrupting in to free chunks that are in states other than "unsorted"

I conclude that this condition is extremely exploitable. The malloc metadata hardening is very useful for developers, to highlight corruption early and stop the program closer to the root cause. But if an actual attacker has even a slight amount of control, the hardening can be easily sidestepped.
consolidate_forward.c
786 bytes Download
consolidate_backward.c
727 bytes Download
shrink_free_hole_consolidate_backward.c
1.5 KB Download
shrink_free_hole_alloc_overlap_consolidate_backward.c
2.0 KB Download
Comment 2 by cevans@google.com, Aug 22 2014
geohot set up a wargame for actually exploiting this bug, as a team exercise. It was fun. I've lost the reference to the actual wargame server, but essentially the server allowed you to send messages to malloc() buffers of arbitrary size and content; to free() existing buffers; and to do an off-by-one NUL byte write on an existing buffer.

I've attached my well commented solution to geohot's wargame, heapfunn_solution.c. It is expressed in terms of raw calls to the malloc() / free() API, but could easily be ported to the heapfunn API.

I choose to develop on 64-bit Fedora 20, to show that there's nothing magic about the glibc heap protections on 64-bit. We decided to turn off ASLR for the challenge, to keep matters tractable for a wargame-sized challenge, so to pop your gnome-calculator:

gcc heapfunn_solution.c
setarch x86_64 -R
./a.out

-> gnome-calculator like a boss
heapfunn_solution.c
3.5 KB Download
Comment 3 by cevans@google.com, Aug 25 2014
Attaching my working local Linux privesc exploit. It works on my install; will likely need trivial mods to work on _yours_ :)
pkexploit.c
7.5 KB Download
pwn.c
111 bytes Download
Project Member Comment 4 by taviso@google.com, Aug 26 2014
Here is a fixed version portable across installs.
CVE-2014-5119.tar.gz
5.9 KB Download
Comment 5 by cevans@google.com, Aug 26 2014
Labels: -Restrict-View-Commit
Blogged on team blog: http://googleprojectzero.blogspot.com/2014/08/the-poisoned-nul-byte-2014-edition.html
Comment 6 by cevans@google.com, Sep 23 2014
Labels: -Reported-13-Jul-2014 Reported-2014-Jul-13 Fixed-2014-Aug-29
Status: Fixed
This is now fixed.
Sample glibc errata: https://rhn.redhat.com/errata/RHSA-2014-1110.html
Sign in to add a comment