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 |