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 |