Gentoo Archives: gentoo-security

From: "Israel G. Lugo" <israel.lugo@×××××××.com>
To: gentoo-security@l.g.o
Subject: [gentoo-security] Re: Kernel Security Update Target Delay?
Date: Sun, 17 Oct 2010 14:06:55
Message-Id: 4CBB0133.2010305@lugosys.com
1 Greetings,
2
3 So what's the conclusion on what happened with bug 337645? What can we
4 learn from here? That everything went just fine and according to plan?
5 That hardly seems like a realistic assessment. If we ignore mistakes
6 instead of learning from them, we are doomed to repeat them.
7
8 Regarding the assessment that has been made of this exploit somehow not
9 being "important", I couldn't disagree more. We're not all just running
10 desktops at home here, clicking on random executables. There are those
11 of us who run Gentoo Hardened on multiuser servers, which is the first
12 place I would consider running Hardened to begin with. Some of these
13 servers simply need to support 32-bit execution as well as 64-bit,
14 because the users need it to do their job. It's not such a strange
15 requirement in the real world; just think of development environments,
16 for example. Yes, or proprietary tools -- as much as I would love to
17 have a world entirely based on FOSS, unfortunately I don't have the
18 luxury of pretending that proprietary software doesn't exist, or that
19 it's not necessary in some cases, especially when I am supporting other
20 users who may need it.
21
22 It would be wonderful if malicious executables and malicious users could
23 never exist; the world would certainly be a happier place. Sadly, things
24 don't work that way, and that's why we have to worry about security in
25 the software industry to begin with. I would think it shouldn't have to
26 be explained that the ability for a local user to get root access by
27 compiling a piece of code and running it is a very bad thing. Your own
28 vulnerability treatment policy ranks it as A1 level, and correctly so in
29 my opinion.
30
31 Whether the fix was in tree within 4 hours or 4 days is irrelevant; the
32 fact is that a stable release didn't come out until a week later (in the
33 hardened version), when a trivial fix was already in tree, is very bad.
34 The fact that the general-public gentoo-sources remained vulnerable to
35 the exploit for 3 weeks is appalling.
36
37 Yes, there were mitigating security measures *in the hardened sources*,
38 which broke the *publicly known* exploits. It is still hiding one's head
39 in the sand to assume that just because the symbols are hidden, no one
40 else might come up with a cleverer exploit. Just think back to the
41 original flaw from 2+ years ago, and the exploit techniques that scanned
42 the memory looking for function signatures, for example. Yes, Grsecurity
43 provides an additional layer of defense in depth, *on hardened-sources*,
44 but that's it: it's only a stop-gap measure, a best effort in case a
45 vulnerability appears, to minimize the possibility for damage until the
46 vulnerability gets fixed. The point is that a very serious vulnerability
47 is there: certainly the Gentoo Security team are the first people who
48 would want it fixed.
49
50 Then there's the case of gentoo-sources, which has no Grsecurity and
51 therefore no mitigation whatsoever. Surely the users of the normal
52 kernel (including myself on my home PC, for example) aren't mistaken for
53 expecting that the high standard of quality, stability and security
54 provided by Gentoo will still apply to them...
55
56 I am and have always been an avid defender of Gentoo, for I agree with
57 the philosophy behind it, and admire the consistent high quality work of
58 the developers and maintainers, the second-to-none documentation, the
59 practicality of the rolling release, the unrivaled flexibility of
60 Portage, and I could go on. But when we have a local root exploit, with
61 a known fix, that clings on for this long, it's just sad. It hurts the
62 Gentoo image, and leaves it wide open to unfair blanket criticism like
63 we saw near the end of the 337645 bug thread. Every major distribution
64 had a fix for this very important problem within a couple of days; it
65 tarnishes the otherwise magnificent security efforts undertaken by the
66 Gentoo dev team that 3 weeks later the exploit was still there.
67
68 So, concrete question:
69
70 The fix could have easily been backported to the stable kernels, and a
71 new intermediary stable release could have been launched. I even went to
72 the trouble of submitting a patch, the upstream fix made against
73 2.6.32-hardened-r9, which was the stable hardened version at the time
74 (not to mention stable gentoo-sources, which doesn't even have any of
75 the mitigation measures provided by Grsecurity). It was an obvious patch
76 (now that the bug was found) fixing a 2-year old regression, altering 8
77 lines of code, most of them in the same manner. As noted earlier, the
78 fix was in Portage something like the next day after the CVE came out.
79 So why then was it not backported and stabilized, instead of waiting for
80 stabilization of a new version, which had many new features and
81 associated bugs? And why was it not merged with gentoo-sources in the
82 same manner?
83
84 Regards,
85 Israel G. Lugo

Replies

Subject Author
Re: [gentoo-security] Re: Kernel Security Update Target Delay? Alex Legler <a3li@g.o>
Re: [gentoo-security] Re: Kernel Security Update Target Delay? "Israel G. Lugo" <israel.lugo@×××××××.com>