User: Password:
|
|
Subscribe / Log in / New account

2.6.32.9 Release notes

2.6.32.9 Release notes

Posted Feb 23, 2010 22:09 UTC (Tue) by nix (subscriber, #2304)
In reply to: 2.6.32.9 Release notes by bojan
Parent article: 2.6.32.9 Release notes

I think you got that backward. It's not that security bugs are normal
bugs, therefore security bugs are as unimportant as normal bugs: 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. And this is true of most bugs when they're fixed.

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


(Log in to post comments)

2.6.32.9 Release notes

Posted Feb 23, 2010 22:36 UTC (Tue) by bojan (subscriber, #14302) [Link]

> I think you got that backward. It's not that security bugs are normal bugs, therefore security bugs are as unimportant as normal bugs:

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.

Completely agree.

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

2.6.32.9 Release notes

Posted Feb 27, 2010 6:30 UTC (Sat) by malor (guest, #2973) [Link]

Yeah.... I, for one, totally don't expect them to spend a bunch of extra work figuring out if something is a security problem. But I DO expect them to pass along if it's a confirmed security issue if they already know about it. Deliberately obfuscating that information only hurts me. It can't possibly help. The ONLY thing it "helps" is that people get less pissed about security holes.

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.


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