Stable kernel 2.6.32.8
Stable kernel 2.6.32.8
Posted Feb 10, 2010 4:20 UTC (Wed) by spender (guest, #23067)In reply to: Stable kernel 2.6.32.8 by njs
Parent article: Stable kernel 2.6.32.8
Red Hat (RHEL/Fedora)
Novell (SuSE)
Canonical (Ubuntu)
Debian
Gentoo
Otherwise how can you have any kind of reasonable expectation of security for your vendor kernels?
Why should they all individually have to be playing a guessing game on things that kernel developers already know but deliberately obfuscate? And again, before anyone brings it up again, it's not about the developers themselves trying to figure out if every bug is a security bug -- it's about not hiding or obfuscating what they are clearly aware of. In this case, for starters, it was clearly obvious to both Linus and Greg that a DoS was fixed for amd64 for which a trivial exploit existed. The developers were told by the bugfinder that it was a DoS issue and were sent code to trigger it. It seems obvious stopping this insane policy of deliberate obfuscation would reduce the ridiculous lengths each individual vendor has to go through to turn kernel developer weasel words into actual assessments of bugs.
As an example, the mremap "fixes" that went into the stable tree recently -- a huge set of patches with only vague descriptions of what was being fixed: Red Hat assigned it a cvss2 score of 7.2, saying that it was more than just DoS fixes (7.2 puts it in the highest category of severity, if you weren't aware). Ubuntu (and I believe another distro) just released an advisory for the same set of fixes recently, saying that they only fixed a memory consumption problem leading to a DoS. This is the kind of confusion "a bug is just a bug" causes.
What we know for sure is that "they" (being the kernel developers) don't care about telling us about security bugs once they learn they exist. Greg didn't mention the amd64 DoS by name, and all the commit messages involved in fixing it avoid mentioning it as well (Linus' work here).
While we're on the topic of fixing security bugs though, one security vulnerability that wasn't fixed in 2.6.32.8 was the move_pages() infoleak, which affects kernels >= 2.6.18. If you're running RHEL 5.4 x64, you're vulnerable to the infoleak, which unlike the recent leaks of tiny amounts, involves a leak within a 512MB range. It was posted to oss-sec 3 days prior to the release of 2.6.32.8, and the fix was a trivial 2 lines.
I wrote up an exploit for the vulnerability within an hour of the oss-sec email, available here: http://grsecurity.net/~spender/exp_sieve.txt and integrated into the enlightenment exploit framework here: http://grsecurity.net/~spender/enlightenment.tgz
Finally, I reported two security issues to a prominent kernel developer that affect all 64bit kernels since 2.6.26 several months ago and they've yet to be fixed. You'll be shouting your "a bug is just a bug" mantra until it's revealed months from now that there's yet another vulnerability in the mmap_min_addr code (making null pointer dereference bugs exploitable again) that would have been prevented if the issues I reported months ago had been fixed.
-Brad
Posted Feb 10, 2010 4:38 UTC (Wed)
by njs (subscriber, #40338)
[Link] (7 responses)
Dude, all I did was correct the record on what they said, not make any claim myself. Why you gotta sweep me up into some drama in your head?
Posted Feb 10, 2010 4:42 UTC (Wed)
by spender (guest, #23067)
[Link] (6 responses)
-Brad
Posted Feb 10, 2010 8:53 UTC (Wed)
by chad.netzer (subscriber, #4257)
[Link] (5 responses)
I personally think Linus's position is more compelling:
Posted Feb 10, 2010 21:07 UTC (Wed)
by ballombe (subscriber, #9523)
[Link] (4 responses)
Linus argues that for most patches, it is unknown whether it fixes a security issue, and so it is misleading to mark a small subset of them as 'security fix', and that cherry-picking patches marked 'security fix' create a false sense of security.
However, the stable kernel team job is precisely to cherry-pick patches, and it can be expected that some of them have been picked because they fix a security issue.
Posted Feb 11, 2010 8:00 UTC (Thu)
by chad.netzer (subscriber, #4257)
[Link] (3 responses)
Posted Feb 11, 2010 10:16 UTC (Thu)
by nix (subscriber, #2304)
[Link] (2 responses)
Posted Feb 11, 2010 18:13 UTC (Thu)
by chad.netzer (subscriber, #4257)
[Link] (1 responses)
Posted Feb 12, 2010 0:03 UTC (Fri)
by nix (subscriber, #2304)
[Link]
Posted Feb 10, 2010 22:25 UTC (Wed)
by vonbrand (subscriber, #4458)
[Link]
OMG, not this nonsense again...
Work flow is that somebody notices a bug, and fixes it. Somebody else (stable team) goes through the set of patches and picks those they consider "important enough" and "non-intrusive" to include in the next point release. Here "important enough" certainly includes potential security problems, but nobody goes through the (not trivial) work of checking if it is a real security problem or just a "can't ever happen, but the code is badly written anyway" or even creating an exploit. In parallel, somebody figures out something is a (potential) security problem, and gets it a CVE number. There is no connection between the commit fixing the problem (which is probably taken almost verbatim from vanilla, just to be on the safe side) and any CVE announcement and/or exploit writing. Ergo, that information rarely (if ever) shows up in changelogs.
This is not some world-wide conspiracy to hide security problems, the kernel's developers are doing their best to fix known problems (which includes security problems). Want a more stable, secure system? Then you have to check it more (you are certainly welcome to help out) and/or beat more on it (i.e., wait longer while testing and looking it over).
Perhaps the tools should be enhanced so PaXteam (or others) can publish annotations to the commits in the stable (or even vanilla) kernel tree (without touching the originals) tieing the commits to whatever CVE or other anntotations they deem appropiate.
Posted Feb 11, 2010 13:46 UTC (Thu)
by tao (subscriber, #17563)
[Link] (2 responses)
And was your trivial 2 line fix merged in the 2.6.33-tree (reasonably early) before the release
Posted Feb 11, 2010 23:58 UTC (Thu)
by nix (subscriber, #2304)
[Link] (1 responses)
Posted Feb 15, 2010 15:50 UTC (Mon)
by BenHutchings (subscriber, #37955)
[Link]
Stable kernel 2.6.32.8
Stable kernel 2.6.32.8
Stable kernel 2.6.32.8
http://kerneltrap.org/Linux/Security_Bugs_and_Full_Disclo...
http://kerneltrap.org/mailarchive/linux-kernel/2008/7/15/...
Stable kernel 2.6.32.8
Stable kernel 2.6.32.8
shown to be a security fix as well, should it be rewritten to indicate it as such,
or is it not easier to just track this elsewhere where commits can be
unambiguously referred to? If the issue is that security fixes and commits
aren't being disseminated or discussed, surely that can be addressed outside
of commit messages.
Stable kernel 2.6.32.8
Stable kernel 2.6.32.8
Stable kernel 2.6.32.8
but attacks only get worse, never better: it's safe to say 'this is a
security hole', because it's not going to *stop* being a security hole.
Stable kernel 2.6.32.8
Stable kernel 2.6.32.8
wasn't fixed in 2.6.32.8 was the move_pages() infoleak, which affects kernels >= 2.6.18. If
you're running RHEL 5.4 x64, you're vulnerable to the infoleak, which unlike the recent leaks
of tiny amounts, involves a leak within a 512MB range. It was posted to oss-sec 3 days prior
to the release of 2.6.32.8, and the fix was a trivial 2 lines."
of the 2.6.32.8 kernel? If not, your argument fails. The -stable kernels only merge fixes that
have already been integrated in the mainline kernel (sometimes more simple or hackish
fixes than the mainline fix, but if the issue isn't fixed in mainline, then the fix doesn't go into
-stable either).
Stable kernel 2.6.32.8
three-day-long review period for 2.6.32.8 started. Patches don't normally
land in a given stable release after the review period starts for that
release unless specifically requested.
Stable kernel 2.6.32.8