Re: [kernel-hardening] [RFC] x86, mm: start mmap allocation for libs from low addresses

[Solar Designer <solar@openwall.com>]

Vasiliy,

On Sat, Sep 03, 2011 at 03:18:49PM +0400, Vasiliy Kulikov wrote:
> On Fri, Sep 02, 2011 at 22:29 +0400, Solar Designer wrote:
> > On Thu, Aug 25, 2011 at 09:19:34PM +0400, Vasiliy Kulikov wrote:
> > > additionally overwrite function arguments, which are located after the
> > > function address on the stack.  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.
> > 
> > The above was partially flawed logic on my part - as written above
> > (without further detail), the pop/pop/.../ret thing doesn't apply
> > because those pop's would read stack right after the just-used return
> > address - that is, the same stack locations that we presumably could not
> > write to in order to pass the arguments in a more straightforward
> > fashion.  So this trick would be of no help, and thus its other
> > limitations would be of no relevance.
> 
> Why not?

I am not sure what exactly your "why not" applies to.  What I said was
that the trick of returning specifically to pop/pop/.../ret would be of
no help to an exploit writer trying to bypass ASCII armor, and I
explained why not in the paragraph you quoted.  So the exploit writer
would use some other trick, possibly just slightly different - to give
an example (just to you, not for LKML), I included an instruction
sequence from a glibc build that would be a better target to return to
(note how it is not limited to pop and ret instructions), and that would
actually make the limitations being talked about relevant.

> If function address contains NUL, the overflow stops at this
> address.  If it doesn't contain NUL, but argument contain NUL, it is the
> last argument an attacker can use

Right.

> (therefore, it would be the last used code chunk).

I don't understand this bit.

> So, it has some value even if he can somehow write
> the ret address (e.g. it is out of 16 MBs).

Right.  Once again, what I said is that this limitation becomes relevant
in certain cases other than returning to a trivial pop/ret sequence.
Namely, it is relevant when returning straight to a function entry, and
it is relevant when returning to certain other instruction sequences.
Just not when returning specifically to pop/ret, which is of no help in
an attack trying to bypass ASCII armor anyway.

To summarize: we happened to give a poor example in the patch
description, and I'd like to correct that by reducing the level of
detail.  (The alternative would have been to go deeper into detail.)

> > > If CONFIG_VM86=y, the first megabyte is excluded from the potential
> > > range for mmap allocations as it might be used by vm86 code.  If
> > > CONFIG_VM86=n, the allocation begins from the mmap_min_addr.  Regardless
> > > of CONFIG_VM86 the base address is randomized with the same entropy size
> > > as mm->mmap_base.
> > 
> > OK.  Shouldn't CONFIG_VM86 be a sysctl, though?
> 
> This is not a hardening setting that was present in -ow, but an existing
> config to disable vm86/vm86_old at the compile time.  It was added for
> EMBEDDED.

Oh, I was not aware of that.

solar@host:~/kernel/mainline/linux-3.0.4 $ fgrep -rl CONFIG_VM86 .
./arch/x86/kernel/Makefile
./arch/x86/kernel/entry_32.S
./arch/x86/include/asm/vm86.h
./arch/x86/include/asm/processor-flags.h

Looks like there's no Kconfig option for this - perhaps add it with a
separate patch?

Thanks,

Alexander