Date: Sun, 4 Sep 2011 03:57:28 +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 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@...t:~/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
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.