Re: [tlug] Notes on the Nomikai

[John Fremlin <john@example.com>]

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.