Stable kernel 2.6.25.7 released [LWN.net]

The -stable team has released the 2.6.25.7 kernel. The description reads much the same as for 2.6.25.6: "It contains a number of assorted bugfixes all over the tree. Users are encouraged to update."

to post comments

"Stable" kernel 2.6.25.7 released

Posted Jun 17, 2008 1:38 UTC (Tue) by spender (guest, #23067) [Link] (113 responses)

In this issue of "we have no clue what we're doing," we have:

"Format string bug. Not exploitable, as this is only writable by root,
but worth fixing all the same."
http://git.kernel.org/?p=linux/kernel/git/stable/linux-2....

Sorry, but when protections such as SELinux are implemented in the kernel which are meant to
make uid == 0 not mean a full compromise of a system, the ability to completely subvert the
kernel and thus all of these protections does in fact make this a security issue.

"double-free of inode on alloc_file() failure exit in create_write_pipe()"
http://git.kernel.org/?p=linux/kernel/git/stable/linux-2....

Is at minimum a local DoS. Max out your file descriptors and create a pipe, refcnts on the
file will be wrong and free_pipe_info will get called on a possibly trashed inode. In fact,
the bugzilla entry referenced by the commit calls it a DoS and provides code to cause the DoS:
http://bugzilla.kernel.org/show_bug.cgi?id=10878

Yet again no CVE and no mention of security despite the committer's obvious knowledge of the
implications of the bug.

Meanwhile we have:
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-...
waiting to be fixed in -stable, which is trivially exploitable.

We also have vendorsec sitting on a patch from Serge Hallyn fixing the vulnerability in TPM i
alluded to in my previous posting. One week on a one-line fix which has yet to make it
upstream (which Serge requested be fixed ASAP).

I'm sure there's more fun to be found in these "bugfixes" but I only looked for a few minutes.

-Brad

"Stable" kernel 2.6.25.7 released

Posted Jun 17, 2008 1:46 UTC (Tue) by dlang (guest, #313) [Link] (10 responses)

like it or not, despite the fact that SELinux is in the kernel, most kernel folks (like most
other admins) don't use it. As such the fact that root can do something nasty is not
considered a critical/exploitable fix

as for the one where you complain about no CVE number, is there a number allocated for this,
or are you complaining becouse the person who found and fixed the problem didn't jump through
whatever hoops are needed to create one first?

for the one that's in Linus' tree but didn't get into -stable, did anyone send it to -stable
and they rejected it, or is it one of the many patches that got upstream that the author
didn't send to -stable?

as for the one in vendorsec, it is disappointing that vendors are taking this long to deal
with it.

"Stable" kernel 2.6.25.7 released

Posted Jun 17, 2008 2:32 UTC (Tue) by spender (guest, #23067) [Link] (9 responses)

I'm not sure when the last time you used Linux was, but SELinux is enabled by default on
Fedora and RHEL (and others I'm sure, but I haven't checked).  Your usage argument doesn't
apply anyways, since it doesn't come into play when labeling bugs as security-related for
obscure hardware which may only affect a tiny number of users (much much smaller than the
number of users of SELinux).  Either these bugs need to be taken seriously (and they have in
the past, so I'm not sure why this one was declared a non-issue) or people need to be told
that SELinux is completely worthless against preventing complete compromise as any root-based
vulnerability that can totally subvert its security isn't considered a security bug and thus
won't be backported to any distribution-maintained kernel.

Generally when a kernel bug is identified as security-relevant, someone creates a CVE for it.
The problem in this case was the committer (Al Viro) knew of the security relevance of the bug
but covered it up in his changelog, which resulted in it getting covered up at the -stable
level.  Now tell me how any distribution is supposed to know to backport this security fix if
for this 2.6.25.7 release, as with the 2.6.25.6 release with silently fixed vulnerabilities,
no security implications whatsoever are mentioned?

I don't know about the one that didn't make it into -stable, I was just pointing out that it
belongs to the class of trivially exploitable bugs.  I'm sure when it makes it into -stable
(if it does), its exploitability will again be covered up.

-Brad

"Stable" kernel 2.6.25.7 released

Posted Jun 17, 2008 3:02 UTC (Tue) by bojan (subscriber, #14302) [Link]

> Now tell me how any distribution is supposed to know to backport this security fix if for
this 2.6.25.7 release, as with the 2.6.25.6 release with silently fixed vulnerabilities, no
security implications whatsoever are mentioned?

Excellent point. I actually asked Fedora kernel maintainers to label the latest F9 kernel as a
security fix (I went with the official .5 explanation, although LWN discussion about .6 made
me do it):

https://admin.fedoraproject.org/updates/F9/FEDORA-2008-5308

Although I'm neither security expert nor kernel developer, that double-free in the log made me
think that there could be security issues being fixed. I'm not really sure what's going on
with all this, but I reckon it's always better to err on the side of caution and open CVEs
etc.

"Stable" kernel 2.6.25.7 released

Posted Jun 17, 2008 6:15 UTC (Tue) by dlang (guest, #313) [Link] (7 responses)

I have been using linux as my desktop full time for the last 11 years. I am aware of the fact
that RedHat chooses to enable SELinux by default, but I am also aware of the fact that many
(if not most) sysadmins (as opposed to casual users) end up disabling SELinux as a fairly
routine thing as they start to configure the boxes to be something other then the defaults
that RedHat ships. and from various discussions on the kernel mailing list it's clear that the
most of the kernel developers do as well (those that have RedHat based systems).

the useage argument is that since the kernel developers don't use it, they don't have the
mindset to take it into account when evaluating the severity of bugs, and therefor something
that requires root access to do is not considered that bad as root can already get around the
limitations (even on a RedHat system root is the account that can disable SELinux, so
pretending that SELinux can protect you from rootis wishful thinking)

distribution-maintained kernels will backport or not backport patches on teir own criteria,
not matter what the kernel devs decide to put in a -stable kernel (and note that this patch
did make it into stable, it's not that they didn't fix the problem, it's that you are
complaining that the commit message didn't identify it as a security problem)

"Stable" kernel 2.6.25.7 released

Posted Jun 17, 2008 7:28 UTC (Tue) by nix (subscriber, #2304) [Link] (6 responses)

Oh, in our previous go-round he was quite clear that the problem wasn't 
the commit message... after spending half a dozen messages whining about 
nothing else.

I'm still unclear what the problem actually *is*. There's meant to be some 
sort of huge conspiracy, perhaps focused around not doing whatever Brad 
says the instant he says it (it would help if he didn't say it in such a 
profoundly unpleasant fashion.)

(And I thought I was bad at diplomacy. At least I have interaction modes 
besides `J'accuse' and don't try that one first. If you want to get people 
to do something, telling them they're all in a conspiracy and 
intentionally attacking the general public(?) is not the way to go.)

"Stable" kernel 2.6.25.7 released

Posted Jun 17, 2008 9:32 UTC (Tue) by PaXTeam (guest, #24616) [Link] (5 responses)

> Oh, in our previous go-round he was quite clear that the problem wasn't 
> the commit message... after spending half a dozen messages whining about 
> nothing else.

would you stop distorting the facts? first, it was me who posted quite a few messages, not
Brad, second, the problem *is* with the commit messages in that they intentionally omit
important and known-to-the-developers security information. you were given several examples,
not one of which you contested. it's funny how you keep running around with a huge post sign
shouting conspiracy whereas noone of us said anything like that. what we did talk about was
good old human dishonesty hidden in an unaccountable mailing list. as you quite rightly said
in your last post on that other thread, you should not be talking to us as we can't change the
situation. you should be asking questions to your kernel developers and make them accountable.
unfortunately it seems it's easier to pull strawmen than actually trying to get to the bottom
of this problem.

"Stable" kernel 2.6.25.7 released

Posted Jun 17, 2008 13:47 UTC (Tue) by nix (subscriber, #2304) [Link] (4 responses)

Ah, right, you were talking in such similar ways that I confused you :/ However, you're
assuming that a large number of people are each acting dishonestly for no obvious gain in
different places, with the strong implication of coordination (in that they have all chosen to
be 'dishonest' in exactly the same way: by not mentioning things you consider a security hole
in their commit logs). That's called a conspiracy theory. If you remove the assumption of
dishonesty, it's simply human error, or perhaps that they have lower thresholds for defining
something a security hole than you do. (It would be a miracle if this were not true, given
that most of these people are not security paranoids by nature, and thus are almost bound to
have lower thresholds for such things than you are!)

I'm not contesting the facts: I'm contesting your unnecessarily unpleasant interpretation of
them.

In fact your interpretation makes no sense at all: why would people spend time coordinating to
hide security holes when knowingly doing that could have no consequence other than to harm the
reputation of the system they're working on? Doing that would be ridiculous. Ergo, they aren't
doing that: there is no magically coordinated decision to fix security holes while hiding them
by the single means of describing them differently in commit logs, no conspiracy, no bad
intent. Simply differently-set thresholds.

"Stable" kernel 2.6.25.7 released

Posted Jun 17, 2008 14:47 UTC (Tue) by PaXTeam (guest, #24616) [Link] (3 responses)

i'm not assuming or interpreting anything, i speak of facts i have. for one, it's not a large
number of people, it's the membership of secret lists which by its nature is quite limited.
second, it doesn't take a lot of coordination when you're within your normal social circle
anyway (the same kernel devs who interact on lkml, at conferences, real life, etc), it's
normal human behaviour to stick to the flock lest you get ejected. so no, this is not a
conspiracy (you've been caught again ;).

speaking of facts, what do you have to say about the Paul Mackerras quote and its visible
result in the commit message? what is your interpretation? why was he even raising the point
of how candid he should be in the commit?

> In fact your interpretation makes no sense at all: why would people
> spend time coordinating to hide security holes when knowingly doing that
> could have no consequence other than to harm the reputation of the
> system they're working on? Doing that would be ridiculous.

why would there be consequences when all of this can take place outside of the public eye, in
a completely unaccountable manner?

> Ergo, they aren't doing that:

and you determined that by...? oh right, you didn't. why don't you go ask for the mailing list
archives? that would surely answer all questions, do you agree? and if there's nothing bad to
hide in there, there shouldn't be any objections to getting them.

"Stable" kernel 2.6.25.7 released

Posted Jun 17, 2008 15:40 UTC (Tue) by nix (subscriber, #2304) [Link] (2 responses)

Er, if the holes get exploited, of *course* there's a consequence. And if there's no
possibility that the holes would be exploited, then modifying the commit messages to conceal
the security-related nature of the commits makes no sense.

You're blatantly contradicting yourself now. I've had enough of this thread.

"Stable" kernel 2.6.25.7 released

Posted Jun 17, 2008 16:09 UTC (Tue) by PaXTeam (guest, #24616) [Link] (1 responses)

> Er, if the holes get exploited, of *course* there's a consequence.
> And if there's no possibility that the holes would be exploited, then
> modifying the commit messages to conceal the security-related nature of
> the commits makes no sense.

i have absolutely no idea what you are talking about now. probably another of your strawmen,
but just in case: you were trying to speculate why it makes no sense to downplay/hide security
information in commit messages (mind you, a few posts below you argued the *opposite*, so much
for contradiction ;) since that would only endanger the reputation of their work. except you
forgot the little fact that such coverup took place in a secret list, hence there was no
danger of exposure, on the other hand there was a perceived advantage of not getting bad PR
about the many silently fixed security bugs. and now, out of the blue, you come with this
commit message modification and how it makes no sense for bugs that don't have a security
impact. guess what, if a bug cannot possibly be exploited then it doesn't have a
security-related nature. that's a tautology and i'm not sure what you tried to say with that.
incidentally, we weren't talking about bugs without security impact either. another strawman
down ;).

> You're blatantly contradicting yourself now.

hmm, where? you're making no sense to me now, sorry. but feel free to elaborate. of course if
you just wanted a cheap cop-out, let this rest.

"Stable" kernel 2.6.25.7 released

Posted Jun 17, 2008 18:07 UTC (Tue) by nix (subscriber, #2304) [Link]

As I said, I'm dropping this because we're talking past each other. ('Cheap cop-out'.
Charming.)

"Stable" kernel 2.6.25.7 released

Posted Jun 17, 2008 3:39 UTC (Tue) by gregkh (subscriber, #8) [Link] (37 responses)

> In this issue of "we have no clue what we're doing," we have:

<snip>

Hm, if you have questions/comments/suggestions about our kernel releases, then please, send us
email and cc: the mailing lists.

I will be glad to discuss this there, in public with all of the developers, and put to rest
any issues raised about these releases, how we are doing them, and any potential problems that
you feel are still outstanding and not yet addressed.

But not on a web site comment system, that's just not where the kernel developers do their
work, sorry.

"Stable" kernel 2.6.25.7 released

Posted Jun 17, 2008 4:26 UTC (Tue) by avik (guest, #704) [Link] (36 responses)

He will immediately get 13 (unwarranted) "Do not feed the troll" replies.

Negative comments about the Linux process on lkml receive very negative feedback, especially
if they come from someone who is not a regular contributor.

"Stable" kernel 2.6.25.7 released

Posted Jun 17, 2008 6:08 UTC (Tue) by wtarreau (subscriber, #51152) [Link] (21 responses)

> He will immediately get 13 (unwarranted) "Do not feed the troll" replies.
> Negative comments about the Linux process on lkml receive very negative
> feedback, especially if they come from someone who is not a regular
> contributor.

Then he can post privately to the -stable team. But I think that unfortunately, Brad is not
trying to improve Linux but to demonstrate it's a pile of crap, maybe in order to promote
security add-ons such as grsecurity. But it's doing no service to him either because acting
this way will scare away people who look for a reliable system.

IMHO, he would be of great help if he would accept to be on the -stable reviewers list. He
will be able to remind all of us about security impacts when not perceived, suggest missing
patches just in time for inclusion, he will get general gratitude for this useful work and
will feel proud of really improving the kernel security.

Attacking the work of the stable team as he does now is unfair. The stable series is the thing
which made 2.6 usable, and I know it's a tough work for Greg and Chris. Suggesting and helping
would be more welcome than whining.

And it's not like Brad does not have the skills to do so, which is really a shame.

The core issue

Posted Jun 17, 2008 6:29 UTC (Tue) by bojan (subscriber, #14302) [Link] (15 responses)

For me, the main issue here is this: are these things real security problems or not?

- if yes, CVEs should be opened and logs clearly marked
- if no, then someone should should let us know that they are not

I'm really not in the position to evaluate validity of Brad's claims, but from what I saw in
other discussions, other more qualified people usually cannot refute them.

The core issue

Posted Jun 17, 2008 7:21 UTC (Tue) by wtarreau (subscriber, #51152) [Link] (14 responses)

> For me, the main issue here is this: are these things real security problems or not?

It's not as simple. Security means everything and nothing at the same time. There are people
who consider security only about risk of intrusion. Other people consider the risk of remote
or local DoS. Others the risk of data leak. If we want to be picky, everything which can
permit a non-privileged user to cause a malfunction resulting in a degradation of performance,
integrity, availability, confidentiality or traceability is a security issue.

As you can see, the smallest driver bug can become a security issue. If someone plugs an
usb-serial cable into a machine and makes it crash, it is a security issue if it is normally
not allowed to enter this machine.

Brad tends to be particularly picky about security issues (and it is good to have someone who
really sees a lot of risks as he does). Other people like Al Viro consider that anything which
requires root to impact the security is not a problem, because once your box is rooted, you
have lost. These differences explain why a lot of bugs are not marked as security issues and
are complained about afterwards.

Another example I reported a long time ago : make a chroot, mount /proc into it, install a
shell there, chroot overthere, then "cd /proc/1/cwd". Bingo, you're out of the chroot. Some
people say that since this "cd" already requires to be root, it's not an issue. Others
(including myself) consider it is an issue. It's just a matter of point of view unfortunately.

Overall, I think the security issues are correctly taken by the middle chain (2.4 and
2.6-stable), but the fact that information sometimes gets lost at the starting point makes it
difficult to dig for the whole thing. It depends on who reported the issue and how it was
merged into mainline in fact. Sometimes, big security fix will get immediately merged, even
before a CVE gets assigned. But those ones are not the most difficult to track.

The most difficult ones are the ones which require special knowledge in a specific area and
which are not covered as security problems by the person who initially fixes them (by lack of
knowledge too). This is often the case with drivers.

The core issue

Posted Jun 17, 2008 10:47 UTC (Tue) by PaXTeam (guest, #24616) [Link] (9 responses)

> It's not as simple. Security means everything and nothing at the same
> time.

Willy, please do read the previous discussion before commenting. the problem isn't that people
are unable to determine whether a given bug has a security impact or not. that is a separate
issue and is not the point raised now. the problem we exposed is that of covering up security
impact information when it *is* already known to the kernel developers. you're privy to that
information yourself and in silent agreement with that policy, don't pretend you don't know
(care to explain to the rest of the world that itanium hardware bug still unfixed after 2
years?).

> There are people who consider security only about risk of intrusion.
> Other people consider the risk of remote or local DoS. Others the risk
> of data leak. If we want to be picky, everything which can permit a
> non-privileged user to cause a malfunction resulting in a degradation of
> performance, integrity, availability, confidentiality or traceability is
> a security issue.

and where's the problem? you simply include the relevant info in the commit and let the users
decide which ones they're interested in. the current problem is that by omitting or
obfuscating any such info makes it *impossible* to quickly select the interesting commits.
you're not improving linux security by making it hard for users to make decisions.

> Overall, I think the security issues are correctly taken by the middle
> chain (2.4 and 2.6-stable),

once again, to stress the point: no, they are *not* correctly handled. ask Chris Wright about
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-... .

> but the fact that information sometimes gets lost at the starting point
> makes it difficult to dig for the whole thing.

it doesn't get 'lost', it gets intentionally omitted. and it's not sometimes but pretty much
every time now. case in point,
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-... .
knowing Ilja's past work, i can't imagine he didn't report this as a bug with security impact
(not that it's hard to figure out even if he didn't) yet there's no mention of it in the
commit, not to mention a backport to -stable.

The core issue

Posted Jun 17, 2008 19:08 UTC (Tue) by wtarreau (subscriber, #51152) [Link] (8 responses)


> Willy, please do read the previous discussion before commenting.

I did, and I do not agree with what was said, it is exagerated.

> the
> problem isn't that people are unable to determine whether a given bug
> has a security impact or not. that is a separate issue and is not the
> point raised now. the problem we exposed is that of covering up security
> impact information when it *is* already known to the kernel developers.

Well, I know that Linus does not like to give too much information in
the commits because he believes it will help the bad guys, reason why
he does not add the methods to reproduce the problems nor the CVE when
he does the commits himself. I don't share his opinion here, but that's
personal taste, and after all, it's *his* project.

You have to keep in mind that most often, a commit is a summary of 10-20
mail exchanges with reproducers, tests and results. You cannot put all
that in a commit. OK Linus tends to go to extremes (and believe me, it's
hard for -stable and I to follow those bugs). But I don't think there are
many more people oversimplifying the commits in such circumstances.

Both -stable and I keep the original message when backporting, and look
for any existing CVE information then add it. I have already missed CVE
numbers before committing. It happens.

What I'm really sicked about is the accusations of "general agreement to
deliberately hide security informations from commits". That's false IMHO,
really. And in fact, examples given by Brad were on public lists, so that
does not make any sense.

What we agree about is not to divulgate information when joining the list.
That's the minimalist requirement you can expect from members who you will
send sensitive information. There are times you would like to shake a bit
the tree to get something to speed up, and you cannot. Those moments are
a bit frustrating, but you agreed about the initial rules. But I have
never seen anything there such as "hey shhht! don't tell anybody, let's
fix it silently". It's more like "pfff!! needs to be root anyway, not
relevant".

> you're privy to that information yourself and in silent agreement with
> that policy, don't pretend you don't know (care to explain to the rest
> of the world that itanium hardware bug still unfixed after 2 years?).

As ruled above, I cannot explain this. However, I can paraphrase what
Brad already reported there : http://lwn.net/Articles/285928/
Basically, the fix was deemed wrong and needed some rework. Then no
time to work on it. I recently asked for news about the situation,
because I don't like a fix to remain pending, and response was
that the fix was wrong and not sufficient anyway because of the
reasons Brad already explained. If a fix cannot be developped,
game over! And please don't ask someone to publicly forward the
patch, it will only harm in helping exploitation without bringing
any value towards a possible fix.

Hint: I found the wrong fix is already present in at least one publically
downloadable distro kernel update.

> and where's the problem? you simply include the relevant info in the
> commit and let the users decide which ones they're interested in.

Believe it or not, it is already the hardest part of my work, determining
the relevant information. It is no different than any bug tracking for any
software, people ask for tests, some seem valid and point to one direction,
some seem invalid, some tracks are finally proven wrong. It's very hard to
build a relevant commit message. Sometimes when I read Linus' commits, I
think "oh he's abusing..." but when I try to do the work myself, I
sometimes wonder why I take 30 minutes to try to collect relevant
information to build a useful commit message when it could simply be
a one-liner.

> the
> current problem is that by omitting or obfuscating any such info makes
> it *impossible* to quickly select the interesting commits. you're not
> improving linux security by making it hard for users to make decisions.

I know that, believe me! And this is not limited to security impacts. I
regularly read random 2.6 commits to find if there are fixes relevant to
2.4 or stable. Sometimes I don't know. Sometimes I think I should merge
them, then someone explains me that I'm wrong because the bug cannot be
triggered in my situation.

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

> > Overall, I think the security issues are correctly taken by the middle
> > chain (2.4 and 2.6-stable),
> once again, to stress the point: no, they are *not* correctly handled.
> ask Chris Wright about
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-... .

Could you elaborate please ? This fix is in Linus tree, and I don't see
Chris in the sign chain. Did he report it first ? Also, I'm sorry, but
I fail to see the security implications of this patch, eventhough seeing
"ptrace_attach" catches my attention.

> it doesn't get 'lost', it gets intentionally omitted. and it's not
> sometimes but pretty much every time now. case in point,
> http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-...
> knowing Ilja's past work, i can't imagine he didn't report this as a bug
> with security impact (not that it's hard to figure out even if he didn't)
> yet there's no mention of it in the commit, not to mention a backport to
> -stable.

From what I have seen, this was finally judged as a non-issue since other
checks are in place, which probably explains why you don't have it in
stable. It is very often that fixes for supposedly real vulnerabilities
finally end in mostly code cleanups.

Don't get me wrong, I'm all about transparency, and we're not good enough
at this IMHO. But it is not *that* bad.

What amazes me, to be honnest, is the ability you have to spot patches in
mainline that take a lot of time to other people. I'd love to know how you
proceed, it would save me a lot of time. Or maybe you spend whole days at
this, in which case all users would benefit from your findings. Why don't
you post on LKML, to -stable or even on security lists links to the patches
you consider suspicious security-wise ? Even assuming everyone's honnest
in the chain, and the other people considered the bug inoffensive when you
think the contrary, you could educate people about your methods of
discovering this.

For instance, people are slowly getting used to CC stable when releasing
a fix for an annoying bug. It still takes a lot of efforts to get those
bugs automatically submitted, but after about 2 years, people start to
educate themselves. If you regularly prove them wrong when they claim
that a bug has no security impact, they will more often ask for a second
opinion, or try to a bit more descriptive in their commits.

But you cannot expect too much from the people who already do this on their
minuscule spare time, really.

The core issue

Posted Jun 17, 2008 22:08 UTC (Tue) by PaXTeam (guest, #24616) [Link] (7 responses)

> Well, I know that Linus does not like to give too much information in
> the commits because he believes it will help the bad guys, reason why
> he does not add the methods to reproduce the problems nor the CVE when
> he does the commits himself.

that's obviously utter crap. the bad guys are smarter than him or any kernel contributor.
they'll spot the bugs *before* they do. they'll also spot the bugs in the commits regardless
of what the commit says. does anyone remember the collective bruhaha in the security world
when CVE-2006-2451 became public? IIRC, that was a full year after the original commit and
also a full year after at least two working private exploits for it. on a sidenote, IIRC, that
bug still isn't fixed properly, as soon as a sysadmin enables the suid coredump feature, it's
exploitable again.

but actually i don't care about his opinion. what i do care about is that his published
commitment to full disclosure matches what he actually does and that's where the problem is.
you see, withholding security impact information doesn't full disclosure make. you guys can't
have it both ways because the people relying on you expect you to hold up to that commitment
you made in Documentation/SecurityBugs and if you violate that promise, people will make wrong
decisions and innocent people may suffer as a result. so if you want to stick to withholding
security impact info from commits, say so and the world will adjust. but let me guess, that'd
also be bad PR and you don't like that part.

> You have to keep in mind that most often, a commit is a summary of 10-20
> mail exchanges with reproducers, tests and results. You cannot put all
> that in a commit.

that's a strawman Willy, noone asked for it. what we did ask for was inclusion of known
security impact details. 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). once
again, this info doesn't help the bad guys because they'll spot this regardless of how obscure
the commit message is.

> What I'm really sicked about is the accusations of "general agreement to
> deliberately hide security informations from commits". That's false IMHO,
> really. And in fact, examples given by Brad were on public lists, so that
> does not make any sense.

when you publicly commit to full disclosure, yet, by your own admission now, you don't
actually practice it, then what do you call that? i call that general (silent or otherwise)
agreement of all participants. after all, participation in handling the kernel security bugs
is voluntary, noone forces you or anyone else to do it against his better judgement. therefore
if you play ball there, you de facto accept the not-exactly-full-disclosure policy (you later
admit that regarding vendor-sec, except everyone knows that vendor-sec does not practice
full-disclosure so people don't build that expectation into their decision making processes).
do you understand the problem better now?

> What we agree about is not to divulgate information when joining the list.

that's not the whole truth. what you also agree to is full disclosure after the embargo. go
read Documentation/SecurityBugs if you don't believe me. do you admit that you don't actually
practice it? if you do, we can take the discussion further and figure out whether you want to
actually update Documentation/SecurityBugs or really adopt full-disclosure. if you don't,
we'll keep on exposing the fallacy because we have no other way to affect you and at the same
time help the world by letting them know that their security risk analysis processes are based
on false promises.

> But I have never seen anything there such as "hey shhht! don't tell
> anybody, let's fix it silently".

i quoted Paul Mackerras a few times now. what do you have to say about that quote? why would
someone practicing full disclosure even *ask* that question and then actually withhold the
more important security impact?

> [stuff about the itanium hw bug]
> If a fix cannot be developped, game over!

not true. did the FDIV or F00F bugs mean game over? i don't think so. last time i checked, the
world hadn't stopped back then. what did happen was a huge PR disaster for Intel (in part
because of the same coverup attempt they're doing again). and history is repeating itself,
except this time you guys are actively party to the coverup. you should all be ashamed and the
conscientous of you should have left the list the moment Intel first had asked you to keep
silent because they didn't feel like fixing the chips. something tells me that there's another
PR disaster in the making.

> Believe it or not, it is already the hardest part of my work, determining
> the relevant information.

this is another strawman Willy, as this should not be your work at all and noone asked for it.
what we do ask for is that if you guys learn about security impact information during the
course of bug examination, then you *do* include those details in the commit. noone is
expecting anyone to spend time on thorough bug impact analysis, most of you are not even
qualified for that, it's really hard and time consuming work (just look at this very thread
and see how i missed stuff ;). but, say, if you see a kernel stack overflow then you say so
and don't try to be creative by calling it 'copying overly long strings' and similar crap. of
course there's always the alternative of publicly admitting that you do not in fact want to
practice full disclosure. it won't look cool in PR events but you can at least sleep with
clear conscience.

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

sorry, but i have no better words when i see something like
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-... .
do you really call that 'summary'? i hope not.

> Could you elaborate please ? This fix is in Linus tree, and I don't see
> Chris in the sign chain. Did he report it first ? Also, I'm sorry, but
> I fail to see the security implications of this patch, eventhough seeing
> "ptrace_attach" catches my attention.

don't you think there's a reason you fail to see the security impact and that i cited this
particular commit? go ask Chris about the history of it, you'll be surprised. in short, this
*is* a local DoS, the kernel devs were provided proof-of-concept code *yet* Linus deliberately
did not include any of that information. then Chris deliberately omitted it from the -stable
commit as well. wild accusations? or the unbelievable truth? it's yours to find out and you
even know how.

> From what I have seen, this was finally judged as a non-issue since other
> checks are in place, which probably explains why you don't have it in
> stable. It is very often that fixes for supposedly real vulnerabilities
> finally end in mostly code cleanups.

it would have been nice to mention this in the commit as well.

> What amazes me, to be honnest, is the ability you have to spot patches in
> mainline that take a lot of time to other people. I'd love to know how
> you proceed, it would save me a lot of time.

uhm, there's nothing magical in this. i sometimes check the kernel shortlog looking for
potential conflicts with PaX and obviously my eyes catch sometimes other 'interesting' looking
commits which i then go and look at in detail.

> Or maybe you spend whole days at this, in which case all users would
> benefit from your findings.

not at all, as i said somewhere below, i do it on my free time, always have in fact. and these
days, i'm trying to actually spend my time on other things. but as long as i can't give PaX
away to a new crew, i'll have to have a look every now and then.

> Why don't you post on LKML, to -stable or even on security lists links
> to the patches you consider suspicious security-wise ?

what would that change? more flames, more excuses for why it's not a good idea to support the
bad guys, etc. and in the end, as i said above, that's not what i care about but rather the
consistency between the promise made to the public and the actual actions. i can't fix any of
that because it's not of my making.

> Even assuming everyone's honnest in the chain, and the other people
> considered the bug inoffensive when you think the contrary, you could
> educate people about your methods of discovering this.

that's a whole separate issue of figuring out that a bug has a security impact after the
commit. i'm afraid such research requires a full staff, and i'm not in the position to fund
anything like that. heck, i'm happy when i make ends meet here ;).

Kernel bug 9416

Posted Jun 18, 2008 2:28 UTC (Wed) by vonbrand (guest, #4458) [Link] (4 responses)

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!

Kernel bug 9416

Posted Jun 18, 2008 3:28 UTC (Wed) by spender (guest, #23067) [Link] (2 responses)

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

Posted Jun 18, 2008 4:20 UTC (Wed) by vonbrand (guest, #4458) [Link] (1 responses)

"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

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

> 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

Posted Jun 18, 2008 12:10 UTC (Wed) by PaXTeam (guest, #24616) [Link]

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

The core issue

Posted Jun 18, 2008 21:53 UTC (Wed) by wtarreau (subscriber, #51152) [Link] (1 responses)

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

The core issue

Posted Jun 19, 2008 0:47 UTC (Thu) by PaXTeam (guest, #24616) [Link]

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

The core issue

Posted Jun 17, 2008 11:50 UTC (Tue) by bojan (subscriber, #14302) [Link] (2 responses)

> If we want to be picky, everything which can permit a non-privileged user to cause a
malfunction resulting in a degradation of performance, integrity, availability,
confidentiality or traceability is a security issue.

Kernel is done for a wide audience and, as you mentioned, different people would like to know
about different types and severity of security problems. So, the best policy is just to
describe them all and let people (including distributors) decide if they want to bump up or
not.

In other words, if things are logged in such a way that even the pickiest of them are OK with
it, then the ones that are less picky will be OK too. Provided the information about the
security impact is known, of course.

It's done exactly in this way... in a sense

Posted Jun 17, 2008 17:08 UTC (Tue) by khim (subscriber, #9252) [Link] (1 responses)

So, the best policy is just to describe them all and let people (including distributors) decide if they want to bump up or not.

Better for whom exactly? There are exist one potential group which will be VERY negatively affected: top-level kernel developers (and to lesser extent all other kernel developers). For them detailed list of security implications in descriptions is unneeded noise, not something important. They look and review THOUSANDS of such descriptions each and every week so OF COURSE they want to reduce this noise. If issue looks severe enough - they keep it in description.

In other words, if things are logged in such a way that even the pickiest of them are OK with it, then the ones that are less picky will be OK too.

And the pickiest users are of course kernel developers - they want to avoid clutter in various typed of reports and so demand short and concise descriptions. So they remove unimportant (for them) parts. Including detailed descriptions of possible security implications. In all cases except the most severe ones. So in fact they did what you asked them to do - but somehow you are not satisfied.

Now if you think they go overboard in some cases - you can join the system and help to prevent this. If you want totally different style of commit messages (extensive with lots and lots of details) in general - you are free to fork the project and put any kind of descriptions you want.

It's done exactly in this way... in a sense

Posted Jun 17, 2008 21:54 UTC (Tue) by bojan (subscriber, #14302) [Link]

> Better for whom exactly?

For people trying to keep their systems secure?

Security issues are not noise, especially when people producing patches for them are already
aware of their nature.

> So they remove unimportant (for them) parts.

Yeah, that's kinda the problem. Even the most trivial of security issues may be important to
someone. Removing information about it puts users that may be affected at a disadvantage.

> If you want totally different style of commit messages (extensive with lots and lots of
details) in general - you are free to fork the project and put any kind of descriptions you
want.

So, mentioning in the release notes of .7 that some security issues have been addressed, which
would take less than 100 words, requires a kernel fork? I don't understand where all this
hostility is coming from.

If issues are known, release notes should specify that. It's that simple.

The core issue

Posted Jun 18, 2008 1:07 UTC (Wed) by vonbrand (guest, #4458) [Link]

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.

"Stable" kernel 2.6.25.7 released

Posted Jun 17, 2008 10:07 UTC (Tue) by PaXTeam (guest, #24616) [Link] (3 responses)

> Then he can post privately to the -stable team.

in case you didn't read http://lwn.net/Articles/285438/ , the problem is not with -stable per
se, it's just one of the causalties of the policies played on the kernel security mailing list
(although it's probably not a coincidence  as there's overlap between the members). it should
also be clear by now that we are NOT going to play ball with that list. i even told you so in
the past already (remember the random driver stack overflow bug?). the reason is very simple
and sad at the same time: this list has become the primary place to discuss then hide security
information about bugs. in case it's not clear, the problem is not with the 'discuss' part but
the 'hide' one.

> But I think that unfortunately, Brad is not trying to improve Linux but
> to demonstrate it's a pile of crap, maybe in order to promote security
> add-ons such as grsecurity.

how is exposing the dishonesty of certain kernel developers not improving linux? do you want
people to live without knowing what bugs have security related consequences? if said
developers are unwilling to practice full disclosure (despite public reassurances, mind you)
then someone else has to. and how on earth is this supposed to promote grsecurity (or any
other access control system)? if anything, they all suffer collateral damage from this policy
of not-exactly-full-disclosure.

> But it's doing no service to him either because acting this way will
> scare away people who look for a reliable system.

i did that more than 3 years ago already:
http://forums.grsecurity.net/viewtopic.php?p=3805#p3805 and i still stand by what i said back
then. in fact, the situation has become a whole lot worse since.

> IMHO, he would be of great help if he would accept to be on the -stable reviewers list.

it's too late by then, the problems start with the kernel security list, -stable feeds on
that. and no amount of private lists will help the accountability problem you're having now.
the way of solving that is to make the archives public after a certain period (there's nothing
to hide after the bug is fixed and public, right?) then we can talk about having improved
linux security.

"Stable" kernel 2.6.25.7 released

Posted Jun 17, 2008 19:24 UTC (Tue) by wtarreau (subscriber, #51152) [Link] (2 responses)

stable@ is not a list, just an address to post things you think should
be fixed in stable releases. There is no secrecy there, you can simply
CC LKML if you want (and preferably the patch reporter first in order
to get information about relevance). I sometimes proceed like this.

I have no problem with your policy about not posting to private lists.
Davem does the same, and I respect this. Then you'd better check the
oss-security list : http://oss-security.openwall.org/wiki/

It is public, talks about security issues in opensource software
(including linux), and many of the closed lists members are there.

"Stable" kernel 2.6.25.7 released

Posted Jun 17, 2008 20:35 UTC (Tue) by PaXTeam (guest, #24616) [Link]

> stable@ is not a list, just an address to post things you think should
> be fixed in stable releases.

yes, i figured it out in the meantime. problem with it still is that anything that makes it
there is already *too late* because it must have been entered the Linus tree already
(mandatory condition for a submission to be accepted). and if the commit is misleading there,
it's game over for everyone else. in any case, you can certainly CC me on anything you need my
input on *but* consider that my work has nothing to do with neither the kernel nor security
and, as of this year, i'm spending less and less of my free time on this as well, with the
eventual goal of completely stopping it. in other words, don't expect me to spend a lot of
time on this, my quota for linux/security is already pretty much exhausted.

"Stable" kernel 2.6.25.7 released

Posted Jun 17, 2008 21:21 UTC (Tue) by spender (guest, #23067) [Link]

Though it won't solve many of the problems mentioned, particularly:
1) Bugs that originate in private through the numerous private mailing lists
2) Obvious and explicit security information mentioned in attached bugzilla entries getting
omitted from changelogs
3) root-based bugs not only being downplayed, but specifically labeled as not security
relevant (defeats the purpose of SELinux, SMACK, capabilities)

It may help in raising more awareness regarding the invalid userland dereference class of
bugs, which seem to most often get ignored.  (Microsoft hopefully is paying similar attention:
http://www.immunitysec.com/downloads/DriverImpersonationA...)

With that said, you're of course welcome to CC me on relevant mails as well.

-Brad

"Stable" kernel 2.6.25.7 released

Posted Jun 17, 2008 12:31 UTC (Tue) by hmh (subscriber, #3838) [Link]

I suggested this very thing in the comments for 2.6.25.6, and guess what :-) I was told to
"reread the thread because I had missed the point".  Heh.

The point, apparently, is that those who could help lessen the damage of security fixes going
unnoticed are NOT interested on doing it (because of various reasons) for -stable.  I won't
judge their reasons for this, but that's what it boils down to.   And that's really
unfortunate, because while it would not be the full round-trip to the moon, it would still be
a damn nice first step.

"Stable" kernel 2.6.25.7 released

Posted Jun 17, 2008 6:58 UTC (Tue) by Los__D (guest, #15263) [Link] (13 responses)

And how is a comment starting with In this issue of "we have no clue what we're doing," NOT auto-labeling itself as a troll comment?

"Stable" kernel 2.6.25.7 released

Posted Jun 17, 2008 10:14 UTC (Tue) by PaXTeam (guest, #24616) [Link] (12 responses)

you might want to read and understand this before labeling someone as a troll. in particular, the problems we're exposing are neither irrelevant nor off-topic nor are they meant to incite emotional responses but rather a rational discussion of the problem. but the first step towards that is to actually admit that there's a problem which is where the kernel devs are stuck at the moment.

"Stable" kernel 2.6.25.7 released

Posted Jun 17, 2008 10:26 UTC (Tue) by Los__D (guest, #15263) [Link] (11 responses)

Starting discussions with people by labeling them as clueless as the first sentence, is doing
a pretty terrible job about not inciting emotional responses.

"Stable" kernel 2.6.25.7 released

Posted Jun 17, 2008 10:52 UTC (Tue) by PaXTeam (guest, #24616) [Link] (10 responses)

it wasn't a start but the continuation of http://lwn.net/Articles/285438/ . second, it's not a
discussion apparently, but just talking to ourselves and maybe telling the world to look at
certain problems, the discussion itself is apparently to be had on lkml with the kernel devs,
not us. finally, maybe you wanted to say 'flame' instead of 'trolling'? there's a big
difference and lkml is full of the former yet life continues, problems get solved. why can't
this one be?

"Stable" kernel 2.6.25.7 released

Posted Jun 17, 2008 11:27 UTC (Tue) by Los__D (guest, #15263) [Link] (9 responses)

<p><i>it wasn't a start but the continuation of http://lwn.net/Articles/285438/ </i><br/>
Another post started in exactly the same mocking way, and not intended FOR the developers, but
for spewing gall at them, on a semi-random news site.

Please note that I don't disagree at with the technical parts, just the serving.

"Stable" kernel 2.6.25.7 released

Posted Jun 17, 2008 13:53 UTC (Tue) by nix (subscriber, #2304) [Link] (8 responses)

Likewise. Obviously it would be nice if more things that were security holes got so labelled,
but short of educating everyone who commits anything to think in a suitably paranoid manner (a
nice long-term goal but ridiculous in the short term), I can't see any way in which this
problem could be instantly fixed, except if the people who *could* determine that particular
fixes fix security problems were to help with that.

But at least one of them (sorry Brad, mixed you up, it may be that only PaXTeam is alleging
some sort of widespread dishonesty conspiracy theory and you're merely alleging insufficient
paranoia, which I'd agree with) would apparently rather moan than help fix the problem.

"Stable" kernel 2.6.25.7 released

Posted Jun 17, 2008 14:25 UTC (Tue) by PaXTeam (guest, #24616) [Link] (7 responses)

1. none of us talked about 'conspiracy', you did. you keep coming up with this strawman and
i'll keep exposing it. but keep trying ;).

2. as you were told about a dozen times already, the problem isn't with not recognizing a bug
for its security impact (or rather, that's a separate problem), but the intentional omission
of such information when it is already known. you have yet to explain the ptrace self-attach
commit, why don't you say something about that?

3. we can't help fix the problem because the problem isn't with us but rather those kernel
developers who decided (but failed to inform the public about) that full-disclosure is a PR
act only, in reality they don't practice it. the consequence of this double-play is that
people who trust them on their word will make false security evaluations when looking at the
commits (and no, they have nothing else to judge because these bugs are discussed on private
lists).

"Stable" kernel 2.6.25.7 released

Posted Jun 17, 2008 15:07 UTC (Tue) by nix (subscriber, #2304) [Link] (6 responses)

Did you not read what I wrote at all? You're insisting that your assertions of coordinated
identical intentional malpractice on the part of many dozens of unrelated people does not
constitute a conspiracy theory... but coordinated identical intentional malpractice is the
very *definition* of conspiracy.

i.e. you're now arguing with the dictionary, not with me.

"Stable" kernel 2.6.25.7 released

Posted Jun 17, 2008 15:24 UTC (Tue) by PaXTeam (guest, #24616) [Link] (3 responses)

i read what you wrote but i think we're having a definition crisis of some sort ;). how do you
define 'coordination'? somewhere above i told you it doesn't take much in a close-knit circle
of people who belong to the same social group anyway. if you mean written edicts issued in
secret or something like that, then it's definitely not that. if you mean the 'see what Linus
does, do as Linus does' kind of 'coordination', then you may call it that but it doesn't make
it so. ever heard of unspoken/unwritten rules that people understand and abide by? doesn't
make them all conspirative, does it? nevertheless, it can still be bad practice and in this
case, it is.

but in the end, you know what, whatever word makes you happy. can you now make the next step
and actually do something about checking the facts out for yourself?

"Stable" kernel 2.6.25.7 released

Posted Jun 17, 2008 15:42 UTC (Tue) by nix (subscriber, #2304) [Link] (2 responses)

I can't do that because the facts are largely on private lists I don't have access to. (That's
why I trusted that the facts were as you stated.)

"Stable" kernel 2.6.25.7 released

Posted Jun 17, 2008 15:47 UTC (Tue) by PaXTeam (guest, #24616) [Link] (1 responses)

> I can't do that because the facts are largely on private lists I don't
> have access to.

and what prevents you from asking for them? are you not curious? don't you think that it may
be a good idea to make them public? or just afraid of finding your beliefs shattered a bit?

"Stable" kernel 2.6.25.7 released

Posted Jun 17, 2008 18:09 UTC (Tue) by nix (subscriber, #2304) [Link]

Mostly I'm not interested enough to bother people over it (and I have other things to do). If
the holes get fixed, it's good enough for me personally...

"Stable" kernel 2.6.25.7 released

Posted Jun 17, 2008 20:53 UTC (Tue) by ncm (guest, #165) [Link] (1 responses)

Sorry, nix, the "definition of conspiracy" involves lawbreaking.  I see no evidence of crimes
here, and no accusations of crimes, hence no conspiracy and no accusation of conspiracy.  

What we do appear to have is a belief in security-by-obscurity, abetted by preference for
convenience and tidiness, and by publicity-shyness, finally coupled with disrespect for
SELinux.  None are crimes, but the combined effect on security is no less fortunate.

"Stable" kernel 2.6.25.7 released

Posted Jun 17, 2008 22:36 UTC (Tue) by nix (subscriber, #2304) [Link]

There's a dictionary definition and a legal definition, and they're 
different. The dictionary definition doesn't mention lawbreaking (at least 
not in my dictionary).

(And no, nobody's alleged crimes, although some of the allegations might 
be read to allege criminal *intent*.)

"Stable" kernel 2.6.25.7 released

Posted Jun 17, 2008 10:18 UTC (Tue) by mb (subscriber, #50428) [Link] (3 responses)

> In this issue of "we have no clue what we're doing," we have:

So can you please join the -stable review list to improve this situation? Or are you just out
for blood and don't really want to _improve_ the situation?
I'd be happy, if you'd review my patches and point out (security) errors in the patch or
patch-description, that I didn't think of.

"Stable" kernel 2.6.25.7 released

Posted Jun 17, 2008 11:12 UTC (Tue) by PaXTeam (guest, #24616) [Link] (2 responses)

> So can you please join the -stable review list

can you point us to the archives of this mailing list?

"Stable" kernel 2.6.25.7 released

Posted Jun 17, 2008 11:24 UTC (Tue) by mb (subscriber, #50428) [Link]

> can you point us to the archives of this mailing list?

Well, it's not a mailing list AFAIK. It's a list of CCs that the -stable patches are sent to
for review. Just ask greg, if you want to be added.

"Stable" kernel 2.6.25.7 released

Posted Jun 17, 2008 18:16 UTC (Tue) by wtarreau (subscriber, #51152) [Link]

> > So can you please join the -stable review list
> can you point us to the archives of this mailing list?

It's not a mailing list, it's just a list of people who automatically
receive the patches planned for next stable release when they are sent
to LKML. I asked myself to be subscribed because it was hard to spot
those in the huge LKML noise. It helps me track fixes which I may have
to backport to 2.4, and maybe one day I'll be able to contribute back
by spotting bugs before they get merged.

All you get is 100% public, it's just a convenience to avoid polling
LKML. If you or Brad have things to add to the patch descriptions,
it might be a good idea.

"Stable" kernel 2.6.25.7 released

Posted Jun 17, 2008 11:22 UTC (Tue) by NAR (subscriber, #1313) [Link] (46 responses)

According to Napoleon, never ascribe to malice, that which can be explained by incompetence.
How do you know, it's malice and not incompetence? Some of the comments imply malice.

Of course, incomptence is not that reassuring either, but for example Al Viro's comit seems to
be two months older than the DoS bug report so I don't see how could he knowingly omit the
security information from the bug report...

"Stable" kernel 2.6.25.7 released

Posted Jun 17, 2008 12:00 UTC (Tue) by spender (guest, #23067) [Link] (44 responses)

First, a correction to my original post.  The fix for the TPM bug on vendorsec came from
Michael Halcrow, not Serge Hallyn.

I should have linked to the proper URL, which is:
http://git.kernel.org/?p=linux/kernel/git/stable/linux-2....

Here we see Greg committed it into -stable, and Al Viro and Chris Wright both signed off on
it.  Unless Greg or any of the other people signing off on the commit didn't read any of the
link which was pasted (which I find very hard to believe) the information about it being a
local DoS was intentionally suppressed.

If you don't bother to spend the time to go and read the links to everything the PaX team and
I have posted, then it would be easy to assume that this is just some huge series of
incompetence (which extends back far beyond these last two releases where I started to
actually point things out).  If you go and actually read the references though, I think you'd
have to be pretty naive and distort the evidence in every case to come to a conclusion of mere
incompetence.

Like I mentioned before though, the public doesn't have all of the information at hand since
so much goes on behind the scenes in private mailing lists with no accountability.  I alluded
to a few of the instances earlier if you actually read all my previous posts, but I'm
compiling the full details of this information and will be submitting it to LKML and other
mailing lists, since it's too good to waste here.  It should clear up any lingering doubts.

-Brad

"Stable" kernel 2.6.25.7 released

Posted Jun 17, 2008 12:31 UTC (Tue) by NAR (subscriber, #1313) [Link] (43 responses)

Well, I haven't noticed the DoS in the bug report for the first look, I had to do a search in
the browser.

I think there are very very few security consious developers like yourself. Most of them won't
notice that a "double free" is a security bug. Most of them start to read the bugzilla entry
from the "Description" part and would miss the summary.

Given the speed of kernel development, the amount of changes and the lack of common bug
database (and it's integration with the version control system), I still think it's
incompetence, not malice. I haven't examined all of the links in details, but haven't read a
"it's a security fault, let's hide it" comment which would prove malice.

Not that's it all that reassuring.

"Stable" kernel 2.6.25.7 released

Posted Jun 17, 2008 13:11 UTC (Tue) by PaXTeam (guest, #24616) [Link] (42 responses)

> I haven't examined all of the links in details, but haven't read a
> "it's a security fault, let's hide it" comment which would prove malice.

well, you really should check them out, but here's a choice quote from Paul Mackerras posted
to the security list a while ago:

  I'd appreciate advice about the best way forward here, and to what
  degree we should be candid about the reason for the patch in the
  commit message when it gets committed to Linus' git repository.

how 'candid' it became you can check in that thread and the posted links (hint: no mention of
the more serious security impact).

"Stable" kernel 2.6.25.7 released

Posted Jun 17, 2008 15:10 UTC (Tue) by nix (subscriber, #2304) [Link] (36 responses)

I imagine this is because the bad guys must be assumed to read the commit logs too, before
releases are made, and it's intentionally hard to edit commit logs immediately before
releasing, especially if it's a big tree (i.e., a new major release, not -stable): it would
likely mean a massive rebase.

"Stable" kernel 2.6.25.7 released

Posted Jun 17, 2008 15:43 UTC (Tue) by PaXTeam (guest, #24616) [Link] (35 responses)

> I imagine this is because the bad guys must be assumed to read the
> commit logs too, before releases are made,

this mentality is called security by obscurity. congratulations for having made the basic
mistake in computer security ;-).

more seriously, you're saying that the bad guys in desperation read commit logs and use the
little time between that and the actual release/widespread adoption to exploit the holes (that
takes some skill in case of kernel bugs), because the same (skilled) bad guys are unable to
find exploitable bugs themselves? do you have the *slightest* evidence to support this view
(yeah i was paraphrasing, hope you got the point and won't get sidetracked in my choice of
words)?

second, what about the good guys who need to know the same information (think IDS/IPS vendors
for one, then the many trees tracking that of Linus and trying to keep their side secure)? oh
yeah, the two sides of the coin. the problem is that you, the ultimate end user and most
affected person didn't get to flip it. maybe you personally don't want to, but there're many
others who do.

third, about this particular commit: why does it make sense to mention the DoS at all then?
don't you think it draws attention from the bad guys who can sniff an exploitable bug where
others smell a DoS only? wouldn't it have been better (from your point of view, that is) to
simply not mention anything at all? i think your imagination needs a little more consistency.

last but not least, now that you're done using your imagination, will you actually try to do
something to figure out what's really going on? you know, talking here won't get you far, your
answers are in the mailing list archives.

Congratulations are in order!

Posted Jun 17, 2008 17:37 UTC (Tue) by khim (subscriber, #9252) [Link] (28 responses)

this mentality is called security by obscurity. congratulations for having made the basic mistake in computer security ;-).

This one comment explains it all: you DON'T care about security. What you DO care about is your reputation. You will happily increase risk for users as long as everything is done by your rules.

Why? Oh, it's simple: anyone who claims that security by obscurity never works is a troll. Actual rule is "You can fool all the people some of the time, and some of the people all the time, but you cannot fool all the people all the time". Case to the point: PSP had easily exploitable backdoor in firmware from the day one - and still has it today. Yet crackers needed two years to find and exploit it. Why? Because of the obscurity. And you can be pretty sure A LOT OF guys wanted to this: hardware solitions were offered, rare disks (needed to use previously known cracks) were sold for $100 or more, etc. BIG BUSINESS. BIG MONEY. Yet no crack for TWO YEARS. THAT is the power of "security by obscurity". It DOES work. Forever? Of course not! But for a long time.

If you don't accept thios simple fact that there are nothing to discuss further - you have different set of axioms then kernel developers do.

about this particular commit: why does it make sense to mention the DoS at all then? don't you think it draws attention from the bad guys who can sniff an exploitable bug where others smell a DoS only? wouldn't it have been better (from your point of view, that is) to simply not mention anything at all?

Bingo! This particular commit is bad NOT because it does not mention all security implications, but because it talks about DoS at all. Poor phrasing, but not the end of the world.

Congratulations are in order!

Posted Jun 17, 2008 18:58 UTC (Tue) by zakalwe2 (guest, #50472) [Link] (27 responses)

What you've just said is that experts who spent their time reverse engineering a binary
firmware failed to find an easily exploitable method, but instead found a method that enabled
them to make money.  That is human nature.  What guarantees do I have that some linux
contributers don't deliberately introduce or obscure exploitable bugs so that they can profit
from them in some way?  The vast majority of other people who understand and find them are
likely to keep them to themselves, or sell them on.

If there is no accountability or transparency in how these serious flaws are dealt with,  no
incentives to disclose or not put them there in the first place, bad things will almost
certainly happen.  It's inevitable.  These corruptions happen in every other field, it's naive
to think they won't happen here.

Everything that is even remotely a "security" threat should be labeled as such.  If this makes
linux look bad when some smart researcher compares all the major OS' security by counting
publicly known flaws, so be it.  That is the incentive to not put them there in the first
place.  Hiding them is, at best, leading to a culture of complacency, and at worst an
indication of malice.

I salute spender and the PaX team for bringing these issues to the fore.  They have made a
considerable impact in the field of security,  when they speak it is worth listening.

Not so fast

Posted Jun 17, 2008 22:04 UTC (Tue) by man_ls (guest, #15091) [Link] (26 responses)

But wait, you have to realize the consequences of the way advocated by spender and PaXTeam: let us follow the path suggested by nix below. First find a bug, and search for a related vulnerability; then publish it along with an exploit so people take you seriously, and obtain a CVE identifier. That is the moment to send a patch to a public list pointing to the CVE so people can make informed decisions.

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?

You may think that Linus et al are burying their heads in the sand, but try to picture yourself in their shoes; there is little else they can do but try to raise the bar, however little they can, for exploitation. Occasionally a really serious issue arises with obviously dangerous implications. Such rare events can be disclosed and publicized so hopefully everyone will patch their kernel before an exploit is published, but it cannot be done for every bug with potential security implications (i.e. a hundred times a month). Kernel users would stop paying attention quickly if every esoteric bug was magnified by the maintainers.

Not so fast

Posted Jun 17, 2008 22:38 UTC (Tue) by PaXTeam (guest, #24616) [Link] (24 responses)

besides a few strawmen, you missed the entire point of what we were saying. it's not about
what disclosure policy is best for the kernel. i don't care, really. what i do care about is
that what the kernel devs commit to in Documentation/SecurityBugs (as of now, full
disclosure), they stick to it. and i explained many times now the reason for that: people
assessing security risks need to know whether the kernel commits are a reliable source of
information of that or not. because if they aren't then these people will know they'll have to
assign resources to that. as simple as that, it's called risk management.

Not so fast

Posted Jun 17, 2008 23:28 UTC (Tue) by man_ls (guest, #15091) [Link] (12 responses)

besides a few strawmen [...]

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

The policy for security bugs you cite is specifically for people who contact the security team. If a specific bug doesn't reach them I don't see why that policy should apply at all. 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; or maybe it was due to incompetence. Anyway for these bugs kernel devs are free to apply whatever disclosure policy they see fit (i.e. not bound by any document), and we are free to discuss if they do it sensibly, whether you care about it or not.

people assessing security risks need to know whether the kernel commits are a reliable source of information of that or not.

People assessing security risks should make their own assessments. They should not trust commit messages, and I don't see how you can suggest that they might even think about it.

Not so fast

Posted Jun 18, 2008 0:41 UTC (Wed) by PaXTeam (guest, #24616) [Link] (11 responses)

> "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?

Not so fast

Posted Jun 18, 2008 6:57 UTC (Wed) by man_ls (guest, #15091) [Link] (10 responses)

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.

Not so fast

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

> 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 (guest, #15091) [Link] (8 responses)

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 (guest, #23067) [Link] (4 responses)

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] (3 responses)

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 (guest, #23067) [Link] (2 responses)

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 (guest, #15091) [Link] (1 responses)

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 (guest, #24616) [Link] (2 responses)

> 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 (guest, #15091) [Link] (1 responses)

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 (guest, #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.

Not so fast

Posted Jun 17, 2008 23:32 UTC (Tue) by drag (guest, #31333) [Link] (10 responses)

Always with the strawmen. Strawmen here, strawmen there. What is this?

Lets learn pointless internet debate techniques 101?

"If you call something a strawman, then you don't have to respond to it in a meaningful way.
If you don't have to respond to it in a meaningful way then they can't reply to you about it.
If they can't respond, then you get the last word.. that means you win!!"

"See also: Avoiding the dreaded 'tldr' that spells ultimate failure for any argument. Did he
not reply because your intellect humiliated him? Or was it because he got to bored and decided
to get drunk with his friends instead? Use the 'strawman' reply to keep replies down to a
minimum and allow you to skillfully divert the argument to something you can easily be right
about."

Hint:

When knocking down strawmen, it takes a bit more effort then just to say 'that's a strawman!'
and ignore it. In fact saying 'strawmen' is like crying wolf and is a very weak technique. I
can't even make heads or tails of what you exactly mean or what parts of the OP's comments you
find irrelevant.

=====================

I mean, seriously.

The problems are:

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.

followed by:

If you sound like a arrogant dick on a public forum people will classify you as a arrogant
dick no matter how right you are. Rightfully so. (not so much, you, PaX as other people)

Being forceful with facts and well considered opinions is not the same thing as being
insulting, even if people take it the wrong way. Being insulting is always insulting and it
may get people's attention once or twice, but after that they'll just ignore you out of spite.

This is the reality of the situations and a balance or solution must be found. There is no
absolute, no perfect way to approach this problem and the best solution _will_ be different on
many occasions.

followed by:

Arguing the same things over and over again is pointless. Do not cast pearls before swine.
Your time, your effort, is much more precious then to waste on some pointless internet fart
fest.

That's all.

Not so fast

Posted Jun 18, 2008 0:58 UTC (Wed) by PaXTeam (guest, #24616) [Link] (9 responses)

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

Posted Jun 18, 2008 12:49 UTC (Wed) by nix (subscriber, #2304) [Link] (8 responses)

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

Not so fast

Posted Jun 18, 2008 13:06 UTC (Wed) by PaXTeam (guest, #24616) [Link]

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

Not so fast

Posted Jun 18, 2008 13:44 UTC (Wed) by spender (guest, #23067) [Link] (6 responses)

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

Not so fast

Posted Jun 18, 2008 16:52 UTC (Wed) by nix (subscriber, #2304) [Link] (5 responses)

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

Not so fast

Posted Jun 18, 2008 17:59 UTC (Wed) by PaXTeam (guest, #24616) [Link] (4 responses)

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

Not so fast

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

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

Posted Jun 19, 2008 10:31 UTC (Thu) by PaXTeam (guest, #24616) [Link] (2 responses)

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

Not so fast

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

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

Posted Jun 20, 2008 1:37 UTC (Fri) by zakalwe2 (guest, #50472) [Link]

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

Posted Jun 17, 2008 22:57 UTC (Tue) by zakalwe2 (guest, #50472) [Link]

Writing an exploit for every potentially exploitable bug could end up taking more work than
developing the kernel for a start.  I don't think anybody sane is suggesting that.  If the
number of security bugs is so high that the kernel developers can not possibly keep up with
labeling them as such, then we have a more obvious problem than disclosure.  The entire
development model must then come into question if that is the case.

If there are so many public security bugs, how many more must go unnoticed?  Bugs that may
never trigger under any normal use?  Like the PaX team suggested, it's hard to imagine people
even need to resort to disclosure lists.

I think the only people raising the bar for exploitation are Spender and the PaX team, yet
their work has been completely dismissed for inclusion in the mainline kernel on the basis
that Linus doesn't like the segmentation logic of PaX.

"Stable" kernel 2.6.25.7 released

Posted Jun 17, 2008 18:11 UTC (Tue) by nix (subscriber, #2304) [Link] (5 responses)

The 'little time' you refer to can be anything from months to years. Not everyone keeps their
kernels bang-up-to-date, and fixes to things which might be security holes in mainline are not
always instantly propagated to -stable. Thus a window exists, and given the existence of
rapidly-propagating worms it is unwise to make that window wider than necessary.

(This is of course the entire justification for the existence of private lists like vendor-sec
and the BIND security list in the first place. You might not like it but it *is* defensible. I
don't much like it either, not being on any of those private lists, but nonetheless I can't
really argue against it.)

"Stable" kernel 2.6.25.7 released

Posted Jun 17, 2008 22:26 UTC (Tue) by PaXTeam (guest, #24616) [Link] (4 responses)

it does *not* matter what that 'little time' is. that's because your *whole* argument is based
on a false assumption, namely that it's the kernel devs (or whoever reports a bug to them) who
are the *first* to find a given security bug. it's obvious that there's exactly one such
person in the world who can make that claim, and based on what resources kernel devs spend on
finding security bugs vs. the rest of the world does, it's easy to see that this one lucky guy
isn't one of the kernel devs. it then follows that you can't in general assume that the
security bugs found by kernel devs aren't already being exploited in the wild. it then also
follows that this 'hide the bugs from the bad guys' doesn't actually do that, but it does hide
them from honest but less knowledgable people who nevertheless still need to know about them
to be able to properly assess the risks of a given bug *themselves* (and what the kernel devs
think they can do better themselves - good luck proving that, if anything, they so far proved
the exact opposite).

"Stable" kernel 2.6.25.7 released

Posted Jun 17, 2008 22:44 UTC (Tue) by nix (subscriber, #2304) [Link] (3 responses)

It likely isn't always one of the kernel devs, but I fail to see how you 
can make claims regarding relative probabilities without data (and I can't 
figure out how to get useful data without being a major black hat whom a 
lot of other black hats talk to).

(You really do talk a lot about straw men for someone who produces so 
many.)

"Stable" kernel 2.6.25.7 released

Posted Jun 17, 2008 22:57 UTC (Tue) by PaXTeam (guest, #24616) [Link] (2 responses)

> It likely isn't always one of the kernel devs, but I fail to see how you 
> can make claims regarding relative probabilities without data 

because in my carrier i have seen part of what we now call the security industry and i know
for a fact that the kernel devs can't match their resources.

> (and I can't figure out how to get useful data without being a major
> black hat whom a lot of other black hats talk to).

see, one way i can tell a security professional from the armchair one is that the latter's
world consist of simple black and white whereas the former knows it's way more complex. so
however disappointing it will sound to you, no, you don't need to be a 'major black hat'
(whatever that means anyway) to know the capabilities acquired by the security industry.

> (You really do talk a lot about straw men for someone who produces so 
many.)

i see you feel very stronly when yours are being exposed one by one (notice how you never even
contested any of them or chose to chicken out, and btw, i thought you were done with this
thread ;), so you're welcome to expose every single one of mine ;).

"Stable" kernel 2.6.25.7 released

Posted Jun 18, 2008 12:52 UTC (Wed) by nix (subscriber, #2304) [Link] (1 responses)

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

"Stable" kernel 2.6.25.7 released

Posted Jun 18, 2008 13:20 UTC (Wed) by PaXTeam (guest, #24616) [Link]

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.

"Stable" kernel 2.6.25.7 released

Posted Jun 18, 2008 13:52 UTC (Wed) by NAR (subscriber, #1313) [Link] (4 responses)

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

"Stable" kernel 2.6.25.7 released

Posted Jun 18, 2008 14:13 UTC (Wed) by PaXTeam (guest, #24616) [Link] (3 responses)

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

Posted Jun 18, 2008 16:55 UTC (Wed) by nix (subscriber, #2304) [Link] (2 responses)

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

"Stable" kernel 2.6.25.7 released

Posted Jun 18, 2008 17:47 UTC (Wed) by PaXTeam (guest, #24616) [Link] (1 responses)

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

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

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

"Stable" kernel 2.6.25.7 released

Posted Jun 17, 2008 12:43 UTC (Tue) by PaXTeam (guest, #24616) [Link]

a double-free is a well known bug class, known to be exploitable in several heap
implementations. there're also other well known heap related bugs that are exploitable, linux
being no exception to that (check http://www.phrack.com/issues.html?issue=64&id=6). in other
words, in these cases you don't need to trigger the bug in order to tell it poses a security
risk. whether that's some 'harmless oops' or a kernel crash (DoS) or something more serious
can be determined later, but the important point is to *mention* the very fact in the commit
so that more competent people can pick it out and do more analysis if needed. of course these
same competent people have already learned to read between the lines and will pick such
commits out, but the general public and the less security-aware developers/distro
maintainers/etc will be left in the dust - that doesn't help improve linux security.

and you can say a lot of things about Al Viro, but incompetence isn't it, he knows full well
what kind of memory corruption bugs are potential security issues.

"Stable" kernel 2.6.25.7 released

Posted Jun 17, 2008 12:35 UTC (Tue) by tialaramex (subscriber, #21167) [Link] (2 responses)

Meanwhile we have:
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-...
waiting to be fixed in -stable, which is trivially exploitable.


That's an exploit I'd like to see. So far as I can tell this bug occurs during hardware init,
which for a conventional PCI setup will occur during boot or coldplug. If your hardware is
affected, you should see the kernel try to dereference the NULL pointer at that point,
otherwise, not at all.

Looking at a few examples, this PCI device doesn't seem to come in a hotplug form factor, so a
hotplug exploit will require that you manufacture hardware for the purpose. Few people would
call that "trivial"

Attacking thus during kernel boot is an "airtight hatchway" trick, it gets you privileges to
do something you could already do, and thus isn't a security impact. Coldboot is little
better, you're in userspace, but you're root and even in quite locked down scenarios the root
processes doing coldboot are unrestricted so it's back to the "airtight hatchway".

"Stable" kernel 2.6.25.7 released

Posted Jun 17, 2008 13:56 UTC (Tue) by cladisch (✭ supporter ✭, #50193) [Link]

I did not submit this to -stable because this bug is not in 2.6.25.

"Stable" kernel 2.6.25.7 released

Posted Jun 17, 2008 14:13 UTC (Tue) by PaXTeam (guest, #24616) [Link]

'exploitable' wasn't the best term, interpret it as 'triggerable' instead. other than that,
this code can be compiled as modular and hence loaded a lot later than system boot, it's up to
the sysadmin. in any case, we don't learn whether this potential NULL function pointer deref
occurs while the kernel holds any locks, resources, etc that may cause trouble. do you know
one way or another? that's the point we're trying to make!

PS: we're glad to have learned that at least older kernels aren't affected, would have been
nice to have a word about this in the commit because NULL *function* pointer dereferences
immediately trigger a mental 'look here, it's a potential full kernel compromise' alarm.

"Stable" kernel 2.6.25.7 released

Posted Jun 17, 2008 16:10 UTC (Tue) by mhalcrow (guest, #17371) [Link] (3 responses)

> We also have vendorsec sitting on a patch from Serge Hallyn fixing the
> vulnerability in TPM i alluded to in my previous posting.  One week on
> a one-line fix which has yet to make it upstream (which Serge requested
> be fixed ASAP).

rw_verify_area() makes certain that the size_t value fits in a signed
int, so this is actually not a problem that requires a security update
in the kernels shipping the driver. It is, at worst, sloppy code that
should be fixed in the next regular release.

"Stable" kernel 2.6.25.7 released

Posted Jun 17, 2008 16:49 UTC (Tue) by PaXTeam (guest, #24616) [Link] (2 responses)

not quite. on 64 bit archs

  count = (size_t)(2^32-1)

would pass the

  (ssize_t) count < 0

check whereas

  int in_size = size

would still make it -1 and trigger the bug. in other words, you had two bugs, one of using a
signed type for size and second, a truncation.

"Stable" kernel 2.6.25.7 released

Posted Jun 17, 2008 17:53 UTC (Tue) by mhalcrow (guest, #17371) [Link] (1 responses)

> not quite. on 64 bit archs
>
>  count = (size_t)(2^32-1)
>
> would pass the
>
>  (ssize_t) count < 0
>
> check whereas
>
>  int in_size = size
>
> would still make it -1 and trigger the bug.

This is the code:

---
#define MAX_RW_COUNT (INT_MAX & PAGE_CACHE_MASK)

int rw_verify_area(int read_write, struct file *file, loff_t *ppos, size_t count
)
{
        struct inode *inode;
        loff_t pos;

        inode = file->f_path.dentry->d_inode;
        if (unlikely((ssize_t) count < 0))
                goto Einval;
        pos = *ppos;
        if (unlikely((pos < 0) || (loff_t) (pos + count) < 0))
                goto Einval;

        if (unlikely(inode->i_flock && mandatory_lock(inode))) {
                int retval = locks_mandatory_area(
                        read_write == READ ? FLOCK_VERIFY_READ : FLOCK_VERIFY_WR
ITE,
                        inode, file, pos, count);
                if (retval < 0)
                        return retval;
        }
        return count > MAX_RW_COUNT ? MAX_RW_COUNT : count;

Einval:
        return -EINVAL;
}
---

This function pegs the value returned to MAX_RW_COUNT, which is at most 0x7FFFFFFF (it will
actually be reduced to a page boundary). If count = 0xFFFFFFFF, then 0xFFFFFFFF > 0x7FFFFFFF,
so 0x7FFFFFFF is the largest value that can be returned from this function. This is the value
that gets passed to tpm_write() as a size_t data type (see vfs_write()).

"Stable" kernel 2.6.25.7 released

Posted Jun 17, 2008 19:38 UTC (Tue) by PaXTeam (guest, #24616) [Link]

thanks, i missed the limiting at the end. still, this pattern is dangerous, someone had better
audit the code for it.

"Stable" kernel 2.6.25.7 released

Posted Jun 17, 2008 17:11 UTC (Tue) by trasz (guest, #45786) [Link]

Oh, come on.  At least there was no easily exploitable privilege elevation bug this time.  ;->

Which doesn't change the fact that Linux is much closer to Windows than to other unices or
unixlikes wrt number of security holes.

"Stable" kernel 2.6.25.7 released

Posted Jun 17, 2008 18:33 UTC (Tue) by olecom (guest, #42886) [Link] (4 responses)

IT bubble days are over. Linux kernel (almost the only useful FOSS thing left) tries to not
loose it's volume.

Developers do what they do on limited resources, using dumb tools or no tools at all, saving
buzz-hype using PR fuzz. It is a social and economical problem, not a technical and/or ethical
one.

If GRSecurity/PaX wants to save this only FOSS thing from security holes, then systematic
education, automation of audit and code creation by tools must be employed, database of broken
C/API usage must be collected, those patterns must be coded and automated by static analysis
on the source editing stage.

This must big and hard step, step forward. But your even smaller resources are wasted to fix
and confront consequences. Also i don't see something mentioned in your workflow/goals. And
investing into something as moot as all this even for "better future", isn't the way business
wants to make money today.

Top developers try to stay in tune with hardware support/performance side of the technology
development. Or they do, what they know how to do best or just somehow (another fs, another
scheduler, etc.). They and many others are doing this by basic think+edit+patch+debug(rc1,
rcX)... No `git` or similar can eliminate "thinking" and knowledge there.

While automated checking and automated creating of code may reduce debug stages and predict
problems on level higher than `gcc -Wall`. Again step forward. But this again against those
companies, who milk from static analysis, security audit and consulting.

Linus tries to bring tools, but all so far made, were NIH reimplementation of existing ones.
Systematic approach like regression tracking is a craft of committed individuals, no automated
tools are available also. And their work is also in some kind of fuzzy state.

Problem of those cargo-cult security specialists, grown under the shadows of LKML and dark
ages of Linux 0.99, now being on the top of the food chain and don't want to listen or
revolutioning something, is one of all human kind. Just look at present science and thus
education, politics, economics, etc... Unless they will gain more, one have no luck. In case
of retire, make sure you/your agenda have educated and skilled youngsters to propose and
compete.

"Stable" kernel 2.6.25.7 released

Posted Jun 17, 2008 19:36 UTC (Tue) by aleXXX (subscriber, #2742) [Link] (3 responses)

> 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, Eclipse, bind, sendmail, postfix, ruby, 
python, cmake, eCos, WebKit/KHTML, Firefox, OpenOffice.org, KDE, Gnome, X 
Windows, LLVM, php, Tomcat, Samba, FreeBSD, Darwin, sdcc, mplayer, ...

Alex

"Stable" kernel 2.6.25.7 released

Posted Jun 17, 2008 23:36 UTC (Tue) by olecom (guest, #42886) [Link] (1 responses)

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.

"Stable" kernel 2.6.25.7 released

Posted Jun 18, 2008 6:48 UTC (Wed) by aleXXX (subscriber, #2742) [Link]

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

Alex

"Stable" kernel 2.6.25.7 released

Posted Jun 18, 2008 13:41 UTC (Wed) by olecom (guest, #42886) [Link]

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

Fun SELinux remote DoS blast from the past

Posted Jun 17, 2008 22:13 UTC (Tue) by spender (guest, #23067) [Link]

Never mentioned as such in the public, as far as I can tell (I searched quite a bit).  No CVE
either, for that matter.  It's old (2005), but this is the type of information I'm compiling.

Here's the official fix:
http://marc.info/?l=git-commits-head&m=11144414510467...
Short message is "[SELINUX]: Fix ipv6_skip_exthdr() invocation causing OOPS."

No mention of security in the short message or the detailed long message.

Some months later Arjan van de Ven posts to vendor-sec and the kernel security list:
From: Arjan van de Ven <arjanv@redhat.com>
To: vendor-sec@lst.de, security@kernel.org
Subject: [vendor-sec] remote kernel DoS
X-Original-Date: Fri, 2 Sep 2005 10:30:58 +0200

Hi,

just FYI:
we have reason to believe that
http://marc.theaimsgroup.com/?l=linux-netdev&m=111417...
is beeing triggered from remote in the wild (two machines hitting it in the
same public cluster within 3 days).
It's fixed in kernel.org for a while now.
Assume this issue to be public since it's heavily discussed on public irc
already.



----

No replies, and I can't find any evidence of this post resulting in any sort of public
announcement.  I'm sure admitting SELinux *causing* a remote DoS was not something RedHat and
others were willing to admit.

-Brad