"Strong" stack protection for GCC
Stack buffer overflows are a longstanding problem for C programs that leads to all manner of ills, many of which are security vulnerabilities. The biggest problems have typically been with string buffers on the stack coupled with bad or missing length tests. A programmer who mistakenly leaves open the possibility of overrunning a buffer on a function's stack may be allowing attackers to overwrite the return pointer pushed onto the stack earlier. Since the attackers may be able to control what gets written, they can control where the function returns—with potentially dire results. GCC, like many compilers, offers features to help detect buffer overflows; the upcoming 4.9 release offers a new stack-protection mode with a different tradeoff between security and performance impact.
GCC has supported stack protection for some time. It currently supports two different types of stack protection. Recently, Google engineers have come up with another style that tries to chart a middle course between the two existing options. It has made its way into GCC 4.9 (expected later this year) and the upcoming 3.14 kernel has support for building with that option.
The basic idea behind stack protection is to push a "canary" (a randomly chosen integer) on the stack just after the function return pointer has been pushed. The canary value is then checked before the function returns; if it has changed, the program will abort. Generally, stack buffer overflow (aka "stack smashing") attacks will have to change the value of the canary as they write beyond the end of the buffer before they can get to the return pointer. Since the value of the canary is unknown to the attacker, it cannot be replaced by the attack. Thus, the stack protection allows the program to abort when that happens rather than return to wherever the attacker wanted it to go.
There is a downside to using canaries. The value must be generated and checked, which takes some time, but more importantly there must be code added to handle the canary for each function that is protected that way. That extra code results in some level of performance degradation, perhaps mostly due to a larger cache footprint. For this reason, it can make sense to restrict stack protection to a subset of all the functions in a program.
So the question has always been: "Which functions should be protected?" Putting stack protection into every function is both overkill and may hurt performance, so one of the GCC options chooses a subset of functions to protect. The existing -fstack-protector-all option will protect all functions, while the -fstack-protector option chooses any function that declares a character array of eight bytes or more in length on its stack. Some distributions have lowered that threshold (e.g. to four) in their builds by using the --param=ssp-buffer-size=N option.
That "character array" test catches the most "at risk" functions, but it leaves a number of other functions behind. As Kees Cook pointed out in a recent blog post, the Google Chrome OS team had been using -fstack-protector-all since the team is "paranoid", but a new -fstack-protector-strong option has been developed to broaden the scope of the stack protection without extending it to every function in the program.
In addition to the protections offered by -fstack-protector, the new option will guard any function that declares any type or length of local array, even those in structs or unions. It will also protect functions that use a local variable's address in a function argument or on the right-hand side of an assignment. In addition, any function that uses local register variables will be protected. According to Cook, Chrome OS has been using -fstack-protector-strong (instead of protecting all functions) for ten months or so.
During the 3.14 merge window, Linus Torvalds pulled Cook's patches to add the ability to build the kernel using the strong stack protection. In Ingo Molnar's pull request (and Cook's post), the results of using strong protection on the kernel were presented. The kernel with -fstack-protector turned on is 0.33% larger and covers 2.81% of the functions in the kernel. For -fstack-protector-strong, those numbers are an increase of 2.4% in code size over an unprotected kernel, but 20.5% of the functions are covered.
The CONFIG_CC_STACKPROTECTOR_STRONG kernel configuration option adds the strong protection, while the CONFIG_CC_STACKPROTECTOR option for the "regular" protection has been renamed to reflect that: CONFIG_CC_STACKPROTECTOR_REGULAR. The default CONFIG_CC_STACKPROTECTOR_NONE does just what its name would imply.
While stack protection certainly isn't a panacea for security woes, it will catch a significant portion of real-world attacks. Having an option that strikes a balance between the ultra-paranoid "all" and the regular variant (not to mention the wide-open "none" option) is likely to catch more bugs—and attack vectors. We will likely see some of the more security-conscious distributions building their user-space programs and kernels with the "strong" option moving forward.
| Index entries for this article | |
|---|---|
| Security | Tools/Compilers |
| Security | Vulnerabilities/Buffer overflow |
Posted Feb 6, 2014 6:25 UTC (Thu)
by eru (subscriber, #2753)
[Link] (2 responses)
I don't understand this condition. How would using some "register int i" make a stack problem more likely? It seems to me it would have no effect on the issue, and when optimizing, the compiler treats "register" just as a hint that may be ignored anyway. Tried already looking at the linked gcc mailing list entry, but there was no explanation either.
Posted Feb 6, 2014 11:40 UTC (Thu)
by sorokin (guest, #88478)
[Link] (1 responses)
"It was to catch unusual ways to get a reference to the frame address, with things like “register unsigned rsp __asm__(“rsp”);”, etc"
Posted Feb 6, 2014 12:52 UTC (Thu)
by nix (subscriber, #2304)
[Link]
Posted Feb 7, 2014 4:08 UTC (Fri)
by jtc (guest, #6246)
[Link] (27 responses)
Does the word 'generally' imply that there are some cases where this is not true (i.e., canary value does not have to be changed)? I suspect not. And if the answer is no, I believe the meaning of the sentence would be clearer without the introductory 'Generally, '.
Posted Feb 7, 2014 4:28 UTC (Fri)
by jimparis (guest, #38647)
[Link]
The answer is definitely yes. The canary, which is checked before return, protects against the case that the return address was overwritten. But a buffer overflow may overwrite other things too that would be just as exploitable. For example, a local variable containing a function pointer that gets called before the function returns. Or even just an integer that is later used to index an array, which (after overflow) could be changed to point anywhere.
Posted Feb 7, 2014 15:01 UTC (Fri)
by jzbiciak (guest, #5246)
[Link] (5 responses)
jimparis above gave a couple excellent examples, but how about another? 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.
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.
Posted Feb 9, 2014 19:05 UTC (Sun)
by eru (subscriber, #2753)
[Link] (1 responses)
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.
Posted Feb 9, 2014 20:21 UTC (Sun)
by jzbiciak (guest, #5246)
[Link]
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.
Posted Feb 7, 2014 18:19 UTC (Fri)
by deater (subscriber, #11746)
[Link] (1 responses)
I'm pretty sure the stack grows down on Alpha systems.
You might be thinking of HP PA-RISC where the stack grows up.
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.
Posted Feb 13, 2014 19:37 UTC (Thu)
by Pc5Y9sbv (guest, #41328)
[Link]
These canaries can be untouched by buggy code that happens to stride over the canary when writing, whether due to a per-iteration stride or due to some other constant or computed offset introduced by the buggy, unchecked access logic.
Even much more expensive per-access checks, like Purify, cannot catch 100% of array errors in a language like C using typical ABIs. It is not enough to just test whether an accessed address is a valid structure/variable, but you must reconstitute a triplet of info for the check: base address of pointer, offset from base, and size of object at base address; an access is wrong if the offset takes it beyond the object's size, regardless of whether this takes it to another valid object. But this triplet of information is not readily available in a program when general pointer arithmetic is allowed, and everything is reduced to machine addresses in the ABI.
Posted Feb 13, 2014 20:59 UTC (Thu)
by fw (subscriber, #26023)
[Link] (1 responses)
Posted Jun 15, 2014 9:03 UTC (Sun)
by mina86 (guest, #68442)
[Link]
Posted Feb 14, 2014 5:06 UTC (Fri)
by ewimberley (guest, #95544)
[Link] (16 responses)
If you want a bunch of examples check the code in my github repo:
Posted Feb 14, 2014 16:31 UTC (Fri)
by mathstuf (subscriber, #69389)
[Link] (15 responses)
Posted Feb 14, 2014 17:06 UTC (Fri)
by mpr22 (subscriber, #60784)
[Link] (14 responses)
Posted Feb 14, 2014 18:10 UTC (Fri)
by mathstuf (subscriber, #69389)
[Link]
Really, I'd just like for a C compiler to use the error-on-overflow for signed addition and such so that the undefined behavior is able to be caught without extra cost instead of it just being "some random value".
Posted Feb 15, 2014 13:30 UTC (Sat)
by renox (guest, #23785)
[Link] (5 responses)
Posted Feb 15, 2014 14:23 UTC (Sat)
by PaXTeam (guest, #24616)
[Link] (4 responses)
Posted Feb 15, 2014 22:39 UTC (Sat)
by kleptog (subscriber, #1183)
[Link] (3 responses)
To be fair, the C language doesn't make it easy since there's no nice syntax for returning multiple values. So you get alternatives like:
Posted Feb 16, 2014 1:46 UTC (Sun)
by mathstuf (subscriber, #69389)
[Link] (2 responses)
And this is what Mill offers you…sane behavior with zero code change. If the compiler detects custom overflow detection or whatever, just change the flavor of 'add' to use. There's nothing against such optimizations (and other targets could implement it too, but if you now have to stall the pipeline to fetch a flag, it might not really be worth it overall). *Detecting* them might be hard to Turing-complete, but that never stopped us from parsing Perl or C++, has it ;) .
Posted Feb 16, 2014 11:03 UTC (Sun)
by paulj (subscriber, #341)
[Link] (1 responses)
Posted Feb 16, 2014 11:08 UTC (Sun)
by paulj (subscriber, #341)
[Link]
Posted Feb 16, 2014 10:25 UTC (Sun)
by paulj (subscriber, #341)
[Link] (6 responses)
The problem is in the C implementations. Overflow is undefined behaviour in C, so implementations *could* have chosen to implement some kind of trap or exception (signal, etc) in response. Yet, AFAIK, most don't and silently allow overflow to occur. (I'd be curious to hear about any that do). When C runtimes generally don't provide a way to trap overflows, then it becomes very difficult for any other languages or runtimes to do so, unless they bypass C.
This is probably a lamentable state of affairs. Down to decisions made in the days when performance was king and other factors like correctness and security weren't really a consideration (relative to today). Decisions which, in my view, certainly don't serve us well anymore.
There's a longer argument about whether traps would have been more efficient than flags that have to be checked, and whether traps might have been more likely to be implemented. Still, there is surely lots of code where the security benefits of runtime overflow-checking would outweigh any performance costs? If there were a way to enable error/trap-on-overflow (with unhandled leading to termination), that could be quite useful. If it existed, it might possibly be nice to be able to enable/disable this just on a per-file or even function basis, to limit the overheads.
I'd be curious to read more about the relative costs of the overheads, and the effectiveness of overflow flag checking on current ISAs, if anyone knows.
GCC has an "-ftrapv" argument which I was hoping might do this, and use hardware flags when possible. Though, a trivial test-case (adding command-line arguments) doesn't behave any differently with overflow when compiled with ftrapv on x86-64 and happily runs past an overflow, so maybe I've misunderstood what it's meant to do (the trapv compiled code uses __addvdi3 for the addition, if -O isn't passed). ?? With -O it seems to be using leaq to generate the addition.
Posted Feb 16, 2014 10:47 UTC (Sun)
by jem (subscriber, #24231)
[Link] (1 responses)
To be more precise, signed overflow is undefined behaviour in C. Unsigned integers are defined to wrap around.
Posted Feb 16, 2014 10:58 UTC (Sun)
by paulj (subscriber, #341)
[Link]
Posted Feb 16, 2014 11:06 UTC (Sun)
by mchapman (subscriber, #66589)
[Link] (3 responses)
It needs to be a 64-bit signed integer. An int is likely to be only 32 bits.
Posted Feb 16, 2014 11:09 UTC (Sun)
by mchapman (subscriber, #66589)
[Link]
On second thoughts, that may be a compiler bug.
At any rate, I could only get it to work on GCC 4.8.2 if I used a 64-bit integer.
Posted Feb 16, 2014 11:13 UTC (Sun)
by paulj (subscriber, #341)
[Link] (1 responses)
Hmm, that's pretty limited in usefulness so, and buggy with respect to what the documentation suggests it does (the docs don't qualify when overflow checks will actually be done). :(
Posted Feb 16, 2014 11:15 UTC (Sun)
by mchapman (subscriber, #66589)
[Link]
Yes, indeed: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52478
Posted Mar 11, 2020 14:49 UTC (Wed)
by randguy (guest, #137701)
[Link] (1 responses)
I am using Yocto project for our BSP. I tried adding CONFIG_CC_STACKPROTECTOR_STRONG in the kernel configuration and later added -fstack-protector-strong in makefile of our application too. Still the cfa_problems_report generated from ISAFW (meta-security-isafw) claims that our application does not have stack protector. Please let me know if am missing anything.
More on meta-security-isafw:
please refer
Posted Mar 17, 2020 22:21 UTC (Tue)
by nix (subscriber, #2304)
[Link]
In addition, any function that uses local register variables will be protected.
"Strong" stack protection for GCC
"Strong" stack protection for GCC
Note that 'register variables' in this context are not variables declared with the obsolescent 'register' qualifier: they are registers that use the local register variable language extension.
"Strong" stack protection for GCC
"Strong" stack protection for GCC
"Strong" stack protection for GCC
"Strong" stack protection for GCC
void vulnerable( char *too_big )
{
char too_small[8];
// ...
strcpy( too_small, too_big );
// ...
}
"Strong" stack protection for GCC
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
"Strong" stack protection for GCC
"Strong" stack protection for GCC
> architecture),
"Strong" stack protection for GCC
"Strong" stack protection for GCC
"Strong" stack protection for GCC
"Strong" stack protection for GCC
"Strong" stack protection for GCC
https://github.com/ewimberley/AdvancedMemoryChallenges
"Strong" stack protection for GCC
CPUs have offered some assistance with overflow detection for over half a century (System/360 (1964) had a branch-on-overflow insn). The primary responsibility for arithmetic overflow detection not being ubiquitous in real-world software lies not with CPU designers and implementers, but with the designers and implementers of languages that don't take advantage of that assistance and the programmers who chose not to use, or not to press for the creation of, languages that do.
"Strong" stack protection for GCC
"Strong" stack protection for GCC
"Strong" stack protection for GCC
"Strong" stack protection for GCC
It's always bugged me that CPUs have all sorts of flags (Carry, Overflow & Zero) yet they're not exposed at the C level. Not even as GCC builtins. There are tricks with pushf but they're workarounds.
"Strong" stack protection for GCC
res = check_overflow_sadd(a, b, &overflow)
if(overflow)
error();
or
if(check_overflow_sadd(a,b))
error();
res = a+b;
neither of which are really nice. But there are many places where the carry and overflow bits could be used to simplify programs and make them more readable.
"Strong" stack protection for GCC
"Strong" stack protection for GCC
"Strong" stack protection for GCC
"Strong" stack protection for GCC
"Strong" stack protection for GCC
"Strong" stack protection for GCC
"Strong" stack protection for GCC
"Strong" stack protection for GCC
"Strong" stack protection for GCC
"Strong" stack protection for GCC
"Strong" stack protection for GCC
https://www.nccgroup.trust/globalassets/our-research/us/w...
page number: 14,
section:3.2.2
"Strong" stack protection for GCC