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