Gentoo Logo
Gentoo Spaceship




Note: Due to technical difficulties, the Archives are currently not up to date. GMANE provides an alternative service for most mailing lists.
c.f. bug 424647
List Archive: gentoo-security
Navigation:
Lists: gentoo-security: < Prev By Thread Next > < Prev By Date Next >
Headers:
To: gentoo-security@g.o
From: "Israel G. Lugo" <israel.lugo@...>
Subject: Re: Kernel Security Update Target Delay?
Date: Sun, 17 Oct 2010 14:59:15 +0100
 Greetings,

So what's the conclusion on what happened with bug 337645? What can we
learn from here? That everything went just fine and according to plan?
That hardly seems like a realistic assessment. If we ignore mistakes
instead of learning from them, we are doomed to repeat them.

Regarding the assessment that has been made of this exploit somehow not
being "important", I couldn't disagree more. We're not all just running
desktops at home here, clicking on random executables. There are those
of us who run Gentoo Hardened on multiuser servers, which is the first
place I would consider running Hardened to begin with. Some of these
servers simply need to support 32-bit execution as well as  64-bit,
because the users need it to do their job. It's not such a strange
requirement in the real world; just think of development environments,
for example. Yes, or proprietary tools -- as much as I would love to
have a world entirely based on FOSS, unfortunately I don't have the
luxury of pretending that proprietary software doesn't exist, or that
it's not necessary in some cases, especially when I am supporting other
users who may need it.

It would be wonderful if malicious executables and malicious users could
never exist; the world would certainly be a happier place. Sadly, things
don't work that way, and that's why we have to worry about security in
the software industry to begin with. I would think it shouldn't have to
be explained that the ability for a local user to get root access by
compiling a piece of code and running it is a very bad thing. Your own
vulnerability treatment policy ranks it as A1 level, and correctly so in
my opinion.

Whether the fix was in tree within 4 hours or 4 days is irrelevant; the
fact is that a stable release didn't come out until a week later (in the
hardened version), when a trivial fix was already in tree, is very bad.
The fact that the general-public gentoo-sources remained vulnerable to
the exploit for 3 weeks is appalling.

Yes, there were mitigating security measures *in the hardened sources*,
which broke the *publicly known* exploits. It is still hiding one's head
in the sand to assume that just because the symbols are hidden, no one
else might come up with a cleverer exploit. Just think back to the
original flaw from 2+ years ago, and the exploit techniques that scanned
the memory looking for function signatures, for example. Yes, Grsecurity
provides an additional layer of defense in depth, *on hardened-sources*,
but that's it: it's only a stop-gap measure, a best effort in case a
vulnerability appears, to minimize the possibility for damage until the
vulnerability gets fixed. The point is that a very serious vulnerability
is there: certainly the Gentoo Security team are the first people who
would want it fixed.

Then there's the case of gentoo-sources, which has no Grsecurity and
therefore no mitigation whatsoever. Surely the users of the normal
kernel (including myself on my home PC, for example) aren't mistaken for
expecting that the high standard of quality, stability and security
provided by Gentoo will still apply to them...

I am and have always been an avid defender of Gentoo, for I agree with
the philosophy behind it, and admire the consistent high quality work of
the developers and maintainers, the second-to-none documentation, the
practicality of the rolling release, the unrivaled flexibility of
Portage, and I could go on. But when we have a local root exploit, with
a known fix, that clings on for this long, it's just sad. It hurts the
Gentoo image, and leaves it wide open to unfair blanket criticism like
we saw near the end of the 337645 bug thread. Every major distribution
had a fix for this very important problem within a couple of days; it
tarnishes the otherwise magnificent security efforts undertaken by the
Gentoo dev team that 3 weeks later the exploit was still there.

So, concrete question:

The fix could have easily been backported to the stable kernels, and a
new intermediary stable release could have been launched. I even went to
the trouble of submitting a patch, the upstream fix made against
2.6.32-hardened-r9, which was the stable hardened version at the time
(not to mention stable gentoo-sources, which doesn't even have any of
the mitigation measures provided by Grsecurity). It was an obvious patch
(now that the bug was found) fixing a 2-year old regression, altering 8
lines of code, most of them in the same manner. As noted earlier, the
fix was in Portage something like the next day after the CVE came out.
So why then was it not backported and stabilized, instead of waiting for
stabilization of a new version, which had many new features and
associated bugs? And why was it not merged with gentoo-sources in the
same manner?

Regards,
Israel G. Lugo


Replies:
Re: Re: Kernel Security Update Target Delay?
-- Israel G. Lugo
Re: Re: Kernel Security Update Target Delay?
-- Alex Legler
Navigation:
Lists: gentoo-security: < Prev By Thread Next > < Prev By Date Next >
Previous by thread:
Kernel Security Update Target Delay?
Next by thread:
Re: Re: Kernel Security Update Target Delay?
Previous by date:
Re: Kernel Security Update Target Delay?
Next by date:
Re: Re: Kernel Security Update Target Delay?


Updated May 10, 2012

Summary: Archive of the gentoo-security mailing list.

Donate to support our development efforts.

Copyright 2001-2013 Gentoo Foundation, Inc. Questions, Comments? Contact us.