Date: Fri, 12 Aug 2011 14:58:24 +0400 From: Solar Designer <solar@...nwall.com> To: kernel-hardening@...ts.openwall.com Subject: Re: [RFC] x86, mm: start mmap allocation for libs from low addresses Vasiliy, On Fri, Aug 12, 2011 at 02:29:54PM +0400, Vasiliy Kulikov wrote: > This patch changes mmap base address allocator logic to incline to > allocate addresses from the first 16 Mbs of address space. These > addresses start from zero byte (0x00AABBCC). Using such addresses > breaks ret2libc exploits abusing string buffer overflows. As library > addresses contain zero byte, addresses of library functions may not > present in the string, which is used to overflow the buffer. As a > result, it makes it impossible to change the return address on the stack > to the address of some library function (e.g. system(3)). JFYI, this statement is too strong. It is usually possible to pass such addresses because the string does terminate with a NUL and this NUL gets written. C string based overflows where the terminating NUL is somehow not written are uncommon (in fact, I don't recall any). However, requiring NUL as the most significant byte of a 32-bit address achieves two things: 1. The overflow length has to be inferred/guessed exactly, because only one NUL may be written. Simply using a repeated pattern (with function address and arguments) no longer works. 2. Passing function arguments in the straightforward manner no longer works, because copying stops after the NUL. The attacker's best bet may be to find an entry point not at function boundary that sets registers and then proceeds with or branches to the desired library code. The easiest way to set registers and branch would be a function epilogue - pop/pop/.../ret - but then there's the difficulty in passing the address to ret to (we have just one NUL and we've already used it to get to this code). Similarly, even via such pop's we can't pass an argument that contains a NUL in it - e.g., the address of "/bin/sh" in libc (it contains a NUL most significant byte too) or a zero value for root's uid. A possible bypass is via multiple overflows - if the overflow may be triggered more than once before the vulnerable function returns, then multiple NULs may be written, exactly one per overflow. But this is hopefully relatively rare. Overall, this does make exploits harder and less reliable, just not in the exact sense of making it impossible to point the return address at libc. Alexander
Powered by blists - more mailing lists
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.