Which is which [LWN.net]

Which is which

Posted Jul 24, 2009 9:52 UTC (Fri) by dlang (✭ supporter ✭, #313)
In reply to: Which is which by man_ls
Parent article: Quotes of the week

now you are mis-stating the position of the kernel developers.

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.

and I don't believe that they deliberately downplay a known exploitable scenerio by classifying it as a DOS, I do believe that they fix many bugs that they believe are only a DOS at the time they fix them that are later determined to be exploitable.

Brad believes that every fix should be examined and it's security impact determined prior to the fix being submitted (that's the only way the commit message could explain the severity of the bug being fixed)

the kernel developers are more interested in fixing more bugs (and probably introducing a few with the new changes) as a better use of their time.

the kernel developers also fear that if they do start categorizing bugs as 'security' fixes or not, it will be worse in the long run because the fixes that are not classed as security fixes are far less likely to get deployed.

(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:
>> Let me get back to you on this.
>
> I've contacted the relevant people to request a CVE for the issue, as
> the previous bypass of mmap_min_addr was given a CVE back in 2007; this
> should be no different.

Thanks Brad.

Can you cancel the request? I will assign one (faster), and provide you
with the proper credits in the errata.

-Brad