| |||||||||||||
ShockingShockingPosted Jul 17, 2008 18:51 UTC (Thu) by riel (subscriber, #3142)In reply to: Shocking by mheily Parent article: Kernel security problems: a response
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?
(Log in to post comments)
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.
|
|||||||||||||