| |||||||||||||
Finding Linux Bugs Before they Become Exploits (internetnews.com)Finding Linux Bugs Before they Become Exploits (internetnews.com)Posted Jul 27, 2009 16:33 UTC (Mon) by JoeBuck (subscriber, #2330)Parent article: Finding Linux Bugs Before they Become Exploits (internetnews.com) 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?
(Log in to post comments)
Finding Linux Bugs Before they Become Exploits (internetnews.com) Posted Jul 27, 2009 17:08 UTC (Mon) by hppnq (guest, #14462) [Link] In the article it says:
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. ;-)
Finding Linux Bugs Before they Become Exploits (internetnews.com) Posted Jul 28, 2009 15:29 UTC (Tue) by jamesmrh (guest, #31622) [Link]
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.
Perhaps I misunderstand the legalese...
Finding Linux Bugs Before they Become Exploits (internetnews.com) Posted Jul 28, 2009 17:44 UTC (Tue) by bcopeland (subscriber, #51750) [Link] 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.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.
Finding Linux Bugs Before they Become Exploits (internetnews.com) Posted Jul 27, 2009 17:12 UTC (Mon) by spender (subscriber, #23067) [Link]
Both. If you read my exploit and some of my other posts here recently about this topic (where I linked to a paper about the % of Coverity reports that are being triaged by kernel developers), the first stable kernel that had the vulnerability they're talking about (my exploit exploited multiple vulnerabilities -- this fact has been somewhat lost on some) was 2.6.30. The vulnerable code was submitted for inclusion in the kernel back in February however and existed in some 2.6.30-rc kernels (if it was submitted a month earlier perhaps, it might have made it into 2.6.29 instead).
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
Finding Linux Bugs Before they Become Exploits (internetnews.com) Posted Jul 27, 2009 17:26 UTC (Mon) by JoeBuck (subscriber, #2330) [Link] 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) Posted Jul 27, 2009 17:37 UTC (Mon) by spender (subscriber, #23067) [Link]
Well, they do have a point that if the report wasn't ignored, then yes it would have killed that particular bug (but the entire class wouldn't have been fixed, nor would the SELinux vulnerability).
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
Finding Linux Bugs Before they Become Exploits (internetnews.com) Posted Jul 27, 2009 17:39 UTC (Mon) by mattmelton (subscriber, #34842) [Link]
I believe Brad has said it was the bug report that led him to it. After all, who doesnt find this appealing:
>> [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.
|
|||||||||||||