MWR Labs: Assessing the Tux Strength

[Posted September 6, 2010 by corbet]

The MWR Labs group at MWR Info Security is running a series of articles comparing Linux distributions from a security point of view. Part 1: user space memory protection looks at protection against memory corruption attacks, while Part 2 - into the kernel examines kernel security settings. "The notable exceptions in the results are Fedora and Ubuntu. Both distributions do not allow the ability to write code to a certain memory region and then execute it. This can be observed from the results of the first five tests. Fedora goes one step further and also prevents the bss, data and heap sections from being marked as executable using the 'mprotect' system call. It should be noted that there would still be numerous other memory regions where an attacker could upload their code and then use the 'mprotect' function to mark it as executable."

to post comments

MWR Labs: Assessing the Tux Strength

Posted Sep 6, 2010 17:50 UTC (Mon) by Adi (guest, #52678) [Link] (8 responses)

It's said to see that Debian has lost in virtually all tests.
Quite an uneasy conclusion for distro so often used on servers.

MWR Labs: Assessing the Tux Strength

Posted Sep 6, 2010 18:37 UTC (Mon) by foom (subscriber, #14868) [Link] (3 responses)

It seems to me that it's fairly difficult for Debian as an organization to manage to make global settings changes like for those features.

MWR Labs: Assessing the Tux Strength

Posted Sep 6, 2010 18:50 UTC (Mon) by rahulsundaram (subscriber, #21946) [Link] (1 responses)

That would be a organizational failure to address. It should be possible to make technical changes consistently across package boundaries especially when it brings obvious benefits like security improvements.

MWR Labs: Assessing the Tux Strength

Posted Sep 9, 2010 18:33 UTC (Thu) by bronson (subscriber, #4806) [Link]

It should be, yes. But it isn't.

Good luck addressing it! People have tried and failed. I hear it's like sending ten thousand similar emails in an attempt to push a wall of jello.

MWR Labs: Assessing the Tux Strength

Posted Sep 7, 2010 17:15 UTC (Tue) by kees (subscriber, #27264) [Link]

See the thread for yourself. Here is why Debian rejected a global compiler change:

http://www.mail-archive.com/debian-devel@lists.debian.org...

MWR Labs: Assessing the Tux Strength

Posted Sep 6, 2010 19:05 UTC (Mon) by patrick_g (subscriber, #44470) [Link] (1 responses)

The Debian version which was assessed is Lenny (5.0.4).
Perhaps the security level is better with Debian Squeeze (6.0) ?

MWR Labs: Assessing the Tux Strength

Posted Sep 6, 2010 21:42 UTC (Mon) by hmh (subscriber, #3838) [Link]

It is a bit better, but nowhere close to something you'd write home about.

Debian mostly fails where Gentoo succeeds.

Posted Sep 7, 2010 10:26 UTC (Tue) by Alterego (guest, #55989) [Link] (1 responses)

We just need to take a gento hardened-kernel and put it in Debian.

I hope the sync between several distro (to use 2.6.32 kernel) will help to fix this, and avoid duplicate (or useless) efforts from the various maintainers.

Afaik Greg KH is one gentoo kernel maintainer, maybe this can explain several things ?

Debian mostly fails where Gentoo succeeds.

Posted Sep 9, 2010 13:17 UTC (Thu) by blueness (guest, #56336) [Link]

I'm currently maintaining Gentoo's hardened-sources. Ask away.

MWR Labs: Assessing the Tux Strength

Posted Sep 6, 2010 21:18 UTC (Mon) by maks (guest, #32426) [Link] (4 responses)

Comparing apples with pears.

Of course newer distributions have the newer linux-2.6 features. If they'd compared distributions that were released on the same date it be more interesting.

MWR Labs: Assessing the Tux Strength

Posted Sep 7, 2010 7:09 UTC (Tue) by Klavs (guest, #10563) [Link] (2 responses)

evaluating the latest stable for each distro seems fair to me. There will most likely never be a time where distro releases are in sync :)

MWR Labs: Assessing the Tux Strength

Posted Sep 7, 2010 9:22 UTC (Tue) by maks (guest, #32426) [Link]

It is only fair if the compared distros have the same release cycle. So comparing Ubuntu with Fedora is just fine, they release every 6 month. Other wise the time of the experiement is just arbitrary and will effectively disfavor distributions with longer release cycles that don't shipp newer linux-2.6.

They for example didn't test Red Hat or CentOS.

MWR Labs: Assessing the Tux Strength

Posted Sep 7, 2010 9:25 UTC (Tue) by federico2 (guest, #70000) [Link]

> evaluating the latest stable for each distro seems fair to me.

At the same time we should keep in mind that they have been released in different times and with different processes. Otherwise such comparison may be misleading.

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 much more security in my opinion.

MWR Labs: Assessing the Tux Strength

Posted Sep 7, 2010 12:16 UTC (Tue) by PaXTeam (guest, #24616) [Link]

> Of course newer distributions have the newer linux-2.6 features.

1. nothing prevents a distro from backporting features (and they often do), especially simple ones like ASLR.

2. not all tested features depend on the kernel.

Bias : gentoo hardened vs standard kernel

Posted Sep 7, 2010 10:48 UTC (Tue) by Alterego (guest, #55989) [Link] (1 responses)

The study compares hardened version of gentoo with standard kernel.

It would have been insteresting to compare with Debian grsecurity2 kernel (and i guess RedHat and SuSe also have hardened version)

Bias : gentoo hardened vs standard kernel

Posted Sep 7, 2010 11:12 UTC (Tue) by rahulsundaram (subscriber, #21946) [Link]

No. Neither Red Hat nor SUSE have alternative kernels with more security features. Either it is in the default kernel or not.

Add Mandriva?

Posted Sep 7, 2010 14:08 UTC (Tue) by buchanmilne (guest, #42315) [Link]

I know it is more effort to test on more distributions, but many other popular distros people might request are re-spins of one of the distros that have been tested.

However, Mandriva is not a re-spin of any of the distros tested, and has enabled some of these features, and is also used as a base for a few other distros.

MWR Labs: Assessing the Tux Strength

Posted Sep 7, 2010 20:35 UTC (Tue) by jspaleta (subscriber, #50639) [Link]

So no discussion about the value/trade-offs of prelink when PIE is not in use. That's unfortunate.

-jef

MWR Labs: Assessing the Tux Strength

Posted Sep 7, 2010 21:01 UTC (Tue) by SEJeff (guest, #51588) [Link]

Fodder for spender and perhaps jspaleta:
http://www.outflux.net/blog/archives/2010/09/07/cross-dis...

It show Kees Cook's frustration with trying to get proactive security into Debian proper where they have already been in **buntu for several releases already.

Library randomization / prelink

Posted Sep 8, 2010 18:26 UTC (Wed) by gmaxwell (guest, #30048) [Link] (2 responses)

Anyone know how the library randomization is being counted? 3 bits for fedora doesn't sound right. Is the 3 bits the value for a system vs itself or for this system vs all other systems?

Library randomization / prelink

Posted Sep 8, 2010 19:58 UTC (Wed) by kbad (guest, #61983) [Link] (1 responses)

From the pax dev (gentoo-hardened list):

"a note here: fedora uses exec-shield which maps libraries in two different
regions: ascii-armor (lower 16MB) and the rest. i think what paxtest measured there is the former where the usable entropy is necessarily less than elsewhere and may not be representative of real life apps and their address spaces (not saying the whole ascii-armor region is worth anything for security though ;)"

Library randomization / prelink

Posted Sep 10, 2010 7:57 UTC (Fri) by nix (subscriber, #2304) [Link]

It's still higher than three bits. Not much higher though: there's simply not much room down there. ASCII-armouring was a nice idea, but I'm not sure how effective it is.