After I found out that Fedora's OpenJDK-based Java is not compiled with -fstack-protector or -O2 FORTIFY_SOURCE=2 I was thinking about automatic way to check whether right%{_optflags} were passed to the compiler at the build.
Apart from forgetting to pass %{optflags} upstreams do forget to include <stdio.h> and <string.h> when using the potentially dangerous string manioulation functions, and then they're not fortified by being replaced with macros that utilize argument size checking.
I was thinking to check debuginfo for presence of symbols, but we don't use -g3 when generatind debuginfo symbols. I've been told the debugging symbols would ocuppy too much space as macros are stored expanded; and indeed -- it it about 4 times more.
Other idea was to check for __stack_chk_fail symbol. It is invoked as a part of stack-protector function prologue when stack canary was corrupted, which indicates a stack overflow. But those prologues are not generated by all cases -- I think it's only when a character array is actually present on stack (not being optimized away). We have a couple of very simple programs that would generate false positives.
Another idea was to check if protected functions get replaced by their *_chk counterparts. But actually -- most of them don't in cases overflows cannot occur.
But at last I was pointed to the fact that *printf should always be fortified, as apart from bounds checking they conduct a check whether the format string that contains %n format specifier is in read-only memory. Fair enough.
Of course this don't spot programs and libraries that don't use *printf functions, but at least it doesn't generate false positives. Most C packages contains at leas one binary that calls *printf, and test failing for one can indicate that FORTIFY_SOURCE is not in effect also for other ones.
Now here's the script:
The script generated a fair amount of positives on my Fedora 8. Looking into those I found that most of them fortunatelly weren't cases of forgetting to use %{optflags}, but not including <stdio.h> in source files what use *printf functions. The same can be the case for {mem,str}{cpy,move} functions from <string.h>.
Maintainers, if a check fails for your package, do a make prep and try to find the offending source files:
$ find . -name '*.[ch]' |xargs grep -l printf |xargs grep -L stdio.h
You can also do the same for <string.h> functions. Please patch those, and send fixes upstream, so others can benefit. (I've heard rumours that Debian is going to use FORTIFY_SOURCE? Or do they currently do?)
Anyways, I'd probably call to the local radio station today and ask them to play a song for the one that's going to fix cdrkit. And probably also for Joerg Schilling.
Source code to the entries and scripts that format this site are available on github. Text of journal entries is licensed under CC-BY-SA license.
Mail questions, comments and pizza to lkundrak@v3.sk