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"
1 Excerpts from Israel G. Lugo's message of Sun Oct 17 15:59:15 +0200 2010:
2 > So what's the conclusion on what happened with bug 337645? What can we
3 > learn from here? That everything went just fine and according to plan?
4
5 Are you kidding?
6
7 > That hardly seems like a realistic assessment. If we ignore mistakes
8 > instead of learning from them, we are doomed to repeat them.
9 >
10 > Regarding the assessment that has been made of this exploit somehow not
11 > being "important", I couldn't disagree more.
12
13 Er, who here assessed the issue to be not "important"?
14
15 > We're not all just running
16 > desktops at home here, clicking on random executables. There are those
17 > of us who run Gentoo Hardened on multiuser servers, which is the first
18 > place I would consider running Hardened to begin with. Some of these
19 > servers simply need to support 32-bit execution as well as 64-bit,
20 > because the users need it to do their job. It's not such a strange
21 > requirement in the real world; just think of development environments,
22 > for example. Yes, or proprietary tools -- as much as I would love to
23 > have a world entirely based on FOSS, unfortunately I don't have the
24 > luxury of pretending that proprietary software doesn't exist, or that
25 > it's not necessary in some cases, especially when I am supporting other
26 > users who may need it.
27 >
28 > It would be wonderful if malicious executables and malicious users could
29 > never exist; the world would certainly be a happier place. Sadly, things
30 > don't work that way, and that's why we have to worry about security in
31 > the software industry to begin with. I would think it shouldn't have to
32 > be explained that the ability for a local user to get root access by
33 > compiling a piece of code and running it is a very bad thing.
34
35 You seem to be assuming that we (=Gentoo people) live in a dream world
36 and still need to be told about hackers and the need for IA32-emul code
37 even today. We don't. So please stop discussing such banalities we are
38 all well aware of and instead get to the point.
39
40 > Your own
41 > vulnerability treatment policy ranks it as A1 level, and correctly so in
42 > my opinion.
43 >
44
45 Besides the fact that the VTP is still not applicable to Kernel
46 packages, we now do seem to rank things correctly? Can you please make
47 up your mind?
48
49 > Whether the fix was in tree within 4 hours or 4 days is irrelevant; the
50 > fact is that a stable release didn't come out until a week later (in the
51 > hardened version), when a trivial fix was already in tree, is very bad.
52 > The fact that the general-public gentoo-sources remained vulnerable to
53 > the exploit for 3 weeks is appalling.
54 >
55 > Yes, there were mitigating security measures *in the hardened sources*,
56 > which broke the *publicly known* exploits. It is still hiding one's head
57 > in the sand to assume that just because the symbols are hidden, no one
58 > else might come up with a cleverer exploit. Just think back to the
59 > original flaw from 2+ years ago, and the exploit techniques that scanned
60 > the memory looking for function signatures, for example. Yes, Grsecurity
61 > provides an additional layer of defense in depth, *on hardened-sources*,
62 > but that's it: it's only a stop-gap measure, a best effort in case a
63 > vulnerability appears, to minimize the possibility for damage until the
64 > vulnerability gets fixed. The point is that a very serious vulnerability
65 > is there: certainly the Gentoo Security team are the first people who
66 > would want it fixed.
67
68 Again: Stop with the banalities.
69 No one claims that workarounds or mitigations are equivalent to a fix in
70 the source code.
71 Yes, the Security team are the first ones to want things (properly)
72 fixed, however we cannot just jump in and fix things. We have to work
73 with maintainers and arch teams. This issue clearly has shown that there
74 are frictional losses that need to be addressed.
75
76 > Then there's the case of gentoo-sources, which has no Grsecurity and
77 > therefore no mitigation whatsoever. Surely the users of the normal
78 > kernel (including myself on my home PC, for example) aren't mistaken for
79 > expecting that the high standard of quality, stability and security
80 > provided by Gentoo will still apply to them...
81 >
82 > I am and have always been an avid defender of Gentoo, for I agree with
83 > the philosophy behind it, and admire the consistent high quality work of
84 > the developers and maintainers, the second-to-none documentation, the
85 > practicality of the rolling release, the unrivaled flexibility of
86 > Portage, and I could go on. But when we have a local root exploit, with
87 > a known fix, that clings on for this long, it's just sad. It hurts the
88 > Gentoo image, and leaves it wide open to unfair blanket criticism like
89 > we saw near the end of the 337645 bug thread. Every major distribution
90 > had a fix for this very important problem within a couple of days; it
91 > tarnishes the otherwise magnificent security efforts undertaken by the
92 > Gentoo dev team that 3 weeks later the exploit was still there.
93
94 ..which is basically the same thing you said on the bug. Can we get to
95 the poi..
96
97 >
98 > So, concrete question:
99
100 ..nt now? Finally! Thank God.
101
102 >
103 > The fix could have easily been backported to the stable kernels, and a
104 > new intermediary stable release could have been launched. I even went to
105 > the trouble of submitting a patch, the upstream fix made against
106 > 2.6.32-hardened-r9, which was the stable hardened version at the time
107 > (not to mention stable gentoo-sources, which doesn't even have any of
108 > the mitigation measures provided by Grsecurity). It was an obvious patch
109 > (now that the bug was found) fixing a 2-year old regression, altering 8
110 > lines of code, most of them in the same manner. As noted earlier, the
111 > fix was in Portage something like the next day after the CVE came out.
112 > So why then was it not backported and stabilized, instead of waiting for
113 > stabilization of a new version, which had many new features and
114 > associated bugs? And why was it not merged with gentoo-sources in the
115 > same manner?
116
117 As the maintainers are primarily responsible for providing unaffected
118 ebuilds, you'll need to ask the kernel team for exact reasons.
119
120 As for the 'lessons learned' part, it does seem that the resolution of
121 this issue was very much focused on updating to newer versions while
122 forgetting about alternatives (i.e. backporting). That's something that
123 we can do better next time.
124
125 Communication could be improved, too. Reading bug 337645, there was
126 little contribution from the Kernel team with regards to stabilizing
127 unaffected sources. That could be improved by noting progress or
128 problems. Then again my team (Security) could have asked for such info
129 earlier when there was no update.
130 At the same time I also have to address the users who made useless
131 comments on that bug. Of course, with a better resolution strategy on
132 our part, such things are less likely to appear, but people need to
133 remember that a bug tracker is not the place for random rants (which
134 again drain the motivation of the volunteers involved in the issue).
135
136 Something I'd like to see as a productive outcome of this issue, is a
137 little Kernel bug best-practices document for improving the interaction
138 of the various teams.
139
140 Yours most sincerely,
141 Alex
142 --
143 Alex Legler <a3li@g.o>
144 Gentoo Security/Ruby

Attachments

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

Replies

Subject Author
Re: [gentoo-security] Re: Kernel Security Update Target Delay? Richard Freeman <rich0@g.o>
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>