[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
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.
