LWN: Comments on "Stable kernel 2.6.25.7 released"

Not so fast

zakalwe2 — Fri, 20 Jun 2008 01:37:29 +0000

>>since your claim of some peculiar form of non-malicious dishonesty is incoherent

No honey, your ass doesn't look big in that at all.

Not so fast

nix — Thu, 19 Jun 2008 21:47:28 +0000

The dictionary definition of a straw man argument is arguing !A and then 
concluding !B, where A is not a precondition of B.

What I'm doing is considering slight variations on what you're discussing 
in order to figure out if *they* have any merit (since your claim of some 
peculiar form of non-malicious dishonesty is incoherent I haven't wasted 
any time considering that case at all).

My apologies for *daring* to consider tangential cases at all. I wasn't 
aware I wasn't allowed to discuss such things.

(Your claims of 'exposure' reek of paranoia. In fact pretty much 
everything you've posted reeks of paranoia.)

Not so fast

nix — Thu, 19 Jun 2008 21:30:24 +0000

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

Not so fast

man_ls — Thu, 19 Jun 2008 20:16:46 +0000

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

Not so fast

spender — Thu, 19 Jun 2008 14:34:37 +0000

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

PaXTeam — Thu, 19 Jun 2008 14:06:37 +0000

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

Not so fast

man_ls — Thu, 19 Jun 2008 13:18:02 +0000

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

PaXTeam — Thu, 19 Jun 2008 10:31:01 +0000

> Er, I was pointing out that it would be significant if we saw things
> getting covered up and not fixed. We don't.

er, i was pointing out that it was *not* what we had been talking about all along. we talked
about things getting fixed but *not* communicated properly, in particular, the security impact
of fixes was sometimes omitted even when it was full well known. that *is* dishonest, no
matter how much you argue the opposite:

> I just don't think it's 'dishonest'.

that is *not* 'I'm agreeing with you', no matter how you spin it later.

but i said all this a 100 times already by now yet *you* keep diverging into irrelevant
possibilities that we have never raised. you tell me who has a reading comprehension propblem.
also it has been your strategy to change the subject of discussion slightly in order to be
able attack it then. that meets the dictionary definition of a strawman. i know you never
liked it when i exposed every one of your attempts, but that should not be reason to resort to
ad hominem in lieu of rational arguments (you probably figured out by now that i'm not a
native speaker, right?). as you so aptly said:

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

"Stable" kernel 2.6.25.7 released

nix — Thu, 19 Jun 2008 09:47:21 +0000

If you're not a native speaker, might I suggest *not* engaging in vast flamewars based solely
on parsing fine details of the meanings of words?

(Sheesh.)

Not so fast

nix — Thu, 19 Jun 2008 09:45:44 +0000

Er, I was pointing out that it would be significant if we saw things getting covered up and
not fixed. We don't.

(Are you *so* confrontational that you assume that when I'm agreeing with you, I'm actually
trying to argue against you, so my point is thus a 'straw man'? If this is actually what's
happening, you're functionally incapable of reading English as far as I'm concerned.)

Not so fast

nix — Thu, 19 Jun 2008 09:39:42 +0000

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

The core issue

PaXTeam — Thu, 19 Jun 2008 00:47:48 +0000

> Well, if what you want to see is mostly keywords, it changes things a
> *lot*. As I said, building a proper commit is a tough work.

it wasn't me who decided that the kernel security bug disclosure policy should be that of full
disclosure. you're free to change it if you can't live up to it for whatever reason.
alternatively, you can make the archives public after the embargo so that people can get the
whole picture. the current situation is not good as it hurts users.

> But in general, adding simple keywords such as "security" or "CVE"
> on subject line helps a lot.

indeed and this is what's missing among others in 2.6 commits (which is what we've been
complaining about, not 2.4).

> Now, about the lists' "full disclosure" after the embargo, I disagree
> with your interpretation.

'full disclosure' is not subject to interpretation. if you withhold information, then it's not
'full', period. check the full-disclosure mailing list if you don't believe me (it's full of
exploit code, there's no embargo observed, etc). you're free to call yours something else and
then everyone will know what to expect.

> Saying that an embargo is over and a bug is public does not mean you can
> talk about everything with everybody. Most common examples are exploits.
> So there's no "full disclosure" commitment, in fact it's pretty the
> opposite. More like a confidentiality commitment.

i know all that Willy, that's why i said that vendor-sec was known *not* to practice full
disclosure. the kernel security list however, as of now, has a declared full disclosure
policy.

> You don't get it. Nobody asked anyone to keep silent.

not true. you stated yourself the vendor-sec list rules that you don't talk about issues in
public. this one was no different, the list rules still apply. if the list had been public, do
you think Intel would have told you about this bug?

> Nobody simply set an end to the embargo.

not true, there was an embargo set but it came and went, nothing happened except the patch got
into at least one distro afterwards, that effectively made it public and thus ended the
embargo.

> You may find this cowardly because noone is responsible that way. But on
> another point of view, the guy may finally come up with a usable fix

you know now that it's not possible because the bug can only be fixed in hw properly.

> and the risk of massive exploitation will have remained lower than with a
> gratuitous disclosure without a workaround.

so you're saying that the world would have been better off if the FDIV and F00F bugs had never
become public? are you seriously justifying this new Intel coverup?

> Also, it was not "intel". Just one individual, not authoritative of
> Intel. That makes a difference too because threatening him will not
> threaten intel, but he would simply stop working on the subject.

someone posting from @intel.com cannot state on his own behalf that Intel would not provide
the code sequences that trigger the bug. and holding Intel accountable is not threatening
them, except their bottom line if angry customers hold them, well, accountable for their bad
decisions.

> But I don't know why I'm explaining this, you seem well informed already.

the world isn't Willy, that's the problem. and when Intel does finally fix the bug in a future
chip, what will happen to the people running with the old ones? will you/they keep them
ignorant about their buggy chips forever?

> Last, about "obfuscated commits", the suspicious examples you collected
> concern Chris, Linus and Paul. Why not talk to them directly,

and tell them what they already know? i don't see the point...

> showing evidence of those bugs being actively used for years before
> their fix and trying to convince them to be more verbose, instead of
> whining on a forum they might never read about general kernel devs
> practises ?

we're not whining, we're telling the world that things are not exactly as one would naively
believe. although i don't expect kernel devs to read everything on lwn, i know that many of
them read this one and they got the message. question now is what they'll do with it, in
particular, will they live up to full disclosure, or will they keep downplaying security
issues.

> Build up a collection of evidence, show them privately or publicly as
> you like, and explain what issues you find there and why you think
> it's bad to proceed that way. It will be quite more productive IMHO.

the evidence is in secret mailings lists. will you make the archives public? this is the point
we made: noone is accountable because everything is done in secret. how can *we* change that?

> I'm for "responsible disclosure" instead of "full disclosure".

i posted somewhere below what Linus had to say about 'responsible disclosure' (look for
'mental masturbation'). you're in wild disagreement, to say the least.

> Also, keep in mind that most bug reports come from vendors' customers,
> and at least for that reason you cannot divulgate too much of their
> context, otherwise your security channel gets a bad reputation and you
> quickly don't get bug reports anymore.

noone asked for that (although the kernel devs' commitment to full disclosure would imply
disclosing even such information, personally i don't care or think it's interesting or
necessary).

> Last, I would say that most people interested in security updates are
> already on security lists : distro vendors and stable maintainers.

not true at all. one must meet some definition of 'elite' to get on these lists. you know full
well how individual researchers are *not* welcome on vendor-sec for example.

> If you feel like you'd need to get more information on the security
> issues, you may ask to join those lists, and even participate in
> elaborating more suitable commit messages.

i may ask and i will get rejected. thanks, but no, thanks.

> If you can respect a certain level of confidentiality, you may finally
> get the information which seems to be missing you too much, and finally
> notice that there is no such common agreement about deliberate
> obfuscation.

i don't need to be on any list to notice when something's covered up. FWIW, i'm not the first
one to have made such an observation: http://marc.info/?l=bugtraq&m=115255401805462 - you know
who he is, right?

Not so fast

PaXTeam — Wed, 18 Jun 2008 23:17:26 +0000

> 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' ;).

The core issue

wtarreau — Wed, 18 Jun 2008 21:53:54 +0000

Hi,

I'm replying quickly because I'm fed up with wasting my time writing in
HTML textareas, and I still have bugs to chase down in other areas.

> it doesn't overflow anyone's mailbox or git repo if you include a
> *single sentence* saying that this is a potentially exploitable buffer
> overflow or NULL deref or whatever. people can grep for the keywords and
> make further judgements based on whatever extra research they deem
> necessary (including asking the committer for more details)

Well, if what you want to see is mostly keywords, it changes things a
*lot*. As I said, building a proper commit is a tough work. Simply adding
keywords or phrases such as "maybe exploitable, costs nothing to merge
anyway" is not hard. We've been trying to work like this at least on 2.4,
noticeably with Dann Frazier from Debian who reported quite a bunch of
fixes. But in general, adding simple keywords such as "security" or "CVE"
on subject line helps a lot.

Now, about the lists' "full disclosure" after the embargo, I disagree
with your interpretation. For instance, vendor-sec charter explicitly
states :
   "...security problems first reported on vendor-sec should not be
    discussed publicly...".

Saying that an embargo is over and a bug is public does not mean you can
talk about everything with everybody. Most common examples are exploits.
So there's no "full disclosure" commitment, in fact it's pretty the
opposite. More like a confidentiality commitment.

> you should have left the list the moment Intel first had asked you to
> keep silent

You don't get it. Nobody asked anyone to keep silent. Nobody simply set
an end to the embargo. You may find this cowardly because noone is
responsible that way. But on another point of view, the guy may finally
come up with a usable fix and the risk of massive exploitation will have
remained lower than with a gratuitous disclosure without a workaround.

Also, it was not "intel". Just one individual, not authoritative of
Intel. That makes a difference too because threatening him will not
threaten intel, but he would simply stop working on the subject. But I
don't know why I'm explaining this, you seem well informed already.

Last, about "obfuscated commits", the suspicious examples you collected
concern Chris, Linus and Paul. Why not talk to them directly, showing
evidence of those bugs being actively used for years before their fix
and trying to convince them to be more verbose, instead of whining on
a forum they might never read about general kernel devs practises ?

Build up a collection of evidence, show them privately or publicly as
you like, and explain what issues you find there and why you think
it's bad to proceed that way. It will be quite more productive IMHO.

Once again, I'm all for giving enough information to users to justify
upgrades, while not giving enough to script kiddies. I'm for
"responsible disclosure" instead of "full disclosure". The real bad guys
are not dangerous, they have their targets and already know about the bug.
Dangerous ones are the script kiddies destructing systems to impress their
friends. That has happened a lot with the vmsplice bug. I've even read
public records of IRC channels where stupid kiddies compared their
performance on their respective friends' colocated systems. In that sense,
giving a link to a CVE and a minor adequate summary is the right thing to
do in my opinion. It can be left to the reader to push analysis further if
he wants to.

Also, keep in mind that most bug reports come from vendors' customers,
and at least for that reason you cannot divulgate too much of their
context, otherwise your security channel gets a bad reputation and you
quickly don't get bug reports anymore.

Last, I would say that most people interested in security updates are
already on security lists : distro vendors and stable maintainers. Rest
of the world either rely on their vendor or on mainline kernel. If you
feel like you'd need to get more information on the security issues,
you may ask to join those lists, and even participate in elaborating
more suitable commit messages. If you can respect a certain level of
confidentiality, you may finally get the information which seems to
be missing you too much, and finally notice that there is no such
common agreement about deliberate obfuscation.

Willy

Not so fast

spender — Wed, 18 Jun 2008 21:53:12 +0000

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

man_ls — Wed, 18 Jun 2008 21:39:51 +0000

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

PaXTeam — Wed, 18 Jun 2008 17:59:27 +0000

> Everyone involved is quite open about what's going on, so
> how it could be considered dishonest is quite beyond me 

where did you see 'everyone involved' being open? not here. not a single person who
participated in the withholding of known security impact info posted to this thread or
admitted doing so.

>and it's not as if we see holes with actual significant impact being not fixed:

strawman warning ;)! we did *not* talk about bugs not getting fixed. we talked about bugs not
getting properly described in the commits. where did you pull this one from? but now that you
did, i'll actually ask you a question: if a commit doesn't contain security info (such as the
ptrace self-attach fix), how are people running their own kernels supposed to know to pick
such commits up (think of distibutors, not only individuals)? they can't therefore all *their*
users are unnecessarily exposed to risk.

"Stable" kernel 2.6.25.7 released

PaXTeam — Wed, 18 Jun 2008 17:47:17 +0000

> (Quibbling over the meanings of words only works if you know what the
> meanings of those words actually *are*.)

hear hear brother! and let me help you out while i'm at it:
http://dictionary.reference.com/search?q=malice . malice requires intent to harm another out
of hostility, or something like that, you're the native speaker, i'm sure you can interpret it
properly. now, the kernel devs did not actually want to do anything like that, they simply
wanted to save face and look better in statistics, or so. that's not malice, only dishonesty
(they did know what they committed to in Documentation/SecurityBugs and did violate that
promise).

> If something is accidental or unintentional it's not dishonest.

strawman warning ;)! the suppression of security info in the commits we pointed out as such
was neither accidental nor unintentional (nor malicious, just dishonest), so i have no idea
what you're talking about.

"Stable" kernel 2.6.25.7 released

nix — Wed, 18 Jun 2008 16:55:14 +0000

Sheesh. Dishonesty *implies* bad intent. If something is accidental or unintentional it's not
dishonest.

(Quibbling over the meanings of words only works if you know what the meanings of those words
actually *are*.)

Not so fast

nix — Wed, 18 Jun 2008 16:52:08 +0000

I agree with everything you've said in that comment.

I just don't think it's 'dishonest'. Everyone involved is quite open about what's going on, so
how it could be considered dishonest is quite beyond me (and it's not as if we see holes with
actual significant impact being not fixed: please, 'root can get complete control of the
system' is likely to impact a number of systems given in single digits, given that on
virtually every system out there root *already* has complete control: and 'hold back for a few
days until the major distros have updated' also seems reasonable. CPU bugs with security
impact are an entirely different kettle of silicon, and I have no idea what the right thing is
to do there, especially if the bug is one that can't be fixed with a microcode update:
someone's going to get hurt sooner or later no matter what you do).

"Stable" kernel 2.6.25.7 released

PaXTeam — Wed, 18 Jun 2008 14:13:10 +0000

i don't think i ever talked about malice, what i did say was dishonesty (they're not the
same). dishonesty about having a commitment to the public yet doing something else behind the
scenes. no bad ill is required for such behaviour, my *guess* is that it's normal human
psychology: you don't need to deal with the problems you don't admit you have. just look at
last week's LWN interview with Andrew Morton (he's fully aware of what's going on on the
security lists) and how he downplays the problem of security bugs, almost as if they were on
the verge of dying out because they're in fringe driver code and so rarely in core code. yeah,
of course they're rare if they don't publish the security impact of those bugs. watch this
quote:

  That being said, I have the impression that most of our "security holes"
  are bugs in ancient crufty old code, mainly drivers, which nobody runs
  and which nobody even loads. So most metrics and measurements on kernel
  security holes are, I believe, misleading and unuseful.

of course said "metrics and measurements" are "misleading and unuseful" if the kernel devs
falsify the input data.

"Stable" kernel 2.6.25.7 released

NAR — Wed, 18 Jun 2008 13:52:47 +0000

OK, this is a kind of "smoking gun" - in spite of the "full disclosure policy", a kernel
developer tried to avoid full disclosure. But still, I'd like to get back to the Napoleon
quote. Maybe the translations altered the meaning of the proverb, but I understood that
"incompetence" contained "simple human mistake" too. This quote you shoved does not prove
malice for me, it could be a simple human mistake (or if a security professional goes for
"security through obscurity", than it's a sign of incompetence). 

As a software developer, I know that we have a couple of rules that we should obey (just like
the kernel developers have rules e.g. for full disclosure). I also know that we tend to break
these rules: out of ignorance, convenience, lack of time, sometimes incompetence - but I've
never seen someone break these rules maliciously.

Even the amount of exploitable security bugs not labelled as such does not prove malice for me
- after all, there are many people fixing these errors, they can make many mistakes. I believe
your standards are just too high. A security professional should be exceptionally paranoid,
but even most kernel developers are not that paranoid.

I think this thread shows that there are other problems with the current kernel development
process, not just those that are usually mentioned (lack of review, regressions, etc.).

Not so fast

spender — Wed, 18 Jun 2008 13:44:02 +0000

Some get it, but some do not (the ones trying to misinterpret all the provided evidence to
support their view).  Unfortunately for them, the way things are is often not as how we
imagine or would like them to be.

If even Willy is saying that Linus intentionally omits security information at times in his
commits, which he is fully aware of at the time of the commit, why are you still quibbling
with us?  I was surprised myself Willy was so honest about this (I appreciate it), and it
meshes with the private evidence I have.

In general, from the evidence I have, the people in charge of handling security put forth a
lot of effort and in most cases handle things properly.  This is especially true of bugs that
are submitted to them from the outside, where security-relevance is either explicitly
mentioned or suggested.

But in some cases (the specific examples already provided and others I'm currently compiling),
things aren't handled properly.  It seems so far that these involve bugs that haven't been
labeled as security-relevant by individuals/companies in the public realm.  Many of these bugs
seem to be DoS-related.  On their private lists will exist PoC code to trigger them, so their
security-relevance is well known to the members of the private lists, and yet often it's these
that get handled improperly.

Like we had been arguing, this isn't a conspiracy.  They don't coordinate on the lists on how
to cover up the security bugs for the day.  But there does seem to be some adherence among
some to an "unwritten rule", that if they aren't being publicly held accountable for
something, the rules can be relaxed.  The problem is they end up hurting themselves (and all
of us) this way, since when things aren't mentioned properly publicly through the changelogs,
it often never gets proper classification (see the SELinux remote DoS at the bottom of the
page).

As to why you continue to argue, this might help explain the uncomfortableness you're feeling:
http://en.wikipedia.org/wiki/Cognitive_dissonance

-Brad

"Stable" kernel 2.6.25.7 released

olecom — Wed, 18 Jun 2008 13:41:02 +0000

>> IT bubble days are over. Linux kernel (almost the only useful FOSS
>> thing left) tries to not loose it's volume.
>
>Ok, so let's ignore gcc, Apache, 

Or simply "almost the only critical (functionality and security) OS part, useful FOSS thing
with no alternatives" to pass flamewar guard, and let us on the subject and >>the message
body<<.

"Stable" kernel 2.6.25.7 released

PaXTeam — Wed, 18 Jun 2008 13:20:59 +0000

the truth isn't always pleasant. neither are strawmen, that seems to be your debate technique
and that didn't work here ;). nevertheless that didn't stop me from responding to you, did it?
i asked you once already, let me repeat that here again: what do you really want from *us*? we
made our point, explained it a dozen times already, what's left for you to do is to check the
facts out for yourself. you said you weren't interested or something like that, then why do
you keep posting irrelevant things?

> (I'm frankly not surprised PaX isn't in the kernel if you're always this
> confrontational, whatever its technical merits.)

i'm frankly not surprised you brought up yet another irrelevant point here. FYI, PaX isn't in
the kernel because, drumroll.... it has *never* been submitted. imagine that! ;) and as a
sidenote, PaX features *are* in the kernel but that's whole different story.

Not so fast

PaXTeam — Wed, 18 Jun 2008 13:06:02 +0000

> So very many people are failing to get the point: might it be that
> you're not expressing yourself very well?

not many, only first time posters who simply didn't read what i said before.

> Either that or you're saying this to divert attention from questions you
> can't answer.

which questions would they be (and you probably meant "don't want to", as you can't seriously
expect me to answer questions that i, well, "can't" ;)? if i missed anything, feel free to
point them out to me.

"Stable" kernel 2.6.25.7 released

nix — Wed, 18 Jun 2008 12:52:23 +0000

No thanks. You're simply too unpleasant to respond to anymore, and your debate technique is
frankly enraging.

(I'm frankly not surprised PaX isn't in the kernel if you're always this confrontational,
whatever its technical merits.)

Not so fast

nix — Wed, 18 Jun 2008 12:49:54 +0000

So very many people are failing to get the point: might it be that you're not expressing
yourself very well?

(Either that or you're saying this to divert attention from questions you can't answer. Well,
I suppose there is the alternative that virtually everyone else on this forum can't understand
English. I know which I think is more likely.)

Kernel bug 9416

PaXTeam — Wed, 18 Jun 2008 12:17:24 +0000

> In all this (by now extremely tiresome) discussion I have seen not a
> shred of evidence of wrongdoing.

would that be because you haven't actually seen/read everything? if you have, please tell me
the history of this commit/bug:
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-... .
if you don't see it immediately from the linked commit it's because it was intentionally
omitted. but you can always ask the committer. will you?

> Perhaps carelessness, perhaps people not seeing potential security
> problems. Bugs get fixed, most developers care that it is a bug and
> don't care much if it might be a security problem.

that shows how much of the discussion you saw. pretty much nothing. the issue is *not* with
people not realizing the security impact of bugs (noone expects people to disclose what they
don't know), but rather with intentional withholding/downplaying the same when it *is* known
to them. i gave you a lead above, try to find out what happened there and be shocked.

Kernel bug 9416

PaXTeam — Wed, 18 Jun 2008 12:10:54 +0000

> What is wrong here? The commit message cites a bug report saying that
> the kernel might have a buffer overflow.

you just said it yourself ;). 'buffer overflow' is *the* very common and usual term to
describe this kind of bug, not 'copying overly-long strings'. mind you, it's even shorter to
type and would immediately match everyone's mental filters for security related commits (it
happened to match my 'look for funny looking commits' filter only, and i've grown one only
because i realized there was a need regarding kernel commits. pretty sad.). so, why was it
omitted/rephrased in an unusual way (a simple google fight shows that 'buffer overflow' has
over a million hits, whereas the other phrase gives a few thousand), especially since the
original bugreport said so already?

Not so fast

PaXTeam — Wed, 18 Jun 2008 11:55:16 +0000

> 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

man_ls — Wed, 18 Jun 2008 06:57:25 +0000

where did we suggest that 'our way' is to unleash full blown exploits on the unsuspecting public in order to stress the bug's importance?

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 can see why giving this kind of information away in the kernel commits (even a CVE id) scares people. I don't think it was a misrepresentation, but whatever.

FYI, every one of the commits we brought up had been discussed on either the kernel security list or vendor-sec.

If it is vendor-sec then Documentation/SecurityBugs does not apply. When it is the kernel security list it applies, but this policy document doesn't say what you seem to think it says. It clearly states that kernel security officers will disclose what they are told as they see fit, and anyone reporting the bug cannot rely on secrecy upon their part.

From what we have seen bugs are disclosed, just not the way you like. 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".

does your definition of 'minor' also match that of the rest of the world?

In this thread we have seen a bug which cannot be exploited ("still, this pattern is dangerous, someone had better audit the code for it."), another one only exploitable by root and a local DoS (i.e. a crash). I sincerely hope the rest of the world also thinks these things are minor.

says who? 'man_ls' or is it the agreed-upon kernel policy?

I say that security professionals who rely upon kernel commits to perform security assessments are crazy. If you think it is sound professional conduct, let me know where you get your security. If for "agreed-upon kernel policy" you are referring again to Documentation/SecurityBugs, then you are still deluding yourself. Where does it say that "kernel commits will contain all available information for security professionals"? Bugs are disclosed and that is what they agreed to.

"Stable" kernel 2.6.25.7 released

aleXXX — Wed, 18 Jun 2008 06:48:18 +0000

Could you please try to be consistent at least with yourself ?

Alex

Kernel bug 9416

vonbrand — Wed, 18 Jun 2008 04:20:28 +0000

"Avoid copying overlong strings" does make my (mostly untrained!) alarm bell go nuts. If that is "obfuscation"...

In all this (by now extremely tiresome) discussion I have seen not a shred of evidence of wrongdoing. Perhaps carelessness, perhaps people not seeing potential security problems. Bugs get fixed, most developers care that it is a bug and don't care much if it might be a security problem. Others try to filter "important" (by whatever measures) fixes to apply to the "-stable" (by their measure) tree. If you disagree, you are wellcome to set up the "-secure" tree and do your own filtering and applying. In doing so, you won't be able to rely blindly on the commit messages (the bug fixer might be completely incompetent at seeing security implications) or the discussions that went before (they could all very well be completely off track), so this is hard, thankless work. If you moreover succeed in recruiting a bunch of hackers to help out, more power to you. That would be a real help, flinging all sort of conspiracy theories and ill will accusations around is counterproductive. If the people here (myself included) had spent their time chasing bugs instead of flaming around, we would all be better off.

Kernel bug 9416

spender — Wed, 18 Jun 2008 03:28:22 +0000

Let's get straight what you were actually commenting on here, since you were turning it into
something it wasn't.

Willy said:
"And please, do not say "obfuscate" when speaking about commit logs,
it's more like "summarize", even if extreme summarization may lead to
obfuscation."

So the PaX team gave an example, where the commit subject was "isdn: avoid copying overly-long
strings".  I agree with them that this isn't a summary but rather a strained attempt at
obfuscating the issue.  Nothing would have been wrong with just copying the description from
the bugzilla entry, it wouldn't have required the invention of clever new phrases, and
wouldn't have required that people click on a bugzilla entry to figure out what was actually
fixed.

Please read and comprehend before posting.

-Brad

Kernel bug 9416

vonbrand — Wed, 18 Jun 2008 02:28:24 +0000

What is wrong here? The commit message cites a bug report saying that the kernel might have a buffer overflow. And that is somehow "hiding" potential security implications, when it took me a few seconds to see that it could be a very serious issue?

Come on, now... a real conspiracy theory needs to hint at more secrecy than that!

The core issue

vonbrand — Wed, 18 Jun 2008 01:07:04 +0000

Or create a device for /, mount it somewhere, and cd there. Or a hundred other creative ways to escape, or to thoroughly thrash the system... As root in (traditional) Unix there is nothing that stops you. And that with SELinux you can make UID 0 powerless doesn't mean that that is common today, even where SELinux is enabled by default.

Sure, if there is a bug that could make the system crash or misbehave, it should be fixed. But if only root can exploit it, it is definitively much lower priority than the same that any user can trigger locally or (even worse) remotely.

Not so fast

PaXTeam — Wed, 18 Jun 2008 00:58:34 +0000

i didn't elaborate on man_ls's strawmen because he missed the point entirely, so i didn't see
it important besides mentioning the fact (he was arguing disclosure policy like you do,
instead of that of consistency). now i just mentioned one, see somewhere above. satisfied? ;)

> If you announce to the world that something is a security bug then every
> script kiddies and their mom will know about it.

> If you are careful about keeping quiet it then distributors may miss a
> important security fix they need to provide to their end users.

you too didn't get the point. i don't care about the disclosure policy per se, i care about
being consistent, or shall i say, truthful about it. if Documentation/SecurityBugs says 'full
disclosure' then the people on that list had better practice it. if they don't, they should
say so in Documentation/SecurityBugs. above you're trying to argue about the disclosure
policy, feel free to take it to where it belongs, but it's not the subject of this discussion.
as for the rest of your post, does that really belong here?

Not so fast

PaXTeam — Wed, 18 Jun 2008 00:41:15 +0000

> "Straw man" commonly refers to the misrepresentation of someone's
> position. I don't see where I misrepresented your position, but I'm
> sorry that you feel I did.

where did we suggest that 'our way' is to unleash full blown exploits on the unsuspecting
public in order to stress the bug's importance?

> The policy for security bugs you cite is specifically for people who
> contact the security team.

stop right there. we weren't talking about anything else but security issues discussed and
subsequently covered up in secret lists. what happens in public forums is not under
discussion.

> If a specific bug doesn't reach them I don't see why that policy should
> apply at all.

in that case what's the question at all? what they don't know they can't cover up.

> In some of the bugs you have brought up the security implications seem
> minor at best, so maybe that is why they were not sent to the security
> team; 

which ones are you talking about? FYI, every one of the commits we brought up had been
discussed on either the kernel security list or vendor-sec. besides, what do you call 'minor'?
does your definition of 'minor' also match that of the rest of the world? did you make sure?
then what entitles you to make that judgement call instead of the world? see, you already
showed the exact bad mindset that plauges the kernel devs engaged in covering up security
bugs. *you* don't get to decide what is important information for *other* people. the *other*
people do. understand?

> Anyway for these bugs kernel devs are free to apply whatever disclosure
> policy they see fit

what bugs again? if bugs are not on a secret list then they're in a public one, what's there
to 'disclose' that isn't already public?

> They should not trust commit messages,

says who? 'man_ls' or is it the agreed-upon kernel policy? do you even realize what you just
said?

"Stable" kernel 2.6.25.7 released

olecom — Tue, 17 Jun 2008 23:36:26 +0000

Exactly!

Seriously:
* binutils/as with really good macro support using `sed`
* zoo of web servers (one's problem if Java version x.y.z.X.Y.Z is needed somewhere)
* Emacs (though nothing more that just text editing is useful in any "IDE")
* bind && sendmail are pride of security holes of past and present (there are alternatives
like exim and qmail for the latter, and some others for former)
* don't know any useful application of zoo of scripting languages except flame wars, otoh i'd
like to have shell be not as it was 20 years ago. Now python 3000 is going to be Java-like,
Ruby runs out of gas (afaik).
* cmake? Oh, man: shell (with one Linux and one libc it's not an autoconf-like mess any more),
ccache (which is 2 time faster shell + sed anyway)
* eCos? maybe, as well as zoo of other abandoned small/tiny OSes
* web browsers? lynx + nc + sed (quite seriously, even for some needed javascript)
* office? in case of bureaucracy maybe, FYI there's only MS there
* X and other useless stuff for what? for global warming?
* php, Tomcat, sdcc (same as above)
* Samba (see office)
* FreeBSD != FOSS, it's a BSD, LSD and such
* Darwin. Don't know, can't say anything

+ mplayer? yes, unless google will open all-codecs-and-file_formats-->ogg
and btw it runs on in pure text-mode using memory mapped framebuffer of modern VGAs just fine

i'd add xpdf (yea, needs X), free console fonts (terminus), inn2, slrn (nothing is hype, but
are very useful).

more importantly accessibility of PDF and web content to simple ASCII + images representations
and no JavaScript/Flash. No w3c handwaving, but real value of information with high SNR.

In case if you are an engineer in architecture, electronics, etc., you will have expensive
proprietary CAD systems, possibly based on Linux kernel and some version of GNU libc. Real
industry is not a joke, handcrafting or religion. Eclipse platform and derivatives doesn't
belong here or they are fancy solutions around basic functionality.