"Strong" stack protection for GCC [LWN.net]

"Strong" stack protection for GCC

Posted Feb 7, 2014 15:01 UTC (Fri) by jzbiciak (guest, #5246)
In reply to: "Strong" stack protection for GCC by jtc
Parent article: "Strong" stack protection for GCC

jimparis above gave a couple excellent examples, but how about another?

void vulnerable( char *too_big )
{
    char too_small[8];

    // ...
    strcpy( too_small, too_big );
    // ...
}

On a machine whose stack grows up instead of down (Alpha was one such architecture), strcpy() could end up smashing its own return address due to a buffer overflow in its caller. A canary in vulnerable() won't help.

to post comments

"Strong" stack protection for GCC

Posted Feb 7, 2014 15:04 UTC (Fri) by jzbiciak (guest, #5246) [Link] (2 responses)

And on machines whose stack grows down, if you have anything that fills a buffer in reverse (it happens, but it's admittedly far less common), you could do the same there.

"Strong" stack protection for GCC

Posted Feb 9, 2014 19:05 UTC (Sun) by eru (subscriber, #2753) [Link] (1 responses)

if you have anything that fills a buffer in reverse (it happens, but it's admittedly far less common), you could do the same there.

You could have two canaries: the second one is at the opposite end of the stack frame. A colleague actually added this feature to an in-house C compiler. The run-time system then reports which canary got killed. This was done to help catch programming errors, not so much for security.

"Strong" stack protection for GCC

Posted Feb 9, 2014 20:21 UTC (Sun) by jzbiciak (guest, #5246) [Link]

I'm not sure why that didn't occur to me here, as I've actually done the same in my own debugging infrastructure.

For example, in our DSP assembly kernel test benches, we actually went further than keeping a single canary word. We actually kept a sizeable buffer zone ahead of and behind the "live" data in the test bench, since some DSP algorithms write results separated by particular stride. (Think column accesses in a 2-D array for one common class.) I also wrote a "dmalloc" wrapper that put pad at both ends as well. Of course, that was all back in the 90s, when writing large amounts of assembly code for DSPs was much more commonplace.

But, as you said, it was more for catching programming errors than for preventing security exploits.

"Strong" stack protection for GCC

Posted Feb 7, 2014 18:19 UTC (Fri) by deater (subscriber, #11746) [Link] (1 responses)

> On a machine whose stack grows up instead of down (Alpha was one such
> architecture),

I'm pretty sure the stack grows down on Alpha systems.

You might be thinking of HP PA-RISC where the stack grows up.

"Strong" stack protection for GCC

Posted Feb 7, 2014 21:21 UTC (Fri) by jzbiciak (guest, #5246) [Link]

Quite possibly. For some reason I had it cached in my head that Alpha grew upwards. I tried to look it up, and found it's a surprisingly difficult topic to Google! Terms like "alpha", "stack" and "direction" turn up a lot of noise.

I did find a BUGTRAQ posting that indicates that the return value is stored below the other variables in a local stack frame, so the effect would be similar despite the stack itself growing down. If that's the case, that could be what I'm remembering.

The principle holds more generally that the frame you smash to trigger an exploit may not be the frame that holds the original array.