User: Password:
Subscribe / Log in / New account



Posted Jul 17, 2008 16:41 UTC (Thu) by mheily (guest, #27123)
Parent article: Kernel security problems: a response

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

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.

(Log in to post comments)


Posted Jul 17, 2008 18:51 UTC (Thu) by riel (guest, #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?


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.


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.


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.


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


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


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


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.


Posted Jul 19, 2008 12:18 UTC (Sat) by PaXTeam (guest, #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.

Copyright © 2017, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds