[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20110822201418.GA3176@albatros>
Date: Tue, 23 Aug 2011 00:14:20 +0400
From: Vasiliy Kulikov <segoon@...nwall.com>
To: "H. Peter Anvin" <hpa@...or.com>
Cc: Thomas Gleixner <tglx@...utronix.de>, Ingo Molnar <mingo@...hat.com>,
kernel-hardening@...ts.openwall.com,
Peter Zijlstra <peterz@...radead.org>,
Andrew Morton <akpm@...ux-foundation.org>, x86@...nel.org,
linux-kernel@...r.kernel.org, linux-mm@...ck.org
Subject: Re: [RFC] x86, mm: start mmap allocation for libs from low
addresses
On Mon, Aug 22, 2011 at 10:24 -0700, H. Peter Anvin wrote:
> Conceptually:
>
> I also have to admit to being somewhat skeptical to the concept on a
> littleendian architecture like x86.
Sorry, I was too short at my statement. This is a quote from Solar
Designer:
"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."
I'll extend the patch description to explain the motivation more
clearly.
> Code-wise:
>
> The code is horrific; it is full of open-coded magic numbers;
Agreed, the magic needs macro definition and comments.
> it also
> puts a function called arch_get_unmapped_exec_area() in a generic file,
> which could best be described as "WTF" -- the arch_ prefix we use
> specifically to denote a per-architecture hook function.
Agreed. But I'd want to leave it in mm/mmap.c as it's likely be used by
other archs - the changes are bitness specific, not arch specific. Is
it OK if I do this?
#ifndef HAVE_ARCH_UNMAPPED_EXEC_AREA
void *arch_get_unmapped_exec_area(...)
{
...
}
#endif
Thank you for the review!
--
Vasiliy Kulikov
http://www.openwall.com - bringing security into open computing environments
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.
