Mailing List Archive


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [tlug] Notes on the Nomikai



Edward Middleton wrote:
John Fremlin wrote:
Two serious exploits so far, I believe. For example, http://blog.cr0.org/2009/08/linux-null-pointer-dereference-due-to.html

Thanks for that.   Just looking at the mitigation methods.

* on IA32 with PaX/GrSecurity <http://www.grsecurity.net/>, the KERNEXEC
feature (x86 only)

Any idea what the (x86 only) is about. Is this only effective on x86. I use KERNEXEC on both x86_64 and x86 systems.

I don't see why it wouldn't be effective on AMD64 if it were effective on IA32.

As far as I understand it, using the no-exec PaX patch would mitigate this particular trick of using a suid binary after setting the strange personality and using the

if (sock_writeable(sk) ||
	    (!test_and_set_bit(SOCK_ASYNC_NOSPACE, &sk->sk_socket->flags) &&
	     sock_writeable(sk)))
		mask |= POLLOUT | POLLWRNORM;

to set the mmap function pointer of file_operations structure to the address 1 (http://lwn.net/Articles/342330/). (If it is NULL then obviously the file operation will not be called and mmap is forbidden.)

The address 1 is in the first page (mapped from NULL to 4096) and it contains the shellcode. The PaX exec protection means that you cannot execute the shellcode from here.

It seems to me that the page could be easily remapped to be read-only/exec before invoking the dodgy mmap file operation, as pulseaudio has dropped privileges at this point and is running the attackers (unprivileged) code. This would trivially circumvent the normal PaX protection as far as I can see. The extra KERNEXEC protection might mark the page as non-executable from kernel context -- I've no idea -- what exactly does KERNEXEC do, I've never heard of it before?

However, it is quite conceivable that there is a better exploit that uses another undesirable write operation or simply uses the same test_and_set_bit (note that SOCK_ASYNC_NOSPACE is zero so it affects the least significant bit) to set another privileged bit somewhere else.



Home | Main Index | Thread Index

Home Page Mailing List Linux and Japan TLUG Members Links