|Line 58:||Line 58:|
Revision as of 13:27, 19 November 2013
What is -Wformat-security
To quote the gcc man page:
-Wformat-security If -Wformat is specified, also warn about uses of format functions that represent possible security problems. At present, this warns about calls to "printf" and "scanf" functions where the format string is not a string literal and there are no format arguments, as in "printf (foo);". This may be a security hole if the format string came from untrusted input and contains %n. (This is currently a subset of what -Wformat-nonliteral warns about, but in future warnings may be added to -Wformat-security that are not included in -Wformat-nonliteral.)
The short answer is this warning is meant to let a user know if they're using printf and scanf functions in an unsafe manner. C has a great deal of power, but also can get us into trouble. This is now comparable to ignoring the default warnings. Long ago it might have been "affordable" to ignore the warnings a compiler spit out but it is not really OK to be ignoring these warnings anymore.
What's the difference from -Werror=format-security
The -Werror= flag will turn certain warnings into errors. GCC will stop compilation when it triggers an error condition. This mean that by enabling this flag, it becomes impossible to compile code that could be vulnerable to a string format security flaw.
Why should I care?
This option elliminates an entire class of security issues. This doesn't happen very often. Also, we would like to see this flag enabled by default in Fedora, see this FESCO ticket for more details. If that can be done, it's possible you will see this error pop up at some point.
We did a test rebuild of rawhide, it caused 400 builds to fail, so there are a fair number of things that use printf in this manner.
I don't process untrusted string, this isn't an error!
This argument is technically valid. If you are not parsing untrusted input, it's not really a bug. GCC can't currently tell which strings are untrusted and which are not, so the error catches everything.
Altering your code for this feature is not a waste of time though. We would call this practice "defensive coding". The idea being that you be extra careful to protect from mistakes at some future date. Your string may not be untrusted right now, but that could change someday. Rather than wait for that date and try to remember to fix the printf statement, you can do it now, preventing future security issues.
Let us not forget that format string vulnerabilities are (unfortunately) still common. For example, in this bug, such proactive hardening action caused a FTBFS (in this very particular case) and further investigations found out that this package had a security vulnerability (CVE-2012-1152). For more such cases, see this, this and this bug reports.
How do I fix these errors?
The fix for these errors is quite simple. It's a matter of changing a line like
I have more questions!
Please let us know, we're here to help. You can reach the people responsible for this on the Fedora Security List.