Not so fast
Posted Jun 18, 2008 21:39 UTC (Wed) by man_ls
In reply to: Not so fast
Parent article: Stable kernel 184.108.40.206 released
how do you know
you're the *first* one to find and exploit a given bug? answer: you don't.
Who cares. For all we know the underworld might be teeming with exploits, it doesn't change a thing. If you think it does change, then my point was not clear enough.
as for how putting even as little info as a CVE in
commits scares people, go tell that to the -stable guys because they're trying their best at
doing exactly that.
Talk about straw men... What is scary is not talking about a published CVE, but going out of your way to obtain one for every bug with possible security ramifications, instead of just fixing the damn thing. As spender said:
Generally when a kernel bug is identified as security-relevant, someone creates a CVE for it.
This was after complaining at length that several "security" bugs didn't have a CVE.
Well, if there is a CVE provided with the patch then let it be published; but for these not-so-important issues it would only increase the risk for everyone. In other cases (for crying out loud, a local DoS -- i.e. a crash) I don't see the point. When there are other more pressing affairs it is reasonable to just fix the things and forget about them. If it is done in broad daylight and not in a proprietary dungeon then it is even better.
the only wiggle factor it mentions is about setting the disclosure
*date*, not its amount.
The point is that security devs have a responsibility to disclose whatever information is passed to them; but kernel devs are free to research it themselves and disclose their findings
at will. Even if Linus fills his mouth with "full disclosure" panegyrics. In fact he talks about disclosing the bugs, and that is what they do, along with a terse evaluation. See spender's original message
for three good examples. They are not silently fixed as in other proprietary operating systems.
hint: disclosing security impact information is not "crying wolf".
Of course it is not, and you will notice that my original sentence was very similar to yours (even if the sense was very different). Let me try to rephrase it so it is more understandable: "Full
disclosure" [of information passed to kernel devs] is not [kernel devs themselves] "crying wolf" [at every opportunity]. You will see it makes more sense this way.
those commits were mentioned in passing only because they looked suspicious, not because there
was any coverup related to them.
They were actually mentioned in spender's original message. I assumed they were important, and yet they appear to have been deconstructed in this long thread.
the subject of this discussion is commits where we did say
coverup and you tell us what happened there (go ask for the mailing list archives, the answer
So those commits he complained about are no good? We have to dig in additional list archives? No thanks.
and i say that you're not a security professional.
Who said I was? If I told you I play one on TV, would it help the discussion? Neither are most kernel devs, and yet there they are happily building their kernel.
and one would
rely on that because he believes that commits are actually part of the full disclosure
when they aren't, one can miss things unless he invests in a whole lot more resources
to figure that out himself (don't only think of companies but also other distro maintainers
I hope my distro maintainers are keeping up with important issues, and not worrying about every "local DoS" that appears in kernel commits. Likewise with root-exploitable bugs.
for actual security professionals (unlike you, that is), 'fully disclose' has a specific
Yes: do not hide bugs and do not hide security implications. "Do not hide" is the relevant part here. It is not "research them yourself" nor "publish an exploit" nor "search for the relevant CVE or get one if none exist". Those things are worthwhile but not part of "full disclosure", I think.
If you or any other security pros are willing to discuss it further (and help the three remaining readers get bored to death) feel free to. But please keep in mind that "full disclosure" is a means to an end: make kernel devs fix dangerous bugs and close security holes. It is not the other way around: fixing bugs is not the way to full disclosure. If kernel devs are already fixing the bugs, full disclosure might not be so necessary.
to post comments)