views:

1113

answers:

2

Hello,

I have enabled the -Wstack-protector flag when compiling the project I'm working on (a commercial multi-platform C++ game engine, compiling on Mac OS X 10.6 with GCC 4.2). This flag warns about functions that will not be protected against stack smashing even though -fstack-protector is enabled. GCC emits some warnings when building the project:

not protecting function: no buffer at least 8 bytes long
not protecting local variables: variable length buffer

For the first warning, I found that it is possible to adjust the minimum size a buffer must have when used in a function, for this function to be protected against stack smashing: --param ssp-buffer-size=X can be used, where X is 8 by default and can be as low as 1.
For the second warning, I can't suppress its occurrences unless I stop using -Wstack-protector.

1/ When should -fstack-protector be used? (as in, for instance, all the time during dev, or just when tracking bugs down?)
2/ When should -fstack-protector-all be used?
3/ What is -Wstack-protector telling me? Is it suggesting that I decrease the buffer minimum size?
4/ If so, are there any downsides to putting the size to 1?
5/ It appears that -Wstack-protector is not the kind of flag you want enabled at all times if you want a warning-free build. Is this right?

Thanks!

A: 

These options try to prevent against buffer overflow/stack-corruption based attacks. These articles should help:

dirkgently
Thanks for the links. I still don't see the big picture though. Is stack protection really useful for a commercial game? Will the game experience any performance hit if -fstack-protector is enabled? And the miminum buffer size set to 1? Or if -fstack-protector-all is enabled?
Guillaume
Do you expect people to try and crack your code? If so, it's probably a good idea. As for performance, you'll have to calculate. Here's a starting point: http://www.trl.ibm.com/projects/security/ssp/node5.html#SECTION00051000000000000000
dirkgently
I'd rather do this on debug builds and leave it out on the first release and see how people respond to the game (which IMHO is more important) and keep my fingers crossed that someday, I'll have to put the stack-protection in ;-)
dirkgently
Games Editors expect people to try and crack their games. If I'm not mistaken, these people usually succeed, so why bother putting a protection if there's a performance hit for every player. Stopping the debate right now, I can conclude that using stack-protection on a release build is not for me to decide (as a programmer). I can now bring this discussion to my hierarchy, and indeed do some performance tests when the project is more advanced, so thanks for your answer. :)What about the development stage. How much does stack-protection bring to the table?
Guillaume
Does your company have a security-threat model that you must adhere to? In that case, yes, you'd need that.
dirkgently
+1  A: 

You indeed should not care about the warning for normal builds. It's really more of an informational message. I hope it's obvious that you do have an inherent security concern with variable-sized buffers on the stack; get the size calculation wrong and you're opening a big hole.

MSalters
From: http://osdir.com/ml/cocoa-dev/2009-06/msg01658.htmlDisable all stack smashing warnings with: -Wno-stack-protectorThere is no pragma yet to disable only this warning. (This often happens with GCC. There is often a tension between having no warnings or too few warnings. One solution is to make special make target for the offending file and have special compile flags for it.)
Amigable Clark Kant
Can you elaborate on why variable-size buffers are significantly different than fixed-size buffers in terms of risk? I can see why it is hard to place them in a function as the stack protector does for fixed size buffers.
Jonathan Leffler
Double attack vectors: an attacker can more provide input bytes than you allocated for the buffer, or he can try to find bugs in your buffer size allocation
MSalters