Weekly Edition
Return to the Kernel page
| |||||||||||||
Kernel security problems: a response
I would like to try to clarify a few points in the article, "Handling
kernel security problems" by Jonathan Corbet.
First off, I speak only for myself, not for the other half of the Linux -stable team, Chris Wright, who might totally disagree with me, nor for the other kernel developers who help out with the security@kernel.org alias, nor for my current employer Novell. Also note that all of my -stable development is done on my own time, and is not part of my role at my current job. All of that out of the way, I object to a few things stated in the original article:
It does seem that there has been a trend away from explicit
recognition of security issues in the stable releases. The
inclusion of CVE numbers was once common; in the 2.6.25 series,
only 2.6.25.1, 2.6.25.2, and 2.6.25.5 had such numbers in the
changelogs. It is, indeed, true that a straightforward reading of
the stable release changelogs will not tell users whether those
releases fix relevant security issues.
A number of times, when we do -stable releases, there are no CVE numbers issued for the "security" related issues that are fixed in there. This happens when the fix is first made in Linus's tree, and is either forwarded to the stable@kernel.org alias saying, "we need to get this out now", or just by the fact that it is only later that people realize that a CVE number should be allocated. And yes, the trend is away from explicit recognition of security issues, exactly following Linus's statement that you quote from. It comes down to who are the users of the -stable kernel series. I personally see these kernels for two different groups of people:
The first group should always update to the latest -stable kernel update as they are relying on the -stable team to always provide them the latest fixes that are known to be needed for them. Simply marking things as "security related" can be misguided as Linus points out. The change log entries should show all users what was fixed, and if they run machine where this code is used, then they should upgrade. It's as simple as that. In fact, in the 2.6.25.11 release I tried to say exactly that:
It contains one bugfix, any user of the 2.6.25 kernel on x86-64
with untrusted local users is very STRONGLY recommended to
upgrade.
How much clearer can I be? Does a user of the -stable tree, who has to be technically competent to be able to do such a thing in the first place, need to know more to decide if they need to upgrade their machines or not? It seems people are upset that I am no longer using the magic words "security fix", and that is true, I am not saying that anymore. As Linus and others have noted, marking some bugs as being "security-related" is not helpful, especially as not everyone can even agree - or sometimes even know at release time - whether a bug has security implications or not. Also note that this release does not refer to a CVE number. This is because, as of this moment, there still is not a number assigned, despite asking the relevant groups for such an assignment. I never want to hold up a release by waiting for any such number, so I personally will just not use them in the future in -stable releases unless they are already contained in the original changelog entry in Linus's tree. The second group, the distributions, all seem very happy with how the -stable releases are conducted. They have the capability to pick and choose from the fixes and apply them to their older kernel versions and ship them to their customers as they see fit. The distros all know what things are security related by the fact that they know and understand the code and the threat model as they have developers assigned to handle such security issues, and have done so for years. In your summary, you state:
It is good to have a clear sense for what the security problems in a
piece of code are. If nothing else, it helps the project itself to
understand where it stands with regard to security and whether things
are getting better or worse. So it would be nice if the kernel
developers could be a bit more diligent and organized in how they
track security issues, much like the tracking of regressions has
improved over the last couple of years.
I think the individual developers of the kernel all know quite well what the security problems for their code are. This is backed up by the fact that these developers are the ones usually making the fix and telling the -stable team that a specific patch is needed to be added. What you seem to be asking for is a way to somehow classify bugs and fixes in the kernel tree as "security related" or not. And that goes back to Linus's original point. To try to do so marginalizes bugs which are somehow not so designated as not worth fixing. However, if someone wants to do this work for the kernel community, and it proves to be useful over time, I'll be the first in line to say that I was wrong. (Log in to post comments)
Why not follow that rule then? Posted Jul 17, 2008 2:41 UTC (Thu) by bojan (subscriber, #14302) [Link] > As Linus and others have noted, marking some bugs as being "security-related" is not helpful, especially as not everyone can even agree - or sometimes even know at release time - whether a bug has security implications or not. If above is true, then saying: > any user of the 2.6.25 kernel on x86-64 with untrusted local users is very STRONGLY recommended to upgrade Is clearly not following that. In other words, you are saying that this is a security issue (keywords: "untrusted users", "very STRONGLY ... upgrade"), just using slightly different language. So, why was this marked as "security fix" if Linus and others say that doing that is not helpful at all? Just release the things with no comment then.
Why not follow that rule then? Posted Jul 18, 2008 7:42 UTC (Fri) by dgm (subscriber, #49227) [Link] Because he said "some bugs" and not "any bugs".
Kernel security problems: a response Posted Jul 17, 2008 3:02 UTC (Thu) by pr1268 (subscriber, #24648) [Link] While I partially agree with Pax Team's argument that software bugs should be categorized on the severity of their impact (see my postings on the Handling Security Problems post), I now realize the issue with the Kernel devs' responsibility in classifying such bugs. I admit to being a user of the -stable kernel, and questions I've asked about why I'm "strongly encouraged" to upgrade to 2.6.25.x were based on this. But, having followed the LKML for the past several weeks while this debate transpired, I've since been enlightened on why it makes more sense for the kernel devs to ignore the severity of bugs and instead just worry about fixing them. Thank you, Greg, for the response. And thanks to Our Editor for having the integrity to openly publish a response that takes issue with one of his articles.
Kernel security problems: a response Posted Jul 17, 2008 7:26 UTC (Thu) by dlang (✭ supporter ✭, #313) [Link] as a user of the -stable kernels, my strategy is simple if they update a driver that applies to hardware that I use I need to apply the update. I will look at the description to see if there are further details that will indicate that it's less critical, but usually I need to apply the fix no matter what bug it's fixing, simply becouse I may run into the bug and crash the system.
Kernel security problems: a response Posted Jul 17, 2008 8:26 UTC (Thu) by nix (subscriber, #2304) [Link] I assume you also apply stable updates if something's changed in generic code that you're bound to run (say, mm).
Kernel security problems: a response Posted Jul 17, 2008 8:53 UTC (Thu) by k3ninho (subscriber, #50375) [Link] Can I has CVE number for this spelling error? Penultimate sentence has excessive negation compromising the sense of the sentence: "To try to do so marginalizes bugs which are somehow not so designated as not worth fixing." It seems that the first 'not' would work instead as a 'now'. K3n.
Don't think so Posted Jul 18, 2008 1:37 UTC (Fri) by tialaramex (subscriber, #21167) [Link] No, there's no spelling error or other typographical problem. I think you're parsing the sentence wrong. "bugs which are somehow not so designated" are the subject of the phrase, and the claim is that they would be marginalised as "not worth fixing". This claim is true as written.
Don't think so Posted Jul 23, 2008 3:48 UTC (Wed) by roelofs (guest, #2599) [Link] No, there's no spelling error or other typographical problem. I think you're parsing the sentence wrong.The sentence can be parsed correctly, but I would claim that it's not properly written. It should instead read as follows:
To try to do so marginalizes bugs which are not so designated as somehow not worth fixing. ...i.e., move "somehow" to the second "not". That is, bugs are either so designated or not; there's no ambiguity there. It's the "worth fixing" part that's a fuzzier judgment call ("somehow"). Greg
Shocking Posted Jul 17, 2008 16:41 UTC (Thu) by mheily (guest, #27123) [Link] It is literally shocking to hear prominent Linux kernel developers say that they will continue to downplay, ignore, and disguise security problems in their kernel. The claim that "security by obscurity" helps their users and deters script kiddies is laughable. No one is asking them to publish sample exploits in the ChangeLog. All we need is to have security bugs clearly marked, along with a note about when the problem began. Since they rely heavily on vendors to distribute their kernels, they should provide advance notice to vendors so the vendors can provide a new kernel package at the same time as the vulnerability is published. The approach of silently fixing the bug in the HEAD branch (or whatever they call it in git), not telling any of the good guys, and hoping that the bad guys don't notice it is **very, very dangerous**. This kernel should definitely not be used on servers, or desktops containing sensitive or confidential information. There are free alternatives to the Linux kernel. Debian has been working on combining the Solaris and FreeBSD kernels with the Debian GNU-based userland. This might be the future of GNU, and people should check out GNU/Solaris and GNU/kFreeBSD to see how to help. If you need a system *right now* that has proper security and development practices, take a look at OpenBSD, FreeBSD, and Solaris. Until the Linux kernel developers have a change of heart about fundamental software engineering practices (i.e. security and stability), the Unix user community should treat it as an interesting toy and playground for new ideas. It's not something you would use for anything important.
Shocking Posted Jul 17, 2008 18:51 UTC (Thu) by riel (subscriber, #3142) [Link] Lets face it, there is nothing special about security bugs. Fixes for race conditions that lead to data corruption are often a much more important reason to update systems than a fix for a security bug that can only be exploited by local users. Security bugfixes are important, but they are no more important than many other kinds of bugfixes. Why would they deserve a special label?
Shocking Posted Jul 17, 2008 21:47 UTC (Thu) by mheily (guest, #27123) [Link] Bugs that cause kernel panics and/or data loss should also be given special treatment along with security bugs. Take a look at the OpenBSD 4.3 changelog as an example of the right way to do things. Both security bugs and dataloss bugs are highlighted, a problem description is given in plain English, and patches to correct the problem(s) are provided.
Shocking Posted Jul 18, 2008 2:23 UTC (Fri) by tialaramex (subscriber, #21167) [Link] If all the "security bugs" are highlighted in that changelog, would you mind explaining how? Maybe you think that's what the red text is for? Sorry, poor reading comprehension again. The red text just identifies issues for which OpenBSD provides a hand rolled patch. They don't recommend that you actually just apply these patches, like Linux they provide a stable branch with various fixes that have (or in some cases might have) security implications, as well as other changes, but not new features.
Shocking Posted Jul 18, 2008 5:10 UTC (Fri) by viro (subscriber, #7872) [Link]
I think I can do a fairly good imitation of what Theo does to folks
coming up with "I've found a local hole, the world is ending". OTOH,
you can experiment yourself - it's _not_ hard to come up with those
in OpenBSD. Let's see... Ah, here we go - take fcntl(fd, F_SETLK, ...)
vs. close(fd) in another thread, while fcntl() has already done FREF()
and sits blocked in copyin(). close(2) gets to closef(), sees no
POSIX locks set (there's none - yet), sets FIF_WANTCLOSE and goes
to sleep until usecount drops to zero. That won't happens until
FRELE() in fcntl(2). So far, so good, but now closef() sees that
FHASLOCK is not set (no flock() locks on that one) and happily
proceeds to ->fo_close(). At that point you've got a lock hanging
off (e.g.) ->i_lockf, with neither VFS nor filesystem having any idea
that it's there.
Alternatively, have another task having the same opened file (e.g.
something that got that sucker from us via SCM_RIGHTS; whatever).
Then close(2) in question will miss the same lock, leaving it in
the list. And struct file will live as long as you want it to live.
Now note that this lock has ->lf_id equal to address of struct proc
of the sucker that had created it. Even if aforementioned sucker
is long gone *and* struct proc got reused.
Turning that into a local vulnerability is left as a clue filter.
RTFS(kern/{vfs_lockf.c,kern_descrip.c,vfs_syscalls.c}). Have fun.
In the interests of disclosure, the source of the above has been
"OK, what kind of mess have I seen lately? Let's see if they've got
something similar" followed by 15 minutes of RTFS and grep.
Shocking Posted Jul 18, 2008 6:21 UTC (Fri) by viro (subscriber, #7872) [Link] PS: FWIW, equivalent bug on the Linux side is instructive. It had been _mostly_ fixed about 3 years ago. By patch that had completely missed a) SMP ordering issues making the fix incomplete b) similar hole in another turd (dnotify instead of FPOSIX locks) and... c) all security implications. And having talked to the guy who'd done the original changeset I'm fairly sure that this was no coverup...
Shocking Posted Jul 18, 2008 11:24 UTC (Fri) by nix (subscriber, #2304) [Link] In the past PaXTeam et al have said that intent doesn't matter. As far as I can tell this equates to 'it's a coverup if we say it is', and you can't argue with people like that (as I am learning). (For people who complain so loudly about definitions they play very fast and loose with theirs.)
Shocking Posted Jul 21, 2008 13:55 UTC (Mon) by pimlott (guest, #1535) [Link] In fact, the OpenBSD policy has always been what Greg articulates: "always update to the latest -stable kernel update". Theo has made this argument for years: Nobody has much time or patience for classifying bugs, and even if they did, it's actually quite tricky. Any classification will contain so many false positives and negatives that basing your security decisions on it would be foolish. Fix and patch bugs rather than philosophizing over their nature.
Shocking Posted Jul 17, 2008 22:01 UTC (Thu) by mgh (guest, #5696) [Link] Agree; Personally, I'd move quicker to apply a fix to data security than to access security. Access security threats are much easier to mitigate than data security issues within the OS. Some people are so obsessed with one class of security bug (un-authorised access) that its become all consuming for them. It's almost as if "I know my data is corrupted - but its ok NO ONE else can ever get to it" has become the mantra. Really what is being asked for could be re-phrased like this:- "What we'd like you (kernel devs) to do is to categorise and provide a risk profile for some of the bugs you fix in your software. In fact we'd like you to prioritise according to our priorities and make it explicit in your work that these threats are fixed because we believe they are more important than anything else." As for the "Full disclosure" argument its nuts - the code is there, its 100% transparent... oh, wait, you want the developer to tell you about stuff YOU think is most important - maybe the developers have decided to opt out of classification and risk assessment and just work on improving the product... Like all religious arguments the underlying requirement is to make someone else do something to make the other feel better about their world.
Shocking Posted Jul 19, 2008 12:18 UTC (Sat) by PaXTeam (subscriber, #24616) [Link] > Fixes for race conditions that lead to data corruption are often a much > more important reason to update systems than a fix for a security bug > that can only be exploited by local users. > Security bugfixes are important, but they are no more important than > many other kinds of bugfixes. Why would they deserve a special label? question: when a commit fixes a bug that can result in data corruption, does it say so or not? because if it does, then you've just answered the question above. and if it doesn't, then how do you expect distro and other people maintaining their own kernel trees to figure out whether to consider the commit for backport or not? remember, you're playing with fire here, if the people doing the backport miss just one such a commit (out of the many thousands that go into a release, no less), they'll put their users' data at risk.
Kernel security problems: a response Posted Jul 17, 2008 21:58 UTC (Thu) by zooko (subscriber, #2589) [Link] Greg: Thanks again for all the work you do on the stable Linux kernel. I'm having trouble understanding exactly what the policy of the stable team is. Could you spell it out for me? At the risk of putting the wrong words into your mouth (and I apologize if this is too far off), I currently think it might be something like this: "Users need to choose someone who prepares kernel releases for them, be it the stable team (stable kernel), Linus Torvalds (mainline kernel), or their Linux distribution (distribution kernel), and whenever that person says to upgrade, they need to upgrade ASAP. The stable team isn't going to spend the time writing explanations about the details of each bug so that users can decide for themselves how urgent that issue is in their deployments." Is that right?
Kernel security problems: a response Posted Jul 17, 2008 23:01 UTC (Thu) by nix (subscriber, #2304) [Link] The point of -stable is that the patches are so small that the users can generally decide for themselves. In larger -stables, you can follow the 'look at the drivers in use and upgrade if some of them are things you use and the bugfix looks significant' approach: for smaller ones (like security releases), you can often get away with simply reading the patch itself, even if (like me) you're not a kernel hacker. (Of course this doesn't work if you can't read a little C...)
Kernel security problems: a response Posted Jul 18, 2008 16:26 UTC (Fri) by NAR (subscriber, #1313) [Link] What you seem to be asking for is a way to somehow classify bugs and fixes in the kernel tree as "security related" or not.Actually it seems that there is a classification done - fixes that do get into the -stable tree, and fixes that don't...
Does anyone know where we can find Chris Wright's sense of integrity? Posted Jul 19, 2008 1:24 UTC (Sat) by spender (subscriber, #23067) [Link] Chris Wright has been awfully silent recently. Did everyone forget that it was only a few weeks ago that Chris Wright had this to say: http://www.fotovallescrivia.it/public/news/linux.kernel/3... "it is not true that we are actively hiding security bugs. Had I realized there was a security issue, I would highlight it in the announce message. In fact, that's our standard procedure for -stable." I don't recall any public announcement of this rather dramatic reversal of policy. Might have been a good idea to tell people. Also Greg, you should read my posting on the full-disclosure list regarding your use of the term "untrusted local users." Your usage of it is simply wrong from a security perspective and is misleading to users. "I think the individual developers of the kernel all know quite well what the security problems for their code are." You mean the same ones that thought NULL pointer dereference bugs were unexploitable until I produced an exploit for one that disabled SELinux and then continued to call them unexploitable over a year later? Those same ones? Meanwhile it seems like all the kernel developers are coming out of the woodwork echoing Linus' ridiculous "security bugs are no more important than any other bug" philosophy. It all seems rather odd, and smells badly of damage control happening behind the scenes, since this is the first time we've ever heard this from anyone. What's the matter, Chris? Redhat got you by the tongue? -Brad
Does anyone know where we can find Chris Wright's sense of integrity? Posted Jul 19, 2008 1:29 UTC (Sat) by spender (subscriber, #23067) [Link] BTW, I'm sure the (large) distributions are happy since they have access to the same private information you have access to but choose to omit, so of course they know what fixes are security fixes! (as far as your collective security bug-finding skills go, and that capability is debatable). -Brad
Does anyone know where we can find Chris Wright's sense of integrity? Posted Jul 19, 2008 10:05 UTC (Sat) by nix (subscriber, #2304) [Link] Chris hasn't posted to linux-kernel, or anywhere else that I can find, since Tue Jun 17. Now perhaps RH has muzzled him to such an extent that he's not allowed to use the net at all, specifically out of a desire to spite you. Or perhaps he's busy with something else, or on holiday. Normally one would consider the latter possibilities before leaping to the former. But then, you aren't a conspiracy theorist at *all*. Oh no.
Does anyone know where we can find Chris Wright's sense of integrity? Posted Jul 19, 2008 12:59 UTC (Sat) by spender (subscriber, #23067) [Link] If I were Chris, I wouldn't much appreciate the other man of a two man team completely reversing the -stable policy while I was away on vacation without talking to me at all about it, if that's indeed the case. That's pretty slimy, really. "Hi Chris, welcome back. While you were gone myself and the rest of the kernel developers decided that what you've been doing since 2005 just isn't important at all, and we're going to stop assisting you. Oh, and by the way, not a single kernel developer came out in support of you. We've decided that the new policy won't be what you declared the policy to be, and we've already informed the world of it without discussing it with you first." If it is the case that he's just on vacation, I hope that when he returns he gets things back to normal, and beyond that, expresses to the other kernel developer why their security-related opinions are just unacceptable. -Brad
|
|||||||||||||