Recent Features
| |||||||||||||
Kernel security, year to dateKernel security, year to datePosted Sep 10, 2008 3:00 UTC (Wed) by bfields (subscriber, #19510)In reply to: Kernel security, year to date by k8to Parent article: Kernel security, year to date
Sound Card Driver X does not produce sound. I dunno, maybe someone has an alarm system that runs on Linux? Any bug causes the system to behave in a way that a user (or application writer, or administrator) didn't anticipate. So for any bug you can probably contrive some situation where it could have security consequences. I'm not convinced that completely makes the "security bug" category useless, but it's probably true that there's more of a continuum then we usually admit.
(Log in to post comments)
Kernel security, year to date Posted Sep 10, 2008 3:30 UTC (Wed) by spender (subscriber, #23067) [Link]
It's very simple, Eric is just feigning ignorance here (or is seriously
deluded) so as to give credence to Linus' belief that security bugs are no different or more important than regular bugs.
If you had read http://lkml.org/lkml/2008/7/17/94, you'd have seen the PaX
Sound not working is not a violation of the kernel's security model.
For another example, BUG()s which occur without any locks held that simply
-Brad
Kernel security, year to date Posted Sep 10, 2008 9:04 UTC (Wed) by bojan (subscriber, #14302) [Link]
> Linus' belief that security bugs are no different or more important than regular bugs
There is no doubt in my mind that Linus is a genius. But, that belief of his is borderline nonsense. It's like saying that you want your mechanic to assign the same importance to problems with your brakes and to discolouration of the upholstery.
Kernel security, year to date Posted Sep 10, 2008 13:56 UTC (Wed) by dlang (✭ supporter ✭, #313) [Link]
as long as your mechanic fixes both, why would you care that they wereboth just single line-items in your bill?
Linus isn't saying that they are the same when deciding what to fix, he is saying that when the fixes are completed and available they should be treated the same, no matter if they are known to be security problems or not.
in part this is because many bug fixes end up fixing security problems that the author of the fix doesn't realize are there in the first place, so if you only apply fixes marked as 'security' you will not have a secure system.
other people think that someone should research all possible implications of every bugfix, and if it could be a security issue create a CVE number for it, and only after that submit the fix to be included.
personally I would rather see the person fix a couple more bugs than to have them take the time to jump through all of those hoops (never mind the fact that many fixes get tweaked after they are submitted, which would cause the need to go through all of that again)
Kernel security, year to date Posted Sep 10, 2008 15:46 UTC (Wed) by PaXTeam (subscriber, #24616) [Link]
> Linus isn't saying that they are the same when deciding what to fix, he
> is saying that when the fixes are completed and available they should be > treated the same, no matter if they are known to be security problems or > not.
when a non-security bug is fixed (say, one resulting in file system corruption), the commit explains what the issue was. when a security bug is fixed, it doesn't say so. how's that equal treatment?
> in part this is because many bug fixes end up fixing security problems
why would anyone apply only explicitly marked security fixes? maybe one just wants to use that info for prioritizing fixes for backporting. second, why are you suggesting that by applying not only explicitly marked security fixes one will have a 'secure system' (such a thing doesn't seem to exist)? it's not about absolutes, it's about shades of grey: by being able to prioritize known security fixes one will have a *more* secure system, simple as that.
> other people think that someone should research all possible implications
you're leaving out the most common and obvious case: when the developer already knows that a bug is security related. what does it cost then to mention it in the commit? not even a CVE is needed for that.
Kernel security, year to date Posted Sep 10, 2008 19:52 UTC (Wed) by dlang (✭ supporter ✭, #313) [Link]
if you don't want to only apply security fixes to get a secure system, why do you need the big red flag that a patch is a security fix? if you are applying all bugfixes then you will get the security fixes along with everything else.
as for the reason to not call it out, to give the good guys a chance to apply fixes before the bad guys are writing exploit code.
if it's called out as specificly being a security fix then the bad guys can start work immediatly on producing an exploit, they don't have to examine the fix to see if it is a security fix or not. yes, this is a bit of security by obscurity, but obscurity by itself isn't a bad thing, it's only when you depend on it for your only defense that it becomes a disaster.
Kernel security, year to date Posted Sep 10, 2008 20:26 UTC (Wed) by PaXTeam (subscriber, #24616) [Link]
> if you don't want to only apply security fixes to get a secure system,
what do non-security fixes have to do with the security of the system?
> why do you need the big red flag that a patch is a security fix?
why? it was in my post, read it again ;). keyword: priority. and if the security bug isn't marked as any kind of important fix whatsoever (as it is the modus operandi apparently) then how is anyone supposed to figure out that it needs to be backported? besides, what is this 'big red flag'? do you only think in extremes?
> if you are applying all bugfixes then you will get the security fixes
you're again thinking in black&white mode. what makes you think that people want all or nothing? what if sometimes one needs to prioritize and does risk evaluation before deciding on backporting and/or applying a fix?
> as for the reason to not call it out, to give the good guys a chance to
this 'argument' has been thorougly debunked back in July. the short story is that guys capable of writing exploit code do not need such marks in commit messages because they will figure it out themselves, sometimes as soon as the commit containing the security bug goes in, way before any fix can possibly reach the good guys.
it's also funny that you're assuming that by not marking a commit as a security fix, the good guys will somehow be better off in identifying it as such.
Kernel security, year to date Posted Sep 11, 2008 1:37 UTC (Thu) by eteo (guest, #36711) [Link]
> if you don't want to only apply security fixes to get a secure system,
> why do you need the big red flag that a patch is a security fix? if you > are applying all bugfixes then you will get the security fixes along with > everything else.
You wouldn't want to introduce possible instability to the system by applying other non-security fixes and enhancements.
> as for the reason to not call it out, to give the good guys a chance to
Obscurity doesn't help, and it only makes the matter worst. Have you ever thought about the possibility that the good guys could also miss applying the security fixes just because of the obscurity in the changelogs?
Kernel security, year to date Posted Sep 11, 2008 7:35 UTC (Thu) by dlang (✭ supporter ✭, #313) [Link]
>> if you don't want to only apply security fixes to get a secure system,
>> why do you need the big red flag that a patch is a security fix? if you >> are applying all bugfixes then you will get the security fixes along with >> everything else.
> You wouldn't want to introduce possible instability to the system by
and I am saying that trying to do this means that you will miss security fixes becouse at the time they were created nobody realized that they fixed security issues.
becouse of this good guys need to apply all the patches, not try to cherry-pick the ones that they think are 'important'. If they want to do so (distros for example), they need to investigate _every_ patch to see if it has security implications or not. tagging some of them as having security implications strongly implies that ones that are not tagged do not have security implications, and that is incorrect.
even if all the commit says is 'this is important for security' the fact that the details of the fix are directly attached to the comment makes it pretty easy for the bad guy to focus their exploit effort.
I think that the reduction in effort is greater for the bad guys than it is for the good guys.
Kernel security, year to date Posted Sep 11, 2008 9:37 UTC (Thu) by PaXTeam (subscriber, #24616) [Link]
> and I am saying that trying to do this means that you will miss security
> fixes becouse at the time they were created nobody realized that they > fixed security issues.
why does that imply that *known* security fixes shouldn't be marked as such? you're thinking in black&white terms again and again, and can't imagine that kernel security isn't one such thing.
> because of this good guys need to apply all the patches, not try to
no, they do not. in fact, judging by the amount of reverted commits, they're a lot better off by being careful. on the other hand i don't recall a security fix being reverted so their quality is a lot better than non-security fixes.
> If they want to do so (distros for example), they need to investigate
they have to do it regardless for non-security implications as well.
> tagging some of them as having security implications strongly implies
why does it imply that? because you say so? ;) in the real world out there, people maintaining kernels for their users are not dumb and they know that any security labeling can at most be best effort, not a guarantee.
> even if all the commit says is 'this is important for security' the fact
why do you think they *need* such explicit marks to begin investigating a commit? think about it, a known security fix is very likely to get applied/backported by the good guys (i.e., its value is reduced for the attacker) whereas an unknown one (meaning, not known as a security fix at commit time) has a much better chance of remaining unfixed elsewhere therefore the bad guys already have to manually scan every commit *anyway*. not to mention the fact that they scan commits and find exploitable bugs in them when the bugs are introduced (think vmsplice or suid coredump), not when the security bugs are fixed. therefore it's really irrelevant for the bad guys whether the security fixes are marked or not. in fact, if there's any impact for them, they're probaly very grateful for the kernel devs for not marking security fixes because that increases their chances of exploiting a bug that is more likely to remain unfixed in their target's systems.
> I think that the reduction in effort is greater for the bad guys than it
there's *zero* reduction in effort for the bad guys. if you have evidence otherwise, i'm all ears.
Kernel security, year to date Posted Sep 11, 2008 20:52 UTC (Thu) by dlang (✭ supporter ✭, #313) [Link]
I am not saying that it's inherently evil to label a security fix as such, but I am saying that it's also not inherently evil to not label a security fix.
there are very few reverted commits after a release (excluding -rc releases). If you are running a pre-release kernel then you have bigger problems, but if you stick with the released kernels (especially with the -stable releases) then there are very few reverted commits. so I don't see how that is relevant.
>> tagging some of them as having security implications strongly implies
> why does it imply that? because you say so? ;) in the real world out
you can't have it both ways. either the tagging of patches as security issues is accurate (so that you can have a secure system by only applying those patches and not applying the other fixes), or it's not (in which case you need to apply all patches to get all the possible security fixes)
> there's *zero* reduction in effort for the bad guys. if you have evidence
bad guys don't need a security park to investigate a commit, but if things have a security mark they know that they will find vulnerabilities in those commits, there is no chance that they will investigate the implications and then discover that they wasted their time.
it's like discovering that a high-security building has an unlocked door where your only communication with the building managers is public with an unknown amount of time before the owners see the message.
you can say 'door X is vunerable' in which case the bad guys can go directly to that door and get in.
or you can say 'I found a unlocked door' in which case the building owner needs to check every door (potentially finding other problems), but the bad guy would probably have to try several doors before finding the open one, and in a high-security building there would be cameras on the doors giving the building owner some chance of spotting the bad guy before they get in, even without seeing the message
I know this isn't a perfect analogy, but it does illustrate why full public exposure of all the details of every security problem is not nessasarily a good thing. with commits, the details are by definition available (the code changes are visible to everyone), so it can be a reasonable approach to not then hold up a sign that says 'target this'
Kernel security, year to date Posted Sep 12, 2008 2:28 UTC (Fri) by PaXTeam (subscriber, #24616) [Link]
> so I don't see how that is relevant.
that'd be because you carefully cut the part i quoted from you and responded to. let's see it again:
> because of this good guys need to apply all the patches, not try to
you're saying that all patches come in equal quality. if that were the case, reverts wouldn't need to occur yet they do, that was my point. then there're the regressions that may or may not result in a revert, but in any case they show that one cannot blindly backport all patches.
> you can't have it both ways. either the tagging of patches as security
what does accurate mean here? that only security issues are marked as such, and all of them at that? who has that kind of expectation? except citizens of your (non-existent) black&white world, i mean.
beyond that, why do developers mark patches that can result in, say, file system corruption? is that accurate in the sense you meant it above? hint: it's *not*, any kernel heap overflow or similar memory corruption (not to mention several other classes of security bugs) can very well result in such file system (meta)data corruption but that fact is pretty much never mentioned in a commit. yet developers don't stop let alone argue about marking file system corruption fixes as such. how do you explain that discrepancy?
> (so that you can have a secure system by only applying those patches and
again: there's no such thing as a secure system. if you believe you have one, give remote shell access to the internet and see how long it will survive, despite having all your precious patches applied. so coming back to reality, people strive for making a balance (between having an acceptable risk and having to put effort into backporting/applying patches), and marking security fixes helps that process.
> or it's not (in which case you need to apply all patches to get all the
are you saying that applying all patches (whatever that means by the way) will result in a secure system? seriously? why don't you give remote shell access to your most important personal box(es) to everyone? could it be because, horribile dictu, you don't actually consider your system (with all those patches applied) secure enough to withstand attacks?
> bad guys don't need a security park to investigate a commit, but if
did you even read what you responded to? bad guys do *not* care one whit about explicitly marked security fixes because their value is quickly diminishing (as people apply them). the real value is in bugs that either aren't fixed at all or whose fixes aren't widely known and hence not propagating as well as they could.
last but not least, since security fixes aren't marked as such because of thorough and careful examination of impact, there's a very good chance that a given bug cannot be exploited beyond DoS. that has about no value as compared to full privilege escalation bugs. so no, marking a commit as security related doesn't automatically hand anyone a full blown weaponized exploit, it takes a lot of time to reach that stage (or determine why it's not possible) and you save no time for the bad guys by not explicitly calling out attention to security fixes.
> I know this isn't a perfect analogy, but it does illustrate why full
real life analogies *never* hold up in the digital world, yours is bleeding from so many wounds that it's not even funny.
1. a high-security building has been built as such, nothing remotely similar can be said of linux. save for L4 derivatives and coyotos, i can't really think of any contemporary public effort in fact.
2. an unlocked door is trivial to (ab)use, nothing remotely similar can be said of contemporary kernel bugs. case in point, the vmsplice exploit that abused not one but two bugs actually, and the kernel devs with all their knowledge of the kernel managed to miss the second (and more important) one initially.
3. building managers' role is nothing remotely similar to that of kernel developers. builders would be a closer match, except a building will eventually be finished (because it's built to a plan) whereas the kernel never will.
that's a couple of fundamental flaws and i haven't even finished parsing your first sentence. as for what i quoted above, you have yet to explain why bad guys would target explicitly marked security fixes in the first place (i told you why they wouldn't) and why they'd be helped by those marks (i told you why they wouldn't).
Kernel security, year to date Posted Sep 12, 2008 9:23 UTC (Fri) by nix (subscriber, #2304) [Link]
Security fixes *do* introduce bugs, which do have to be fixed later: see,
e.g. ff9bc512f198eb47204f55b24c6fe3d36ed89592. But obviously this is done by fixing the bug, not by reverting the security fix!
Kernel security, year to date Posted Sep 12, 2008 9:30 UTC (Fri) by eteo (guest, #36711) [Link]
> Security fixes *do* introduce bugs, which do have to be fixed later: see,
> e.g. ff9bc512f198eb47204f55b24c6fe3d36ed89592. But obviously this is done > by fixing the bug, not by reverting the security fix!
That's for sure, and I can give you many more examples too. But the good thing about such a regression fix is that it usually mentions the commit hash that introduced the problem. This is quite different from bugs that are security-relevant, and yet have nothing related mentioned in the changelogs.
Kernel security, year to date Posted Sep 12, 2008 9:52 UTC (Fri) by nix (subscriber, #2304) [Link]
Well, there's 91b80969ba466ba4b915a4a1d03add8c297add3f and
27df6f25ff218072e0e879a96beeb398a79cdbc8 from the current stable tree. Now neither actually say the Magic Word 'security', but anyone who's using an upstream kernel who doesn't recognise that a buffer overrun is a security concern *deserves* to be broken into for utter stupidity, IMNSHO.
They don't have CVE numbers and perhaps the authors didn't even bother to
Naturally some bugs have nothing mentioned in the changelogs: not everyone
Haven't we done this whole tiresome argument before? :/
Kernel security, year to date Posted Sep 12, 2008 10:03 UTC (Fri) by eteo (guest, #36711) [Link]
> They don't have CVE numbers and perhaps the authors didn't even bother to
They have CVE names now. CVE-2008-3915 for commit 91b80969, and CVE-2008-3911 for commit 27df6f25.
> isolate the commit that introduced the problem. How terrifying, I'm sure
I don't really understand what you are trying to say.
Kernel security, year to date Posted Sep 12, 2008 10:10 UTC (Fri) by nix (subscriber, #2304) [Link]
The drumbeat here has been that security problems which aren't a)
identified as such with the magic word 'security' and b) don't have CVE numbers shouldn't even have their fixes committed in case the bad guys spot the fix (as far as I can tell). I'm trying to point out that even when they're not identified as such, it's often quite easy to identify them.
Kernel security, year to date Posted Sep 12, 2008 23:34 UTC (Fri) by bfields (subscriber, #19510) [Link] They don't have CVE numbers and perhaps the authors didn't even bother to isolate the commit that introduced the problem.09229edb68a3961db54174a2725055bd1589b4b8 and dc9a16e49dbba3dd042e6aec5d9a7929e099a89b. How terrifying, I'm sure the fix is much worse as a consequence. I don't think knowing the original commits would help much with the fixes in this particular case, but if you see any problems, speak up. I agree that including the commit id's of the original commits would have been a good idea, and I'll try to do that in the future. And if I could make a request for next time: could you please (please!) respond by email instead of lwn comments? Preferably cc'd to the relevant public lists, but if for some reason you just can't stand the idea of sending email to vger lists, then private mail will work too.
Kernel security, year to date Posted Sep 12, 2008 23:46 UTC (Fri) by nix (subscriber, #2304) [Link]
I didn't email you about this because I didn't think you'd done anything
which needed to change: you fixed a bug, and that's great. Obviously you knew these fixes had security implications because you said so, and, to me, that's enough.
(I *was* being somewhat sarcastic. Of course the fix isn't worse because
Kernel security, year to date Posted Sep 13, 2008 2:51 UTC (Sat) by bfields (subscriber, #19510) [Link] you fixed a bug, and that's great. Yeah, well, but I'm also the one that introduced the more serious of those two bugs (and failed to catch the other in review). Urgh. I *was* being somewhat sarcastic. OK! I think it's a reasonable request to include the commit id's that introduced the bugs, though.
Kernel security, year to date Posted Sep 13, 2008 3:00 UTC (Sat) by bfields (subscriber, #19510) [Link] (And, right, sorry, I see the sarcasm now. I got a little lost in the conversation there. More sleep needed!)
Kernel security, year to date Posted Sep 12, 2008 3:22 UTC (Fri) by eteo (guest, #36711) [Link]
> because of this good guys need to apply all the patches, not try to
> cherry-pick the ones that they think are 'important'. If they want to do > so (distros for example), they need to investigate _every_ patch to see > if it has security implications or not. tagging some of them as having > security implications strongly implies that ones that are not tagged do > not have security implications, and that is incorrect.
Realistically, most good guys don't do that. As I mentioned in my previous reply, applying all patches may actually introduce possible instability and/or additional security bugs to the system.
> even if all the commit says is 'this is important for security' the fact
Obscurity does not prevent the bad guys from focusing their exploit effort. It only slows them down a little. By making the commit of security-relevant bugs a little more obvious, it may actually reduce the value of these vulnerabilities.
Kernel security, year to date Posted Sep 10, 2008 22:26 UTC (Wed) by bojan (subscriber, #14302) [Link]
> as long as your mechanic fixes both, why would you care that they wereboth just single line-items in your bill?
You missed the key words: "assign the same importance".
I (and most other people) care more that the brakes work, because they are more important. And I also care more that security related bugs get fixed, because, just like with fixing brakes, failure to do so has a potential to cause more damage.
Of course, Linus and people supporting his view (that contradicts common sense) will come up with complicated philosophical reasons as to why they are right. All of that cannot change the above simple fact.
Kernel security, year to date Posted Sep 10, 2008 9:10 UTC (Wed) by nix (subscriber, #2304) [Link]
Actually, some systems (even Linux systems) have in the past used the random number sources on sound cards as a source of randomness (not terribly good sources, there's all sorts of rhythmic electrical noise in there, but still they're sources). If that's a system's only source of entropy, and an attacker makes the sound card stop working, you've now got an entropyless system. A good few things will stall forever in such circumstances -> DoS.
(Sure, it's contrived: perhaps the only thing that saves us is that the contrived part is the original setup of the system, which isn't something an attacker can easily contrapt.)
|
|||||||||||||