While the LDFLAGS testing is still not complete, and if we are to properly fix any and all of the LDFLAGS-related problems it’s going to take a few years still, I’ve got an idea for the next phase of bugs to report through the tinderbox — and started reporting the first few bugs on the matter; thankfully Kapcer also started fixing them already which at least make it possible for me to feel not too useless.
As you can see from this bug, the kind of problems I’m now looking at are those reported by the _FORTIFY_SOURCE feature of recent GCC/GLIBC; I’ve been stirred up by the recent article on security mitigation strategies that made Gentoo Hardened appear a very shiny option, compared to other more frequently used distribution — to be honest, I don’t know many people running a Gentoo Hardened desktop, outside the general circle of developers, while at least both Ubuntu and Fedora don’t seem to focus extremely on desktops.
As you can see by yourself on that article, there is a feature that is applied to almost all processes: _FORTIFY_SOURCE; to be precise, it is the one feature that is not limited to Gentoo Hardened but is rather applied to standard Gentoo as well. It’s easy to enable that because it is implemented entirely on user space – there is no need to run a special kernel – nor it requires heavy changes to the behaviour that might cause further bugs (like the old SSP system did). Gentoo have been enabling it by default since GCC 4.3.3-r1 — at least as long as -O2 is present, otherwise GLIBC will disable it and it won’t protect you; so don’t expect to get a more stable/secure system by disabling optimisations, okay?
The fact that it works without having to change the kernel at all is a particularly important thing at least to me: the server where this blog is hosted uses the vserver technology, so I have no control over which kernel is executed; given this, I cannot afford stronger mitigation techniques like PaX and strong ASLR (and given I lack strong ASLR, I don’t use PIE either).
Anyway, one thing that is not excessively well known is that _FORTIFY_SOURCE works at run time, but also increase the efficacy of the build-time analysers by providing warnings in case an overflow can be identified at build-time at all. Portage already points a light at these warnings by repeating them at the end of the merge if they happen, but I asked Zac to weigh them more, by considering them fatal. In the mean time I’ve decided I’ll report such bugs on our bugzilla, hopefully this should help improving the upstream quality and reduce the chances that we let security issues sneak in under our nose.
And here, I have to thank Sebastian and Zac for making it possible to get the maintainer’s data right away on a build log, so I could drop the silly hack I added to the tinderbox.
Again, this is not really fixing all the trouble, and it most definitely only ends up hitting basic situations where the problem is far from a security issues, but at a minimum it provides a basic sense of doing things the right way that is helpful in forming a security culture, or at least I hope so.
I cannot afford stronger mitigation techniques like PaX and strong ASLR (and given I lack strong ASLR, I don’t use PIE either).