Gentoo Archives: gentoo-security

From: Alex Legler <a3li@g.o>
To: gentoo-security <gentoo-security@l.g.o>
Subject: Re: [gentoo-security] Re: Kernel Security Update Target Delay?
Date: Sun, 17 Oct 2010 16:05:12
Message-Id: 1287326011-sup-5331@stingray
In Reply to: [gentoo-security] Re: Kernel Security Update Target Delay? by "Israel G. Lugo"
Excerpts from Israel G. Lugo's message of Sun Oct 17 15:59:15 +0200 2010:
> 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?
Are you kidding?
> 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.
Er, who here assessed the issue to be not "important"?
> 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.
You seem to be assuming that we (=Gentoo people) live in a dream world and still need to be told about hackers and the need for IA32-emul code even today. We don't. So please stop discussing such banalities we are all well aware of and instead get to the point.
> Your own > vulnerability treatment policy ranks it as A1 level, and correctly so in > my opinion. >
Besides the fact that the VTP is still not applicable to Kernel packages, we now do seem to rank things correctly? Can you please make up your mind?
> 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.
Again: Stop with the banalities. No one claims that workarounds or mitigations are equivalent to a fix in the source code. Yes, the Security team are the first ones to want things (properly) fixed, however we cannot just jump in and fix things. We have to work with maintainers and arch teams. This issue clearly has shown that there are frictional losses that need to be addressed.
> 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.
..which is basically the same thing you said on the bug. Can we get to the poi..
> > So, concrete question:
..nt now? Finally! Thank God.
> > 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?
As the maintainers are primarily responsible for providing unaffected ebuilds, you'll need to ask the kernel team for exact reasons. As for the 'lessons learned' part, it does seem that the resolution of this issue was very much focused on updating to newer versions while forgetting about alternatives (i.e. backporting). That's something that we can do better next time. Communication could be improved, too. Reading bug 337645, there was little contribution from the Kernel team with regards to stabilizing unaffected sources. That could be improved by noting progress or problems. Then again my team (Security) could have asked for such info earlier when there was no update. At the same time I also have to address the users who made useless comments on that bug. Of course, with a better resolution strategy on our part, such things are less likely to appear, but people need to remember that a bug tracker is not the place for random rants (which again drain the motivation of the volunteers involved in the issue). Something I'd like to see as a productive outcome of this issue, is a little Kernel bug best-practices document for improving the interaction of the various teams. Yours most sincerely, Alex -- Alex Legler <a3li@g.o> Gentoo Security/Ruby


File name MIME type
signature.asc application/pgp-signature


Subject Author
Re: [gentoo-security] Re: Kernel Security Update Target Delay? "Israel G. Lugo" <israel.lugo@×××××××.com>
Re: [gentoo-security] Re: Kernel Security Update Target Delay? Graham Murray <graham@×××××××××××.uk>
Re: [gentoo-security] Re: Kernel Security Update Target Delay? Richard Freeman <rich0@g.o>