Kernel security: beyond bug fixing

Posted Oct 29, 2015 10:45 UTC (Thu) by paulj (subscriber, #341)
Parent article: Kernel security: beyond bug fixing

On return-address overwrites, why not have the compiler put the return address /before/ the locals?

I know that'd be difficult to do for user-space - it'd be a new ABI - but the kernel is much less constrained here. Is it viable? What am I missing?

Kernel security: beyond bug fixing

Posted Oct 29, 2015 11:07 UTC (Thu) by dunlapg (guest, #57764) [Link] (29 responses)

Well first, because that's the way a stack goes -- it starts at the top and works its way down.

But even if that could be arranged, it wouldn't actually help, because now the return address for the *parent* is in front of your buffer; you can overwrite that one instead.

Kernel security: beyond bug fixing

Posted Oct 29, 2015 11:24 UTC (Thu) by hummassa (subscriber, #307) [Link] (3 responses)

Yeah, the only way this could be fixed would be to have a separate return stack. Not that THAT wouldn't come with its own set of problems and vulnerabilities...

Kernel security: beyond bug fixing

Posted Oct 29, 2015 17:39 UTC (Thu) by Nahor (subscriber, #51583) [Link] (2 responses)

That's what is called a shadow stack and is mentioned in the article

Kernel security: beyond bug fixing

Posted Oct 30, 2015 4:14 UTC (Fri) by pbonzini (subscriber, #60935) [Link] (1 responses)

It's also what ia64 did, and it wasn't fun to handle...

Kernel security: beyond bug fixing

Posted Oct 31, 2015 16:33 UTC (Sat) by mathstuf (subscriber, #69389) [Link]

Hmm. What problems does it cause? Mill does all of the stack setup and return address storing as part of the "call" instruction (it also handles argument passing automatically though). The stack is also 0-initialized and not necessarily anywhere near the parent's stack (I believe a stack overflow would just be a hard segfault).

Kernel security: beyond bug fixing

Posted Oct 29, 2015 11:27 UTC (Thu) by paulj (subscriber, #341) [Link] (20 responses)

I guess my wording was a bit bad (particularly 'before' [I meant 'before' in the 'looking back up the stack' sense, which doesn't make sense in terms of the order they're written or the order of the addresses] ;) ).

Yeah, the stack frames grow down, and ebp is saved to the stack first, so overflows of the local vars can write to it. Why not have the compiler create frame-generation code that first allocates the local var space and /then/ pushes the base pointer to the stack? So ebp is at a lower address and can't be written to by local var overflows?

(No doubt there's a reason why this isn't possible, I'm just curious what it is).

Kernel security: beyond bug fixing

Posted Oct 29, 2015 12:42 UTC (Thu) by Paf (subscriber, #91811) [Link]

One quick thought is that negative overflows are sometimes possible as well. Maybe even often possible, or easily achievable in practice - that might explain why your idea has not been adopted.

Kernel security: beyond bug fixing

Posted Oct 29, 2015 23:31 UTC (Thu) by Gollum (guest, #25237) [Link] (18 responses)

The idea that the stack starts at the top, and grows downwards seems to be the fundamental problem here. You write something important on the stack (e.g. a return address), then move to a new space some distance further back, so that any excessive steps forward trample on the important information.

Defining a stack that grows upwards seems like one reasonable approach to deal with this problem. Perhaps swapping the heap (which currently grows upwards, I believe?) with the stack (which grows downwards) is the answer?

Or would that simply swap one set of problems (stack-based overflows) for a new version of heap-based overflows, where a heap overflow overwrites the heap metadata?

Kernel security: beyond bug fixing

Posted Oct 30, 2015 14:01 UTC (Fri) by dunlapg (guest, #57764) [Link] (17 responses)

Look, even if you could change the direction, that doesn't actually fix the problem.

Right now, if you call foo() which calls bar() which calls zot(), you get:
[foo local variables]
[bar -> foo return address]
[bar local variables]
[zot -> bar return address]
[zot local variables]

So if you can overflow a zot local variable, you can overwrite the zot->bar return address.

Now suppose we switch it. What do we get?
[foo local variables]
[bar local variables]
[bar -> foo return address]
[zot local variables]
[zot -> bar return address]

So now if you can overflow a zot local variable, you can't overwrite the zot->bar return address, but you can still overwrite the bar->foo address.

Changing the direction of the stacks won't help.

Kernel security: beyond bug fixing

Posted Oct 30, 2015 18:04 UTC (Fri) by Gollum (guest, #25237) [Link] (16 responses)

I think you may have misunderstood me. My suggestion is more like:

[zot local variables]
[zot -> bar return address]
[bar local variables]
[bar -> foo return address]
[foo local variables]

So, if you are in zot, and you overflow a zot local variable, you write into unused space, and don't "overwrite" anything at all. That is, because zot->bar return address is at a lower address than the zot local variables, and overflows write "upwards" using incrementing addresses, the opportunity to overwrite return addresses is eliminated.

It doesn't protect the rest of the zot local variables, of course, so overwriting something otherwise uncontrollable by yourself may result in a successful comparison when previously it would have been unsuccessful.

And as I say, changing the heap to grow downwards may simply be changing one set of problems for another.

Kernel security: beyond bug fixing

Posted Nov 4, 2015 1:54 UTC (Wed) by ploxiln (subscriber, #58395) [Link] (15 responses)

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).

Kernel security: beyond bug fixing

Posted Oct 30, 2015 13:28 UTC (Fri) by mm7323 (subscriber, #87386) [Link] (3 responses)

You could change the ABIs to make the stack ascending, from low to high addresses. It's a lot of retooling, but there isn't any reason why it can't be done. ARM LDM and STM instructions have ascending modes, so the change wouldn't cost performance, though I have no idea about x86 and other architectures.

However, while such an ABI might make buffer overruns a little harder to exploit, because the overrun would generally be into the unused stack space, but I don't think it solves the problem; underuns or malicious code can still find return addresses in predictable read/write memory locations on the stack.

Kernel security: beyond bug fixing

Posted Oct 30, 2015 13:54 UTC (Fri) by cladisch (✭ supporter ✭, #50193) [Link] (2 responses)

When an interrupt is raised, the CPU automatically pushes some registers (at least the program counter) onto the stack, so it is not possible to change the stack direction without hardware support, which most architectures do not have.

Kernel security: beyond bug fixing

Posted Oct 30, 2015 14:32 UTC (Fri) by mm7323 (subscriber, #87386) [Link] (1 responses)

> the CPU automatically pushes some registers

Is that an x86 thing?

On ARM, there are some shadow registers that backup the PC and the processor doesn't touch the stack itself - and rightly so! It's most efficient for the interrupt handler writer to decide what state needs to be saved and restored, particularly if the interrupt routine isn't going to do very much.

If a CPU did automatically push something on IRQ entry, you could still engineer an ABI that uses an 'empty ascending' stack where the stack pointer is maintained to point to the first unused word at the stack top.

I'm pretty sure you could run an ascending stack on ARM, probably other architectures too, but it would be for limited security benefits so moot.

Kernel security: beyond bug fixing

Posted Oct 30, 2015 15:28 UTC (Fri) by cladisch (✭ supporter ✭, #50193) [Link]

ARM is pretty much the only architecture where software can choose the stack direction.

There are many other architectures with optimized interrupt handling, but they do not have the same flexibility for normal function calls.