Kernel security: beyond bug fixing

Posted Nov 4, 2015 1:54 UTC (Wed) by ploxiln (subscriber, #58395)
In reply to: Kernel security: beyond bug fixing by Gollum
Parent article: Kernel security: beyond bug fixing

It's very common for a buffer to be allocated in a parent stack frame and then used in a child function. For example

foo() {
char buf[16];
bar(buf, 16);
...
}

So if bar could overflow a buffer in its stack frame, or in foo's stack frame, no matter how you arrange them, one of them could hit the return address.

Kernel security: beyond bug fixing

Posted Nov 4, 2015 12:30 UTC (Wed) by renox (guest, #23785) [Link] (14 responses)

> So if bar could overflow a buffer in its stack frame, or in foo's stack frame, no matter how you arrange them,

"No matter how you arrange them" is not correct: if you have separated variable and address stack, you cannot use a buffer overflow to override a return address.

Kernel security: beyond bug fixing

Posted Nov 4, 2015 23:47 UTC (Wed) by PaXTeam (guest, #24616) [Link] (12 responses)

why not? you first overwrite a local variable of pointer type then let the rest of the function write through that pointer to overwrite the return address on the other stack.

Kernel security: beyond bug fixing

Posted Nov 5, 2015 9:31 UTC (Thu) by renox (guest, #23785) [Link] (11 responses)

I'm sorry but I didn't understand how your example would work.

Can you explain it again or do you have a link with an article explaining how it could work?
Thanks.

Kernel security: beyond bug fixing

Posted Nov 5, 2015 10:36 UTC (Thu) by PaXTeam (guest, #24616) [Link] (10 responses)

void foo(char *in, long s)
{
long *p;
char out[8];
memcpy(out, in, 1024);
*p = s;
}

assume the attacker controls the data behind 'in' and that the memcpy overwrites both 'p' and 's' on the stack, the last line will then be able to write anything anywhere. in short, there are many ways a memory corruption bug can be exploited, overwriting the return address of the current frame is just one and perhaps the most popularized textbook example but by far not the only way. this is the reason why having a proper threat model helps avoiding mistakes in devising defenses.

Kernel security: beyond bug fixing

Posted Nov 5, 2015 10:45 UTC (Thu) by renox (guest, #23785) [Link] (9 responses)

Yes, it's able to write anything anywhere the process can, but it doesn't necessarily makes its possible to overwrite the return address, which makes it harder to exploit the flaw (especially if you have w^x and randomisation).

Kernel security: beyond bug fixing

Posted Nov 5, 2015 11:25 UTC (Thu) by PaXTeam (guest, #24616) [Link] (8 responses)

the return address is writable by the process and therefore by the arbitrary write primitive too. whether there're defenses that make it harder or not is orthogonal to your original statement 'you cannot use a buffer overflow to override a return address'.

Kernel security: beyond bug fixing

Posted Nov 5, 2015 12:25 UTC (Thu) by renox (guest, #23785) [Link] (1 responses)

> the return address is writable by the process and therefore by the arbitrary write primitive too. whether there're defenses that make it harder or not is orthogonal to your original statement 'you cannot use a buffer overflow to override a return address'.

The 'arbitrary write' can overwrite the return address only if the address of the return address is known, which can be quite difficult if there is randomisation.

Also for the Mill CPU(unfortunately paperware only currently) I think that the separated address stack is managed directly by the CPU, so an 'arbitrary write' cannot overwrite a return address.

Kernel security: beyond bug fixing

Posted Nov 5, 2015 12:46 UTC (Thu) by PaXTeam (guest, #24616) [Link]

it seems to me that you're mixing up defense techniques with exploit techniques, which one are you arguing about now? ;) your original post made a blanket statement about something which is demonstrably false, that's all i wanted to point out. how you can make exploit techniques fail with deterministic or probabilistic methods is irrelevant for that discussion. case in point, my simple example may very well be non-exploitable if the compiler places some of those variables into registers which by definition are not subject to memory corruption, but that of course was not the point of the example.

Kernel security: beyond bug fixing

Posted Nov 5, 2015 12:28 UTC (Thu) by hummassa (subscriber, #307) [Link] (5 responses)

The only defense against THAT would be "only the CALL instruction can write on the return stack".

Kernel security: beyond bug fixing

Posted Nov 5, 2015 12:52 UTC (Thu) by PaXTeam (guest, #24616) [Link] (4 responses)

there're other defenses against that.

Kernel security: beyond bug fixing

Posted Nov 10, 2015 16:39 UTC (Tue) by hummassa (subscriber, #307) [Link] (3 responses)

Care to elaborate? If any instruction can write to the return stack, it's always possible to point the return address to an address of my choosing, and that way calling anything the current function's security context has the right to call. Which is mostly everything, because proper security contexts are a pain in the arse.

Kernel security: beyond bug fixing

Posted Nov 10, 2015 17:29 UTC (Tue) by PaXTeam (guest, #24616) [Link] (2 responses)

there's a whole bunch of public research on control flow integrity, some of which also addresses protecting the return address despite its being writable by the attacker. i also recently presented my ideas on this at H2HC, see the slides for more details. in short, all these defenses boil down to restricting the 'address of my choosing' to the point that at least privilege escalation is no longer possible.

Kernel security: beyond bug fixing

Posted Nov 24, 2015 13:43 UTC (Tue) by hummassa (subscriber, #307) [Link] (1 responses)

I couldn't find the slides. Link, please? :D

Kernel security: beyond bug fixing

Posted Nov 24, 2015 16:25 UTC (Tue) by PaXTeam (guest, #24616) [Link]

https://pax.grsecurity.net/docs/PaXTeam-H2HC15-RAP-RIP-RO... (there's some small errata in there that i'll fix eventually so better check the doc page for the updated version)

Kernel security: beyond bug fixing

Posted Nov 6, 2015 3:38 UTC (Fri) by ploxiln (subscriber, #58395) [Link]

Indeed, I did mean "if using a single stack" :) Dual stacks are nifty (but as pointed out by another comment not 100% bulletproof).