Hello,
I'm suprised to see how this article is far from complete. It misses some important details
and it doesn't actually explain how the exploit works...
For example, the interesting buffer overflow (which is actually not done by get_user_pages()
BTW), is not used to put a return address on the stack at all ! Hint: it's actually used to
put 0 and 0x1000.
And, surprise surprise, the exploit also 'mmap' 2 areas starting by 0 and 0x1000. And these
areas are made up to look like a struct page structure for a compound page where the
destructor field is set to kernel_code() address.
One thing I still miss is why the exploit code is so weirdly written ?
For example, it does:
pages[0] = *(void **) &(int[2]){0,PAGE_SIZE};
whereas it could have done instead:
pages[0] = NULL;
Is it something common for exploit code to be ofuscated ?
Posted Feb 25, 2008 0:19 UTC (Mon) by cras (guest, #7000)
[Link]
I don't know if the exploit was supposed to work as a 64bit binary (I crashed my machine when
testing one version of it), but that code doesn't translate to "NULL" on 64bit systems.
It's far from complete
Posted Feb 25, 2008 9:02 UTC (Mon) by fbh (guest, #49754)
[Link]
Acutally you're right.
It's a trick to compute the addresses of the fake "struct page" structures on both 32 and 64
bits platforms.
It should work on 64 bits platforms. I don't know why it doesn't in your case though but it's
just a matter of tuning some values in the exploit code probably.
Thanks.