oss-sec mailing list archives
Re: Offset2lib: bypassing full ASLR on 64bit Linux
From: Steve Grubb <sgrubb () redhat com>
Date: Tue, 09 Dec 2014 11:18:53 -0500
On Friday, December 05, 2014 01:54:35 PM Hanno Böck wrote:
On Thu, 04 Dec 2014 21:19:04 +0100 Hector Marco <hecmargi () upv es> wrote:This is a disclosure of a weakness of the ASLR Linux implementation. The problem appears when the executable is PIE compiled and it has an address leak belonging to the executable. We named this weakness: offset2lib.Thanks for that. Two things on that: Cynics might say "most linux distros aren't vulnerable to ASLR bypass because they don't use ASLR at all". Can we please take this as an opportunity to discuss the state of ASLR on Linux in general?
I studied this area 2 years ago for a gray hat talk and in preparation to help set the policy going forward for Fedora and RHEL. The general reason I've heard mentioned about why its not used as fully as possible is that it adds memory pages that can't be coalesced or consolidated because they are not the same. For Fedora and RHEL 7, the intended policy is PIE for all daemons, privileged apps, network facing, and parsers of untrusted media. Enforcement is not so easy. How do you identify in an automated way parsers of untrusted media? I have a script that can grade an installed system that uses rpms: http://people.redhat.com/sgrubb/files/rpm-chksec It has options to grade the system or an individual rpm for compliance with the intended policy. During my research, I found a couple interesting things. These ASLR related tidbits below are pulled from the speech I gave about when open source security mechanisms don't work as intended (all measured on a 64 bit system): 1) On non-PIE applications, the heap doesn't get much randomization. Just 14 bits. 2) Also non-PIE applications seems to be some bias in the numbers chosen. This could be an effect of 14 bits of randomization. It did follow a bell curve such that guessing some addresses was much luckier than others. (I did not get a sample size large enough on PIE apps to see if the same bias could be measured.) 3) When using PIE, you pretty much got 29 bits of randomness everywhere. That lead to the question of why the heap on non-PIE is so limited in address scope. As I remember, there was some coupling with sbrk() that caused this....which might need revisiting. 4) Then I started wondering about the heap when you use other memory manager libraries such as jemalloc. This turned out to be interesting. You get about 19 bits of randomness using it. Its not as bad as non-PIE glibc but not as good as PIE glibc. You also got the same amount of randomness whether the app was PIE or not. This is an area ripe for more experimenting, exploiting, and patching. Supposedly some of these heap managers use mmap as the underlying allocator. So, why aren't they getting 29 bits, too? :-) Here's the current numbers from 3.17.4 kernel + glibc-2.18: $ ./all-bits heap 14 bits exec No randomization mmap 29 bits so No randomization stack 28 bits pie-exec 29 bits pie-heap 29 bits pie-so 29 bits $ ./all-mask heap 0x0000000003FFF000 exec 0x0000000000000000 mmap 0x000001FFFFFFF000 so 0x0000000000000000 stack 0x00000000FFFFFFF0 pie-exec 0x000001FFFFFFF000 pie-heap 0x000001FFFFFFF000 pie-so 0x000001FFFFFFF000 -Steve
It's pretty sad, afaik Linux was one of the first to have ASLR (in the form of pax) back in 2001. Today everyone uses ASLR by default except Linux. Most distros don't ship pic/pie executables by default. Why? I haven't done benchmarks, the saying is that this has a notable performance hit on 32 bit but almost none on 64 bit. If this is true then could we at least have all major distros enable it on 64 bit? Second: I wrote a small test .c to print out offset diffs. As expected printf-main offset is static on normal Linux with pic/pie and random on a pax-enabled system. What i found notable: diff-ing two function offsets from different libraries (I use printf-sin) is alway static, even on Pax. Is this by design? Can't different libraries be loaded at different offsets in ram?
Attachment:
signature.asc
Description: This is a digitally signed message part.
Current thread:
- Re: Re: Offset2lib: bypassing full ASLR on 64bit Linux, (continued)
- Re: Re: Offset2lib: bypassing full ASLR on 64bit Linux Daniel Micay (Dec 05)
- Re: Offset2lib: bypassing full ASLR on 64bit Linux Seth Arnold (Dec 05)
- Re: Offset2lib: bypassing full ASLR on 64bit Linux Daniel Micay (Dec 05)
- Re: Offset2lib: bypassing full ASLR on 64bit Linux Hanno Böck (Dec 06)
- Re: Offset2lib: bypassing full ASLR on 64bit Linux Pavel Labushev (Dec 05)
- Re: Offset2lib: bypassing full ASLR on 64bit Linux Daniel Micay (Dec 05)
- Re: Offset2lib: bypassing full ASLR on 64bit Linux Reed Loden (Dec 05)
- Re: Offset2lib: bypassing full ASLR on 64bit Linux Daniel Micay (Dec 05)
- Message not available
- Re: Offset2lib: bypassing full ASLR on 64bit Linux Daniel Micay (Dec 05)
- Re: Offset2lib: bypassing full ASLR on 64bit Linux Florent Daigniere (Dec 06)
- Re: Offset2lib: bypassing full ASLR on 64bit Linux Daniel Micay (Dec 09)
- Re: Offset2lib: bypassing full ASLR on 64bit Linux Daniel Micay (Dec 09)
- Re: Offset2lib: bypassing full ASLR on 64bit Linux Loganaden Velvindron (Dec 09)
- Re: Offset2lib: bypassing full ASLR on 64bit Linux Steve Grubb (Dec 10)
- Re: Offset2lib: bypassing full ASLR on 64bit Linux Daniel Micay (Dec 10)