Not so fast [LWN.net]

Not so fast

Posted Jun 18, 2008 11:55 UTC (Wed) by PaXTeam (subscriber, #24616) [Link]

> I think my scenario (find vuln, exploit it, publish and get CVE id, then
> send commit with CVE in message) is almost as dangerous without a
> published exploit.

i see you haven't seen my other posts in the thread, so i'll ask you as well: how do you know
you're the *first* one to find and exploit a given bug? answer: you don't. from that point on
your entire argument falls apart because that was the one assumption it rested on (if you're
not the first one then you're not saving anyone but yourself, from embarrasment). not to
mention that you're talking about something we never did: nowhere did we say that we want
exploit code in commits for example. 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. will you crucify them because they're spreading terror among the populace,
to paraphrase you?

> I don't think it was a misrepresentation, but whatever.

you don't? did you even read how you introduced that scenario? here it is for you again:

> you have to realize the consequences of the way advocated by spender and
> PaXTeam

now you tell me how this is not putting words into our mouth. where did we say anything
remotely resembling that? unless you can point to a post we made, you put up a strawman and
attacked it as if it was relevant to the discussion (it wasn't, for other reasons as well, see
my comments on disclosure policy vs. consistency/honesty).

> If it is vendor-sec then Documentation/SecurityBugs does not apply.

other rules still do and they don't call for hiding security impact information. but you're
not a member of either list therefore you couldn't know.

> When it is the kernel security list it applies, but this policy document
> doesn't say what you seem to think it says.

it says full disclosure. the initial participants knew full well what that means. to show that
the whole concept isn't exactly foreign to them, here's a few choice Linus quotes:

  I really _despise_ people who think security is an issue of hiding bugs.
  If they then try to make themselves look good ("no zero-day exploit, we
  fixed it immediately"), they're worse than low.

  The only thing that seems to work for security is public shaming.

and another addressed to vendor-sec:

  I don't care what the hell people do on vendor-sec, and you can do your
  "responsible" mental masturbation all you want, but as far as I'm
  concerned, the _only_ responsibility I have is to fight that tendency to
  hide bugs as much as I can.

you tell me if he was advocating withholding security impact info or not. yet we showed how he
did exactly that himself.

> It clearly states that kernel security officers will disclose what they > are told as they
see fit,

no, it doesn't say that. the only wiggle factor it mentions is about setting the disclosure
*date*, not its amount.

> and anyone reporting the bug cannot rely on secrecy upon their part.

no secrecy = full disclosure. thanks for confirming it.

> From what we have seen bugs are disclosed, just not the way you like.

you either don't read or understand what i'm saying. you're once again talking about
disclosure policy, not consistency. i will say it again then, in the hope you get it: i do
*not* care about the chosen disclosure policy per se, i *do* care about holding it up. so when
the current Documentation/SecurityBugs says 'full disclosure', i expect that. if it said
something else, i'd expect that then. clear enough now?

> You are getting all worked up because commit messages do not reflect the
> kind of information you would like to be there, and that is fine, but it
> does not follow from the document that it should be there. "Full
> disclosure" is not "crying wolf".

you don't know what full disclosure is about, that's clear already. please, if you want to
save further embarrasment for yourself, go read up on the subject before making further silly
comments like the above. hint: disclosing security impact information is not "crying wolf".

> In this thread we have seen a bug which cannot be exploited

those commits were mentioned in passing only because they looked suspicious, not because there
was any coverup related to them. 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
is there).

> I say that security professionals who rely upon kernel commits to
> perform security assessments are crazy. 

and i say that you're not a security professional. the ultimate goal/job of said professionals
is helping the risk management process and any useful piece of information is valuable input
to that. if a given piece of information turns out to be false (because, say, someone decides
to not hold up to his publicly declared full disclosure policy), then there can be
misjudgement and bad decisions affecting innocent people down the ladder. so in case you still
didn't get it: kernel commits are one source of information and it's of great help (read: time
and human resource saver) when one can simply grep the changelogs for keywords. and one would
rely on that because he believes that commits are actually part of the full disclosure
process. 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
for example).

> Where does it say that "kernel commits will contain all available
> information for security professionals"? 

here:

  We prefer to fully disclose the bug as soon as possible.

for actual security professionals (unlike you, that is), 'fully disclose' has a specific
meaning. the kernel devs know it as well. go ask *them* if you're in doubt. so when a commit
and the bug its fixing doesn't get a CVE, we have a problem (i gave an example of that, read
the thread).

Not so fast

Posted Jun 18, 2008 21:39 UTC (Wed) by man_ls (subscriber, #15091) [Link]

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 is there).

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 process. 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 for example).

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 meaning.

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.

Not so fast

Posted Jun 18, 2008 21:53 UTC (Wed) by spender (subscriber, #23067) [Link]

I had hoped the 100th post to this thread wouldn't have been from a troll who doesn't have one
iota of understanding about the meaning of "full disclosure."  You talk a lot for someone who
is obviously not involved in security at all ("the underworld"..really?) and yet you choose to
disagree about things you admit you won't even bother to research yourself.  You're the
epitome of a delusional zealot.

-Brad

Not so fast

Posted Jun 19, 2008 9:39 UTC (Thu) by nix (subscriber, #2304) [Link]

man_ls compliments you, and you respond that he's a delusional zealot.

This thread is giving me so *very* many examples of how not to communicate...

Not so fast

Posted Jun 19, 2008 14:34 UTC (Thu) by spender (subscriber, #23067) [Link]

I'm guessing you were fooled by the juxtaposition of "spender" and "good examples."  If you
had actually read his entire post in context, as I did, you wouldn't have replied in such a
way so as to blatantly expose your poor reading comprehension and "reply-without-reading"
mentality (which seems to be a common theme in your postings).

-Brad

Not so fast

Posted Jun 19, 2008 20:16 UTC (Thu) by man_ls (subscriber, #15091) [Link]

nix is usually a very lucid commenter. Your post says quite more about you than about him.

Not so fast

Posted Jun 19, 2008 21:30 UTC (Thu) by nix (subscriber, #2304) [Link]

Hay fever drugs *are* kind of turning my mind off at the moment, but 
still...

Not so fast

Posted Jun 18, 2008 23:17 UTC (Wed) by PaXTeam (subscriber, #24616) [Link]

> 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.

your point was clear in fact, and i told you it rested on this one assumption. maybe you
didn't realize it, in that case let me explain it in more detail. you said this:

> I think my scenario (find vuln, exploit it, publish and get CVE id, then
> send commit with CVE in message) is almost as dangerous without a
> published exploit.

then added:

> Et voilà! You have an unpatched vulnerability (with a published exploit > in the wild) on
millions of machines worldwide, and everyone who doesn't > update their kernels daily is
vulnerable. Is this responsible disclosure?

this comment of yours makes sense *only* if you're the first one to find and exploit a bug. if
you're not then those 'millions of machines worldwide' have been exploitable all along, well
before *you* found the bug. your entire argument falls apart since the
'end-of-the-world-if-i-disclose' situation you describe had already happened. see the point?
the only thing that changes when you, the second or later comer publishes an exploit is that
more people become able to use it - the amount of vulnerable machines does *not* change, only
the amount of actually exploited machines may. your argument is a typical fallacy coming from
advocates of various forms of 'responsible disclosure', check bugtraq and other security lists
for endless debates about it, or just the Linus quote ;).

> Talk about straw men...

well, let's see again what you said:

> I can see why giving this kind of information away in the kernel commits
> (even a CVE id) scares people. 

am i misunderstanding this or did you actually say that 'giving away even a CVE id in kernel
commits scares people'? 

> 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.

that's not how CVE ID assignment works: you publish to a security list (vendor-sec, kernel
security, etc) and you get one assigned *automatically* by one of the guys monitoring these
lists. you don't go out of your way to get one.

> This was after complaining at length that several "security" bugs didn't
> have a CVE.

it wasn't 'security' bugs, it was security bugs. or at least one specific example i provided
that was known to be a local DoS yet nothing happened.

> Well, if there is a CVE provided with the patch then let it be
> published;

i'm glad we agree on this. now go tell that to Linus because he consistently omits the CVE
even if one's got already assigned by the time of the commit.

> but for these not-so-important issues it would only increase the risk
> for everyone.

what are these 'not-so-important issues? any example? and what risk are you talking about?

> 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.

i hope you're not a kernel contributor either. this attitude of 'fix and forget' is what puts
your users into danger because they will never know they were vulnerable. you may not care
about that fact, but some users do and fortunately you don't get to decide that for them.

> The point is that security devs have a responsibility to disclose
> whatever information is passed to them;

who are these 'security devs'? apparently not the kernel devs because you separated them next,
so i'm left wondering.

> 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.

i'm sorry but that's not what Documentation/SecurityBugs says. of course you're  free to
submit a patch to correct it, then everyone will know the state of affairs (provided that what
you stated above actually reflects the consensus of kernel devs - did you even ask them before
making that comment?).

> In fact he talks about disclosing the bugs, and that is what they do,
> along with a terse evaluation.

in fact he doesn't, he says a bit more than that ('this' was about the embargo):

  The "security@kernel.org" list had lots of discussion about this when it
  was created, and quite frankly, I argued pretty strongly for total and
  full disclosure.

notice 'total and full disclosure'. it doesn't mean omitting security impact of bugs, no
matter how else you'd like to explain it away. if you're still in doubt about what full
disclosure means, i suggest that you ask the people of the mailing list of the same name.

> They were actually mentioned in spender's original message.

uhm, then i didn't get which commits you were referring to. myself, i was talking about the
ones in the previous thread and the one or two extra posted in this one.

> I assumed they were important, and yet they appear to have been
> deconstructed in this long thread.

where was, say, the double-free one deconstructed?

> So those commits he complained about are no good? We have to dig in
> additional list archives? No thanks. 

there're several commits mentioned in this and the previous thread on the same subject, go
look them up before you dismiss them. reading the rest of the posts would also not be a bad
idea before making comments ;). to get you started, find the link to the ptrace self-attach
fix and tell us its story. among others, why it didn't get a CVE.

> 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.

fortunately you don't get to tell them what they should worry about. and i hope there's no
distro that thinks that way. if you know of any that has such a security bug handling policy,
please do make it known to the world at large.

> Yes: do not hide bugs and do not hide security implications. "Do not
> hide" is the relevant part here.

correct.

> It is not "research them yourself"

correct but also strawman, noone expected them to do so.

> nor "publish an exploit"

incorrect, 'full' implies disclosing such information as well, and hard-core full-disclosure
believers actually do that. but i personally don't care if kernel devs publish such code, i
care about knowing that a given commit fixes a bug with security impact at all or not.

> nor "search for the relevant CVE" 

i don't understand this one. why would they have to search for a CVE that gets created as soon
as someone submits a security issue to the security lists?

> "or get one if none exist".

it's automatic as explained above.

> If kernel devs are already fixing the bugs, full disclosure might not be
> so necessary. 

it is their declared policy for security bugs. go convince them that what they're doing 'might
not be so necessary' ;).

Not so fast

Posted Jun 19, 2008 13:18 UTC (Thu) by man_ls (subscriber, #15091) [Link]

OK, I see your point now: publicize all vulnerabilities as much as possible. Still I am not sure that you see mine: kernel devs are not security experts (most of them are probably not in the security list), and you cannot expect that they go out of their way doing security impact analysis. Also, you probably don't want them to. You have shown us several examples of sloppy security assessments; they are probably just not very good at it.

Maybe kernel devs need more training in security, or maybe an independent body doing risk analysis would be the way to go. As a developer who is not a security expert, I can tell you that things look pretty different from the inside. When Linus talks about the tendency to hide bugs and the need to fight it, he has a point.

Not so fast

Posted Jun 19, 2008 14:06 UTC (Thu) by PaXTeam (subscriber, #24616) [Link]

> OK, I see your point now: publicize all vulnerabilities as much as
> possible.

well, that's not so much *my* point, it's what full disclosure means and it's what kernel devs
have committed to. i never said whether i liked/disliked this form of disclosure myself, i
just said that if someone publicly declared to follow such a policy, he'd better do that else
people will be misled and may make bad judgements affecting innocent users.

> kernel devs are not security experts (most of them are probably not in
> the security list), and you cannot expect that they go out of their way
> doing security impact analysis. Also, you probably don't want them to

actually, i did say the very same thing myself, e.g., here: http://lwn.net/Articles/286439/
(there was a reason i asked you to read all the previous posts before making your own).

> You have shown us several examples of sloppy security assessments; they
> are probably just not very good at it. 

no, the examples we wanted to draw attention to were cases where the kernel devs *knowingly*
omitted the security impact information (such as the ptrace self-attach fix). figuring out the
security impact of bugs is a whole different problem and noone expects regular kernel devs to
solve that. but when they see or are told what a given bug does, they'd better not sweep it
under the carpet yet that's exactly what happened.