Date:	Mon, 6 Jun 2011 07:19:08 -0400
From:	Andrew Lutomirski <luto@....edu>
To:	pageexec@...email.hu
Cc:	Ingo Molnar <mingo@...e.hu>, x86@...nel.org,
	Thomas Gleixner <tglx@...utronix.de>,
	linux-kernel@...r.kernel.org, Jesper Juhl <jj@...osbits.net>,
	Borislav Petkov <bp@...en8.de>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Arjan van de Ven <arjan@...radead.org>,
	Jan Beulich <JBeulich@...ell.com>,
	richard -rw- weinberger <richard.weinberger@...il.com>,
	Mikael Pettersson <mikpe@...uu.se>,
	Andi Kleen <andi@...stfloor.org>,
	Brian Gerst <brgerst@...il.com>,
	Louis Rilling <Louis.Rilling@...labs.com>,
	Valdis.Kletnieks@...edu
Subject: Re: [PATCH v5 8/9] x86-64: Emulate legacy vsyscalls

On Mon, Jun 6, 2011 at 5:42 AM,  <pageexec@...email.hu> wrote:
>>
>> I can't see any problem, but exploit writers are exceedingly clever,
>> and maybe someone has a use for a piece of the code that isn't a
>> syscall.  Just as a completely artificial example, here's some buggy
>> code:
>
> what you're describing here is a classical ret2libc (in modern marketing
> speak, ROP) attack. in general, having an executable ret insn (with an
> optional pop even) at a fixed address is very useful, especially for the
> all too classical case of stack overflows where the attacker may already
> know of a 'good' function pointer somewhere on the stack but in order to
> have the cpu reach it, he needs to pop enough bytes off of it. guess what
> they'll use this ret at a fixed address for...

I'm even more convinced now that exploit writers are exceedingly clever.

>
> as i said in private already, for security there's only one real solution
> here: make the vsyscall page non-executable (as i did in PaX years ago)
> and move or redirect every entry point to the vdso. yes, that kills the
> fast path performance until glibc stops using the vsyscall page.

I'm still unconvinced.

I would be happy to submit a version where the entire sequence is just
int 0xcc and the kernel emulates the ret instruction as well.  But I'm
not convinced that using a page fault to emulate the vsyscalls is any
better, and it's less flexible, slower, and it could impact a fast
path in the kernel.

>
> another thing to consider for using the int xx redirection scheme (speaking
> of which, it should just be an int3):

Why?  0xcd 0xcc traps no matter what offset you enter it at.

> it enables new kinds of 'nop sled'
> sequences that IDS/IPS systems will be unaware of, not exactly a win for
> the security conscious/aware people who this change is supposed to serve.

I think that's only because the patch allows int 0xcc to exist at any
address.  That's only because not doing so will apparently break one
particular commercial program.

I'm happy to break said program, and it sounds like the maintainer
will fix it up quickly.  I checked, and at least recent versions of
valgrind would not be affected (contrary to what I said earlier).

I don't think that making the page NX is viable until at least 2012.
We really want to wait for that glibc release.

(Yes, I know that not everyone uses glibc.  But the only remotely
relevant alternative out there that I can find that would be affected
is Go, and I'm sure that'll get fixed up in short order.)

--Andy
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists