| |||||||||||||
Speaking with codeSpeaking with codePosted Jul 25, 2009 0:27 UTC (Sat) by man_ls (subscriber, #15091)In reply to: Which is which by dlang Parent article: Quotes of the week
yes, they are opposed to people releasing exploits against released kernels. that is because they recognise that it's frequently not trivial for people to change their kernels, so by releasing exploits you are doing the bad guys work for them.What we have seen here is that, while Brad's sometimes shrill voice has in the past got him nowhere, a working exploit has mobilized a lot of developers to work on several attacked areas. Not working for the bad guys but making the good guys work for us. As I said before code speaks much louder than words.
(Log in to post comments)
Speaking with code Posted Jul 25, 2009 0:56 UTC (Sat) by dlang (✭ supporter ✭, #313) [Link]
Brad's shrill criticisms have mostly been about how badly the kernel devs have handled things after the fact. this is the first one that I've seen where he has presented a bug instead of complaining abut how other bugs are handled.
there are a _lot_ of bugs that get reported, some security bugs, most not. and they do get worked, it doesn't take publishing an exploit to get them to jump on it and fix it. it may take telling a developer what you are seeing and how you think it could be exploited (as a security person myself I see a lot of times when I see something that I think is an obvious hole, but it takes me explaining for a while before even other security people see the same thing)
now, if this bug had been presented and explained and the kernel devs blew him off, further steps are nessasary, but as I understand it in this case, the bug was reported, fixes were already in the works when the exploit was released.
Speaking with code Posted Jul 25, 2009 1:07 UTC (Sat) by man_ls (subscriber, #15091) [Link] Combining your message with nix's you get precisely to my point: after the exploit was released kernel devs started not just closing that bug, but dealing with whole categories of bugs. As explained by Jon at length in this very weekly edition:But this exploit suggests that there could be a whole class of related problems in the kernel; there is a definite chance that similar vulnerabilities could be discovered - if, indeed, they have not already been found.and All told, the posting of this exploit has served as a sort of wakeup call for the kernel community; it will, with luck, result in the cleaning up of a lot of code and the closing of a number of security problems.Reporting each bug would probably have served to just close a few tiny bugs, but the exploit made kernel devs think beyond that. Which is exactly what we need.
Speaking with code Posted Jul 25, 2009 1:07 UTC (Sat) by spender (subscriber, #23067) [Link]
Then you missed my similar exploit in 2007 that introduced NULL ptr dereferences as an exploitable bug class. It was the entire reason mmap_min_addr was introduced in the first place.
-Brad
Speaking with code Posted Jul 25, 2009 1:36 UTC (Sat) by dlang (✭ supporter ✭, #313) [Link]
but if you pointed out a problem and they implemented a fix, doesn't that indicate that they care and are interested in fixing the problems?
the fact that that fix didn't solve all possible aspects of this problem is unfortunate, but not more than that (you didn't see the implications at that time or you would have made more of a fuss then)
by the way, I do think that there are times when it's necessary to develop exploits, I don't remember exactly which thing, but within the last few months there was some exploit (I think DNS) where there were reports of people looking at the flaw and saying 'they managed to make an exploit of _that_???'
and I do think that if a vendor does not respond in a reasonable time there is a need to shame them (the bad guys aren't going to remain ignorant of the exploit forever, especially if the good guys are talking about it)
however I strenuously disagree with the people who believe that full public disclosure with exploit code should be the first step
Speaking with code Posted Jul 25, 2009 1:22 UTC (Sat) by spender (subscriber, #23067) [Link]
The only thing that was fixed when the exploit was written was the tun.c bug, which was fixed with no mention of any security impact (understandable since I had opened up yet another bug class as being exploitable). Everything else was fixed either in response to obvious hints/statements in videos I released a week prior to the exploit, or in response to the exploit itself.
Still waiting on anyone from Red Hat/Fedora to report a CVE for the SELinux issue and tell their users how long they've been vulnerable to null ptr dereference kernel exploits because of it.
-Brad
Speaking with code Posted Jul 25, 2009 12:40 UTC (Sat) by nix (subscriber, #2304) [Link]
I'm curious: since they've said they don't think it's a bug (more an
expected tradeoff: if you run SELinux without useful policy this is what you get, and no, I don't agree with that either), why would *they* give it a CVE?
Speaking with code Posted Jul 25, 2009 12:53 UTC (Sat) by spender (subscriber, #23067) [Link]
Well, perhaps because they asked me to cancel the CVE request I put in (which I still haven't gotten a response from) so that they would submit their own:
Brad Spengler wrote:
Thanks Brad.
Can you cancel the request? I will assign one (faster), and provide you
-Brad
|
|||||||||||||