Finding Linux Bugs Before they Become Exploits (internetnews.com)
The issue of patching aside, the public exploit could easily have been a zero day exploit on the Linux kernel itself, were it not for the fact that the bug that enables the exploit was caught by a scan from code scanning vendor Coverity. The Linux kernel has been actively scanned by Coverity since at least 2004 in an effort to find bugs and improve code quality."
Posted Jul 27, 2009 16:33 UTC (Mon)
by JoeBuck (subscriber, #2330)
[Link] (7 responses)
Posted Jul 27, 2009 17:08 UTC (Mon)
by hppnq (guest, #14462)
[Link] (2 responses)
Maybe none of the kernel developers has a Scan account, which I believe is required in order to receive the scan results?
Also read Brad's comment on the article. ;-)
Posted Jul 28, 2009 15:29 UTC (Tue)
by jamesmrh (guest, #31622)
[Link] (1 responses)
Perhaps I misunderstand the legalese...
Posted Jul 28, 2009 17:44 UTC (Tue)
by bcopeland (subscriber, #51750)
[Link]
I understand their intent, but it also scared me away from signing up. Supposing I wanted to put a lot of work into sparse or some other static checker, I fear that having a Coverity account might taint that effort. Especially if their IP extends to "class of bugs we search for."
I wonder how many other developers stay away for similar reasons.
Posted Jul 27, 2009 17:12 UTC (Mon)
by spender (guest, #23067)
[Link] (3 responses)
Coverity's scanner found the bug shortly after, but the report was ignored. The patch that was submitted to fix the bug was in response to a submitted OOPS report with a POC for triggering the bug: http://lkml.org/lkml/2009/7/4/14
The article is inaccurate and misleading in other ways, which I've commented on their site to correct.
-Brad
Posted Jul 27, 2009 17:26 UTC (Mon)
by JoeBuck (subscriber, #2330)
[Link] (2 responses)
Posted Jul 27, 2009 17:37 UTC (Mon)
by spender (guest, #23067)
[Link]
It may just be poor reporting on the part of internetnews.com, since Coverity's blog doesn't make the claims that the above article does. Here's a link to their blog post:
It does of course nicely avoid the fact that the report was ignored, though ;)
I also don't like how so much emphasis is put on when someone says they found a vulnerability, since such information is generally extrapolated to apply to cases where it doesn't apply. The fact that I (a person looking at commit messages occasionally in my spare time because I'm more interested in silent fixes) started working on an exploit after the bug was fixed doesn't at all imply that that's how a blackhat (or anyone else) operates. Their financial/time resources and interests and motivations are completely different from mine.
-Brad
Posted Jul 27, 2009 17:39 UTC (Mon)
by mattmelton (guest, #34842)
[Link]
>> [14610.772456] BUG: unable to handle kernel NULL pointer dereference at
The combination of mmap fp overwrite and OOPS avoidance (cf unix personalities/selinux) was Brad's effort.
I suspect this is the Coverity PR machine doing the rounds, but not entirely without merit: Coverity did find this bug (and their software has the capcity), but nobody noticed. So many things haven't worked as expected, and the lack of attention to the Coverity report is just another one slipped through the cracks.
Posted Jul 27, 2009 22:34 UTC (Mon)
by brianomahoney (guest, #6206)
[Link] (3 responses)
Perhaps DARPA should get Coverty, at least at its present level into the public domain.
Posted Jul 28, 2009 9:39 UTC (Tue)
by tialaramex (subscriber, #21167)
[Link] (2 responses)
Making the tool available is a side issue. If someone hired such a hacker for the next 12 months, or even if Linus, or Alan, or anyone else with a track record wanted to sit and spend August checking and fixing Coverity reports that could be done right now, no problem. It doesn't require putting Coverity into the public domain, which is good because AFAIU there's actually a significant difference between the technology "developed largely at public expense" and the nice shiny Coverity product. Posted Jul 30, 2009 4:46 UTC (Thu)
by proski (subscriber, #104)
[Link]
I'm confused about what is being claimed here. Coverity has had the relevant check (a pointer is dereferenced, and then after it is dereferenced it is compared against NULL) for years, and they've been scanning the kernel for years. So why wasn't this caught before? Is it new code, or was an existing Coverity report being ignored?
Finding Linux Bugs Before they Become Exploits (internetnews.com)
In the article it says:
Finding Linux Bugs Before they Become Exploits (internetnews.com)
"Our builds were broken in February and March so we didn't see it immediately when the code was first committed," David Maxwell, open source strategist for Coverity told InternetNews.com "But we've had it flagged in the system since March and it was fixed on the fifth of July."
Finding Linux Bugs Before they Become Exploits (internetnews.com)
I've read the license for the Scan account, and it's not clear to me whether I should agree to it; e.g. if they find a vulnerability I may then not able to discuss it publicly because it's part of their IP.
Finding Linux Bugs Before they Become Exploits (internetnews.com)
Finding Linux Bugs Before they Become Exploits (internetnews.com)
The patch was not submitted in response to any static checker scan.
I'm trying to determine if Coverity has any relevance at all here. Did a Coverity report alert you to the bug that you then exploited? Or is Coverity PR just trying to claim credit without justification?
Finding Linux Bugs Before they Become Exploits (internetnews.com)
Finding Linux Bugs Before they Become Exploits (internetnews.com)
http://blog.coverity.com/posts/general/would-you-like-to-...
Finding Linux Bugs Before they Become Exploits (internetnews.com)
0000000000000080
Coverty, exploits, DARPA
Coverty, exploits, DARPA
The bug was reported by Julia Lawall, who found it using Coccinelle. Now Coverity is trying to take the credit.
It was Coccinelle, not Coverity