Not logged in
Log in now
Create an account
Subscribe to LWN
Pencil, Pencil, and Pencil
Dividing the Linux desktop
LWN.net Weekly Edition for June 13, 2013
A report from pgCon 2013
Little things that matter in language design
Now would all you whiners that keep saying that the kernel developers should spend all of their time determining if this or that bug could be a security problem for you in particular please GET A CLUE!
126.96.36.199 Release notes
Posted Feb 22, 2010 4:41 UTC (Mon) by bojan (subscriber, #14302)
Posted Feb 22, 2010 5:57 UTC (Mon) by spender (subscriber, #23067)
I'd also like to say something about the last paragraph of the article. "Those who would complain about how the stable tree is managed" "do well to remember" a few years ago when Chris Wright was involved in the stable releases as well. The official policy was different back then, and it's gone downhill since he stopped being involved. As for insinuating that the complainers (which would include me) haven't stepped up to offer time/energy, I'd like to point out that in July 2008 around the time when this issue was first heavily debated, the PaX Team and myself offered our free time to do similar cursory write-ups on the stable releases. Jake had presented the idea to us and said it would be hosted on LWN. Nothing had ended on a sour note, but the last email we received about it was the day after the first email we received about it. We didn't hear anything else back until we asked about it ourselves again in January of 2009. Apparently in the meantime Jake thought "it might not be very productive" and failed to inform us that he scrapped the idea.
Like Eugene mentioned, some of us are putting forth the effort to bring some honesty to the security of the kernel. If you look at Linus' ridiculous changelog message for move_pages(), at the lengths he went through to take the accurate, useful information he was given and turn it into something pointlessly obfuscated (when the two line fix screams of fixing completely nonexistent bounds checks), you'll understand why the work of the "complainers" is important. It's surprising, actually, given Linus' hatred for embargoes -- he wants users to have the security bugs fixed and not have to wait an arbitrary amount of time for it. How does he expect these fixes to get back to actual users if he actively works to hide them?
Seriously, look at it:
>From: Linus Torvalds <email@example.com>
>commit 6f5a55f1a6c5abee15a0e878e5c74d9f1569b8b0 upstream.
>We incorrectly depended on the 'node_state/node_isset()' functions
>testing the node range, rather than checking it explicitly. That's not
>reliable, even if it might often happen to work. So do the proper
>Reported-by: Marcus Meissner <firstname.lastname@example.org>
>Acked-and-tested-by: Brice Goglin <Brice.Goglin@inria.fr>
>Acked-by: Hugh Dickins <email@example.com>
>Signed-off-by: Linus Torvalds <firstname.lastname@example.org>
>Signed-off-by: Greg Kroah-Hartman <email@example.com>
> mm/migrate.c | 3 +++
> 1 file changed, 3 insertions(+)
>@@ -953,6 +953,9 @@ static int do_pages_move(struct mm_struc
> goto out_pm;
> err = -ENODEV;
>+ if (node < 0 || node >= MAX_NUMNODES)
>+ goto out_pm;
> if (!node_state(node, N_HIGH_MEMORY))
> goto out_pm;
I can imagine fixes for buffer overflows being worded like:
"We incorrectly depended on strcpy for testing the array size, rather than checking it explicitly. That's not reliable, even if it might often happen to work. So do the proper explicit test."
Posted Feb 22, 2010 10:57 UTC (Mon) by tialaramex (subscriber, #21167)
It's not clear from this whether you merely offered (it's easy to offer) or whether you actually did it. If you did, links please? It might be interesting to see whether your attempts were any better than our esteemed editor.
Posted Feb 22, 2010 11:23 UTC (Mon) by PaXTeam (subscriber, #24616)
it was a private discussion via email and i think i'm not at liberty to quote it without consent but if the other participants agree to make them public, so do i.
Posted Feb 22, 2010 12:44 UTC (Mon) by tialaramex (subscriber, #21167)
The write ups themselves would not constitute part of a "private discussion"
Posted Feb 22, 2010 13:38 UTC (Mon) by PaXTeam (subscriber, #24616)
no, you were just being dense as usual. try to read the sentences next to what you quoted and understand that the whole effort sort of died down and not because we wanted it.
> I am asking if these "cursory write-ups" actually exist.
i can't speak for spender here but i keep my own logs on various commits here for stuff that i find relevant for myself (not necessarily security related either). but that's a private list and not what we were going to publish.
> It seems not.
it seems you're just trolling as usual. but if you want to get a taste of what was going to be published, read spender's twitter stream where he pointed out several silently fixed security bugs over the past months, many if not all of them without a CVE at the time. reminds me, did the sparc64 NX bug get a CVE already?
> The write ups themselves would not constitute part of a "private discussion"
what's private and what's not is not for you to decide.
Posted Feb 22, 2010 17:39 UTC (Mon) by vonbrand (subscriber, #4458)
I'm sorry, but you claim to be doing the work of travelling the patches and checking them for security relevance, and do not publish the results, while complaining others don't publish the very same data (which they arguably don't have at hand)?
I just can't imagine our esteemed editor refusing a volunteer column like the article we are talking about here.
Posted Feb 22, 2010 19:10 UTC (Mon) by PaXTeam (subscriber, #24616)
some commits, yes.
> and checking them for security relevance,
i mostly check them for interference with my work and that necessarily means that sometimes my eyes catch security relevant commits as well.
> and do not publish the results
i don't understand what is there to publish. aren't all bugs just bugs? what else do *you* want to know about them? you can't defend the coverup of security bugs and complain about their lack of disclosure at the same time. make up your mind ;). also you're welcome to follow spender's twitter stream, we often inform each other about suspicious commits and investigate together.
> while complaining others don't publish the very same data (which they arguably don't have at hand)?
i never complained about not disclosing security impact information they do not themselves have already. quote me back if you believe otherwise. what i did and still do complain about is when they *know* that a commit fixes a security bug but cover it up.
> I just can't imagine our esteemed editor refusing a volunteer column like the article we are talking about here.
it wasn't him (Jon) and it wasn't going to be part of LWN but rather a reply to -stable postings on lkml (spender went back and double checked the emails).
Posted Feb 22, 2010 19:32 UTC (Mon) by nix (subscriber, #2304)
Posted Feb 22, 2010 17:45 UTC (Mon) by vonbrand (subscriber, #4458)
I fail to see any problem with the changelog entry. A range test was mistakenly omited, add it. Sure, this particular missing range check can have disastrous consecuences, just as there are probably a dozen others added the same way that are "can't happen"s or have little or no impact.
The log entry describes what was wrong with the code, as it should.
Posted Feb 22, 2010 19:33 UTC (Mon) by nix (subscriber, #2304)
Posted Feb 22, 2010 20:36 UTC (Mon) by bojan (subscriber, #14302)
Posted Feb 22, 2010 19:07 UTC (Mon) by clugstj (subscriber, #4020)
It's very hard work to do this even in the general case. I'd much rather the kernel developers spend their time FIXING bugs than trying to imagine the possible uses a black hat could have for it.
I didn't point anyone out explicitly, but it does appear that I hit a nerve.
Posted Feb 22, 2010 19:22 UTC (Mon) by spender (subscriber, #23067)
"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."
"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."
"yes, it would be the next step after the already known security issues are acknowleged at least."
"And again, before anyone brings it up again, it's not about the developers themselves trying to figure out if every bug is a security bug -- it's about not hiding or obfuscating what they are clearly aware of."
"If you don't omit the security information you're aware of, nothing changes on the blackhat side because they can already spot developer weasel words when the developers are committing a vulnerability fix."
I look forward to your apology.
Posted Feb 22, 2010 20:16 UTC (Mon) by clugstj (subscriber, #4020)
If you told a kernel developer that such and such a bug has this security impact, why should he automatically believe you? Unless he very much trusts your opinion or has the time to check your findings, he would be foolish to do so.
I made the original comment for two reasons:
1) I have seen the kind of comment of which I speak. I never said it was from you, nor did I have you in mind.
2) I don't mind stirring the pot.
Posted Feb 22, 2010 20:24 UTC (Mon) by bojan (subscriber, #14302)
Er, because he found and wrote exploits for quite a few security problems in the kernel?
Posted Feb 25, 2010 13:52 UTC (Thu) by vonbrand (subscriber, #4458)
Please stop this nonsense. If Linus (or whoever) knows about the possible security implications of, let's say, 10 or 20% of the bugs, and only marked those, the majority of security sensitive bug patches would just be ignored by would-be "experts", and the whining about the other "not reported" bugs would start whenever some box gets broken into...
A bug in the kernel is potentially extremely serious, go and fix it. Questions are optional, patching isn't.
Posted Feb 25, 2010 14:55 UTC (Thu) by PaXTeam (subscriber, #24616)
stop that nonsense. you have zero evidence for it. in the previous thread a kernel developer only offered anecdotal evidence which is of course as good as mine or anyone else's. you might want to understand who patch users are too: http://lwn.net/Articles/374094/ . also you might want to explain why file system corruption bugs are marked as such in commit messages whereas there's no guarantee that unmarked commits don't fix file system corrupting bugs.
> A bug in the kernel is potentially extremely serious[...].
it depends on the bug. and as we learned from local experts here, it also depends on what one considers a bug at all ;).
> Questions are optional, patching isn't.
you've never really had a real job, have you.
Posted Feb 25, 2010 20:44 UTC (Thu) by nix (subscriber, #2304)
Not all filesystem-corrupting bugs are recognised as such at fix time,
just like not all security bugs are recognised as such. (It is probably
easier to detect a filesystem-corrupting bug than a security bug, because
at least there are broad regions of the kernel where bugs are unlikely to
affect filesystems, which is not true for security holes.)
btw, nice to see you're vilely rude to everyone, not just me (and fifty
seconds' googling would make it clear that he's had multiple real jobs in
the free software community. He gives out his real name, you see.)
Posted Feb 25, 2010 22:42 UTC (Thu) by PaXTeam (subscriber, #24616)
aha. and "if people realise at fix time that they are security bugs" they... don't mark them as such. not only that, they even try to explain why that's a good thing. now you tell me why the same arguments don't apply to filesystem corruption bugs (and many others, i just picked an obvious one for this exercise). or more to the point, why the arguments for marking known filesystem corruption bugs don't apply to known security bugs. btw, i'm glad that after years of misunderstanding you're slowly getting it ;).
> [...]because at least there are broad regions of the kernel where bugs
> are unlikely to affect filesystems,
anything that can result in kernel memory corruption, in those broad regions of the kernel included, has a fair chance to trash filesystem related (meta)data as well. speaking of which, by the same token if said memory corruption bugs are not marked for security, they should at least be marked for potential filesystem corruption but not even that is done.
> btw, nice to see you're vilely rude to everyone, not just me
i wasn't rude to you, you yourself admitted that you sometimes post under the influence of drugs that you later regret. i was merely wondering if the same happened here as well because you so obviously posted crap about something that wasn't ever said (you're welcome to prove your post with quotes from us).
> (and fifty seconds' googling would make it clear that he's had multiple
> real jobs in the free software community.
make it 5 seconds, but then we've got bigger skill differences i guess ;). and yes, i know where he teaches and it's also clear that he has no idea whatsoever about how a real corporation works where people have real responsibilities and the "Questions are optional, patching isn't" mentality doesn't fly in *any* production environment i've ever seen (hint: it's not how RH/Novell work either). but someone like you should know better than defending such a stand.
> He gives out his real name, you see.
this coming from an anonymous coward sounds just way too funny ;).
Posted Feb 25, 2010 23:09 UTC (Thu) by nix (subscriber, #2304)
aha. and "if people realise at fix time that they are security bugs"
they... don't mark them as such.
Posted Feb 22, 2010 19:28 UTC (Mon) by PaXTeam (subscriber, #24616)
it is as none of us made such a claim you're trying to push here, in fact every time this comes up we make a claim to the contrary: kernel devs are not expected to figure out the security impact of bugs because they're not qualified to do so. just look at Jon's effort here and how he missed #1 and mischaracterized #2.
> I'm too lazy to look it up
you're not lazy to look it up, you're unable to but needed a convenient excuse.
> but nearly every time that there is a security problem in a kernel update
you're welcome to find a *single* post from us that makes a claim you wish to attribute to us. after all, if it was 'nearly every time' you won't have to spend more than a few seconds to find one.
> someone belly aches that the kernel developers should figure out for if this bug is a security problem for them.
we never made such a claim, and in fact i don't recall anyone else making it either. but the onus is on you to back up your statement.
> I didn't point anyone out explicitly, but it does appear that I hit a nerve.
considering the amount of trolling and shouting from you, i know whose nerve was hit ;).
Posted Feb 22, 2010 20:22 UTC (Mon) by bojan (subscriber, #14302)
I certainly never asked for anything like that.
So, once again: if it is known, it should be passed on. That's it.
Posted Feb 22, 2010 20:25 UTC (Mon) by clugstj (subscriber, #4020)
Posted Feb 22, 2010 20:33 UTC (Mon) by bojan (subscriber, #14302)
Posted Feb 22, 2010 21:41 UTC (Mon) by PaXTeam (subscriber, #24616)
Posted Feb 22, 2010 20:25 UTC (Mon) by jake (editor, #205)
(sorry for the late reply, I was travelling back from SCALE)
At around the same time as we were discussing the idea, there was a flamewar about the same subject going on in lkml and it seemed clear to me that the personalities involved (on both sides) would likely just perpetuate that. That's why I didn't think it would be very productive, fwiw.
But I certainly don't discourage information about the known security impacts of stable tree patches (or any other patches for that matter) being published. If it were, we would be likely to link to it.
Posted Feb 22, 2010 21:24 UTC (Mon) by nix (subscriber, #2304)
It is quite plain by this point that they are impossible to satisfy.
Posted Feb 22, 2010 21:36 UTC (Mon) by PaXTeam (subscriber, #24616)
Posted Feb 22, 2010 23:06 UTC (Mon) by nix (subscriber, #2304)
I *really* want a killfile for LWN. There'd only be two names on it for
me... hm, actually, three, petegn deserves to be on it too.
Posted Feb 22, 2010 23:56 UTC (Mon) by spender (subscriber, #23067)
Posted Feb 23, 2010 4:03 UTC (Tue) by chad.netzer (guest, #4257)
Posted Feb 23, 2010 4:23 UTC (Tue) by corbet (editor, #1)
Posted Feb 23, 2010 6:44 UTC (Tue) by bojan (subscriber, #14302)
Is this directed to the above mentioned "pretentious" people? If yes, could you please point out which of my comments was disrespectful here?
Posted Feb 23, 2010 13:56 UTC (Tue) by corbet (editor, #1)
Posted Feb 23, 2010 19:09 UTC (Tue) by chad.netzer (guest, #4257)
The LWN comment section is not well suited to these kinds of opinionated
"discussions", since there are no tools to control the threading, collapsing
and rating of comments, etc. Hence, the same points keep getting
fruitlessly reargued. Not sure its fixable, but a simple filter *might* help
with signal to noise for those that want to have a novel discussion.
Meanwhile, I'd rather talk about things like which of these fixes actually
solve an issue for people. We have been testing #36 for a short while,
since the umount bug it fixes was actually hitting us in practice. It'd be
nice to talk about something like who here is actually using and testing the
2.6.32.y series, and what issues have they had?
Posted Feb 23, 2010 23:50 UTC (Tue) by nix (subscriber, #2304)
... or, rather, the only wrong thing is an explosion of almost totally
idle ext4 direct I/O kernel threads: one per CPU per sb. That's 96 or
something on my machine. I only want direct I/O for *one filesystem*
Posted Feb 23, 2010 7:02 UTC (Tue) by bojan (subscriber, #14302)
First, they tell us that all bugs should be considered "normal bugs": http://kerneltrap.org/Linux/Security_Bugs_and_Full_Disclo....
Then in 188.8.131.52 (http://lwn.net/Articles/373579/), just a while ago, we are told that, yes, there are security bugs. But, we cannot know which ones they are, although kernel developers already know, because they took special steps to make sure they were properly backported and tested.
In the meantime, we are STRONGLY encouraged to upgrade. Why strongly? Why not just normally? After all, security bugs are just normal bugs, right?
Now, please, tell me what is pretentious about asking to square up the above? I do not see how both can be true. Either security bugs are special (given that kernel developers are obviously giving them special treatment) or they are not. Also, if they already know about them, why can't we be told?
Posted Feb 23, 2010 22:09 UTC (Tue) by nix (subscriber, #2304)
I don't agree with Linus that bugs that are *known* to be security bugs at
the time they're fixed shouldn't be called out as such and backported. I
do agree that it's impractical to expect the security implications of all
bugs to be spotted by the person who fixes them at the time the fix is
made: even if it is obvious to a steeped-in-security guy like spender, it
may not be obvious to everyone.
I'd assume that everyone involved in kernel programming knows how bad
buffer overruns and wild pointer dereferences are. After the recent
palaver I'd hope they'd know that NULL pointer dereferences are bad too.
But there are lots of other classes, and some are rare enough that I
wouldn't know them if I saw them, and might not even know them if they
were pointed out to me. (This is where spender's published exploits are
especially useful to whitehats, IMNHSO: for didactic purposes. He puts
comprehensible comments in the damn things! You can use any random
blackhat's exploit to see if your machine is vulnerable, but if you want
to know how that class of exploit works, and thus why the vulnerability is
a vulnerability, you need more than a pile of incomprehensible uncommented
Posted Feb 23, 2010 22:36 UTC (Tue) by bojan (subscriber, #14302)
Not my words, actually. Directly from Linus:
"I personally consider security bugs to be just 'normal bugs'. I don't cover them up, but I also don't have any reason what-so-ever to think it's a good idea to track them and announce them as something special."
> it's that in an unprotected environment like the kernel, almost any bug could potentially be a security bug (although it might be hard to exploit if, say, it requires module unloading to trigger). i.e., normal bugs are potentially as important as security bugs -- but it is quite impractical to consider them *actually* as important as security bugs, because so very many bugs are fixed all the time. They're merely *potential* security bugs.
> I don't agree with Linus that bugs that are *known* to be security bugs at the time they're fixed shouldn't be called out as such and backported.
And that is the crux of the issue here. What is being asked is actually quite simple. If the kernel developers know it's a security issue (by determining that themselves or by being told by someone experience in security), they should tell the rest of us. No extra effort required.
All other bugs, of course, can still turn out to be security issues. Such is kernel life, I guess. I'd say everyone is aware of that by now.
Posted Feb 27, 2010 6:30 UTC (Sat) by malor (subscriber, #2973)
Having the same number of actual bugs, but being less aware of security holes, is actively dangerous. I consider it egregious behavior to deliberately mislead people about the nature of security fixes.
Posted Feb 22, 2010 21:46 UTC (Mon) by bojan (subscriber, #14302)
What is impossible to satisfy is illogical explanations about why things that were known to be security problems never got disclosed as such. The latest obfuscation by Linus is a clear case in point. The announcement of the .8 release is another.
If something as implemented is nonsense, expect questions. Waving a magic wand in the hope that these questions will vanish won't work. Neither will same illogical explanations.
Posted Feb 22, 2010 21:37 UTC (Mon) by PaXTeam (subscriber, #24616)
what form of disclosure would you link to? twitter? web forum? email archive?
Posted Feb 22, 2010 21:48 UTC (Mon) by jake (editor, #205)
i think it would be difficult to link to individual twitter messages about each problem as it was noted (and i don't know that twitter gives enough room for context and such), but some kind of summary in a web forum or page, mailing list posting, or whatever would (obviously) be of interest to our readers.
Posted Feb 26, 2010 0:34 UTC (Fri) by malor (subscriber, #2973)
Copyright © 2013, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds