glibc off-by-one NUL byte heap overflow in gconv_translit_find

[GoogleCodeExporter]

See:
https://sourceware.org/bugzilla/show_bug.cgi?id=17187
http://www.openwall.com/lists/oss-security/2014/07/14/1

Original issue reported on code.google.com by cev...@google.com on 21 Aug 2014 at 2:12

[GoogleCodeExporter]

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.

Original comment by cev...@google.com on 21 Aug 2014 at 9:28

Attachments:

• consolidate_backward.c
• consolidate_forward.c
• shrink_free_hole_consolidate_backward.c
• shrink_free_hole_alloc_overlap_consolidate_backward.c

[GoogleCodeExporter]

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

Original comment by cev...@google.com on 22 Aug 2014 at 2:20

Attachments:

• heapfunn_solution.c

[GoogleCodeExporter]

Attaching my working local Linux privesc exploit. It works on my install; will 
likely need trivial mods to work on _yours_ :)

Original comment by cev...@google.com on 25 Aug 2014 at 9:54

Attachments:

• pkexploit.c
• pwn.c

[GoogleCodeExporter]

Here is a fixed version portable across installs.

Original comment by tav...@google.com on 26 Aug 2014 at 12:58

Attachments:

• CVE-2014-5119.tar.gz

[GoogleCodeExporter]

Blogged on team blog: 
http://googleprojectzero.blogspot.com/2014/08/the-poisoned-nul-byte-2014-edition
.html

Original comment by cev...@google.com on 26 Aug 2014 at 2:00

• Removed labels: Restrict-View-Commit

[GoogleCodeExporter]

This is now fixed.
Sample glibc errata: https://rhn.redhat.com/errata/RHSA-2014-1110.html

Original comment by cev...@google.com on 23 Sep 2014 at 6:25

• Changed state: Fixed
• Added labels: Reported-2014-Jul-13, Fixed-2014-Aug-29
• Removed labels: Reported-13-Jul-2014