The recent work by MWR Labs does a reasonable job showing Debian’s poor pro-active security and why I am so frustrated about it: we have not been able to move very quickly at getting it enabled. While my hardening-includes package is available to maintainers that want to turn on protections for their builds, it’s still a far cry from having it be distro-wide, and it doesn’t protect people that build stuff by hand. We were able to solve this in Ubuntu very directly a while ago by improving the compiler itself.
Since SSP and FORTIFY_SOURCE can only be confirmed (it’s not possible without source analysis to see if it should have been enabled), it would be nice to see what binaries differed between distros on this. Most of the “SSP disabled” stuff are binaries that lack character arrays on the stack to begin with, and the FORTIFY_SOURCE stuff may have done all compile-time protections. The comments about “other distributions could potentially enable it for a few more binaries” is a bit misleading since, for all but Debian, both SSP and FORTIFY_SOURCE are enabled for all builds.
I did appreciate the nod to Ubuntu for being the only distro without by-default PIE that built Firefox with PIE. Given that Firefox is the #2 most vulnerable piece of software in a desktop distro, it was important to do it. (The #1 most vulnerable is the kernel itself — I’m counting number of fixed CVEs for this stat.)
The kernel analysis by MWR seems rather incomplete. Also, it’s not clear to me which distros were running a PAE kernel, which would change some of the results. I didn’t see any mention of several other userspace protections that the kernel can provide, for example:
- symlink and hardlink protections (Gentoo Hardened and Ubuntu 10.10 only)
- PTRACE protections (Gentoo Hardened and Ubuntu 10.10 only)
And a ton more that only Gentoo Hardened could boast, due to their use of grsecurity.
I’d also be curious to see performance comparisons, too. They compared 4 general-purpose distros against a tuned-specifically-for-security-hardening distro, which seems a bit unfair. How about comparing against vanilla Gentoo instead? I can tell you who would be best then. :)
© 2010, Kees Cook. This work is licensed under a Creative Commons Attribution-ShareAlike 4.0 License.
So much for “Debian, made by experts”
Comment by Tom — September 7, 2010 @ 12:10 pm
did you try submitting a patch against gcc? then all you would have to do is convince the maintainers to accept it, and everyone else would just have to deal with it.
Comment by Michael Gilbert — September 7, 2010 @ 12:52 pm
Upstream gcc has rejected attempts before, but some of the Gentoo folks are working towards making it a build-time configure flag to turn on all the defaults, allowing people to choose to enable most of them.
Comment by kees — September 7, 2010 @ 1:02 pm
Well,.. as I could show by dozens of examples,… Debian does not care much on security,… and for the sake of “beeing cool” it gets even worse…
Comment by Christoph Anton Mitterer — September 7, 2010 @ 1:02 pm
Pity there’s no discussion about the use of prelink as another approach to memory location randomization in comparison/contrast to strict PIE usage and the tradeoffs inherent in both approaches.
-jef
Comment by Jef Spaleta — September 7, 2010 @ 1:23 pm
IMO, prelink was an early work-around for lacking mmap ASLR and symbol table hashes. Now that those exist, there’s no place for prelink in a modern distro anymore.
Comment by kees — September 7, 2010 @ 1:47 pm
No place for prelink? So you are advocating PIE for libraries and executables?
-jef
Comment by Jef Spaleta — September 7, 2010 @ 1:53 pm
Sorry that should have been “all libraries and executables”
Comment by Jef Spaleta — September 7, 2010 @ 1:53 pm
Well, there’s no place for prelink unless, say, you want to reduce startup relocation overhead by orders of magnitude. Which is a good thing.
It’s a tradeoff: if you want to reduce prelocation overhead, you sacrifice dynamic ASLR. On 32-bit, I’d say this is dangerous: the address space is too small to keep things in the same place. On 64-bit, you could easily have so much randomness in the placement that there’s no hope of tracking it down, even with attacks repeated for ages, even with prelink locking a shared library into one place.
Comment by Nix — September 7, 2010 @ 1:54 pm
All libraries are already PIC, and so their position is already randomized at exec time via mmap ASLR. I do advocate PIE for all binaries, but there are performance concerns on register-starved ia32. If I’m missing something that prelink does that isn’t already handled in a different/better way, I’m all ears. :)
Comment by kees — September 7, 2010 @ 2:03 pm
@Nix: actually, no, I was not able to measure any meaningful difference with relocation after the symbol hashes started being used. For example, let’s find a worst-case with a lot of relocations:
$ unset DISPLAY
$ LD_DEBUG=statistics inkscape /usr/share/inkscape/icons/remove-color.svg -e /tmp/test.png 2>&1 | grep “final number of relocations:”
20818: final number of relocations: 30876
Note that other stuff is at least a couple orders of magnitude smaller:
$ LD_DEBUG=statistics ssh localhost echo 2>&1 | grep “final number of relocations:”
20831: final number of relocations: 1781
Verify that the binary isn’t already marked to do immediate binding:
$ readelf -d $(which inkscape) | grep BIND_NOW | wc -l
0
So, we have a worse-case with tens of thousands of symbols, and the binary is not set for immediate binding. Therefore, the overhead of relocation resolution can be seen by timing startup with and without LD_BIND_NOW=1 environment variable:
$ time inkscape /usr/share/inkscape/icons/remove-color.svg -e /tmp/test.png
Running above three times yielded three wall-clock times: 0m0.963s, 0m0.968s, 0m0.965s.
$ export LD_BIND_NOW=1
Now running it three times again: 0m0.992s, 0m0.990s, 0m0.992s. So the average delta is 0.0253 seconds, or 2 hundredths of a second on a worst-case binary. To me, this is a total non-issue. :)
Comment by kees — September 7, 2010 @ 2:47 pm
Come back at the start of the wheezy release cycle and propose to make it a release goal?
The integration with dpkg-buildflags needs to be somewhat thought out I guess. This could start right now…
Comment by Raphaël Hertzog — September 8, 2010 @ 11:19 am
Debian puts a lot of efforts into releasing a distribution that contains only mature software, “old by design” so to speak, where many vulnerabilities have already been found and patched.
The main reasons to do that are security and reliability.
Other distributions (including Ubuntu) are releasing much newer software, mainly to provide a better desktop experience, so they can ship new security features.
OTOH, all the cutting-edge software included inevitably contains many new vulnerabilities.
In terms of trade-offs, given that the memory protection tools mitigate a specific set of vulnerabilities only, having mature software gives better security, in my opinion.
Comment by federico — September 8, 2010 @ 1:16 pm
Unfortunately, that’s not really the best way to look at the reality of the situation. Vulnerabilities show up in software of all ages, so “old by design” doesn’t help for security (it can help for feature stabilization, but that’s not what this is about).
A good example is with the stack overflow in the DHCP client (http://www.debian.org/security/2009/dsa-1833). This was a remote root escalation (in “mature software”) with a public exploit that was a critical vulnerability in Debian, and a total non-issue in every other distro since they all have been using the stack protector for years now.
Comment by kees — September 8, 2010 @ 1:26 pm
My comment was actually with respect to the debian gcc package. If you submitted a patch there, and of course if they accepted it, then the rest of debian would just have to deal with it. It’s too hard to accomplish anything “by consensus” in debian since it is a real meritocracy; rather than ubuntus cross between dictatorship/meritocracy.
Comment by Michael Gilbert — September 10, 2010 @ 6:20 am
Yes, that’s the second link in my blog post, which links to http://outflux.net/hardening-for-all.patch The hardening patches are all already IN Debian’s gcc, they’re just not enabled because the gcc maintainers do no want them enabled.
Comment by kees — September 10, 2010 @ 7:53 am
So, push for it as a release goal for wheezy?
Comment by Michael Gilbert — September 10, 2010 @ 8:23 am