A nasty local kernel vulnerability

Posted Feb 27, 2013 20:46 UTC (Wed) by khim (subscriber, #9252) [Link]

i suggest you look up that word, it doesn't mean what you think it does (hint: it'd apply to us if we expected others to care about security whereas we wouldn't care at the same time, i think even you admitted that that's not the case ;).

It's absolutely the case. Do you know or care who and how produces electric power for your home? Do you know or care abut who and how pumps water? Do you know and care about all the food sources (and all the chemicals used in this process) ? Or do you pick one narrow form of security (IT-related stuff) and assume all other forms of security are somehow less important? Why do you think it's more important and why do you think other should care about GMO less then they care about out-of-bounds access in the Linux kernel?

Posted Feb 27, 2013 21:55 UTC (Wed) by khim (subscriber, #9252) [Link]

And now for some meat.

him, if you don't understand a topic, can you please stay out of discussing it, never mind giving out advices to the laymen?

Well, that's exactly your problem: as someone who's working on security solutions (although not on Linux-kernel related security solutions) I do understand the topic. At least I understand it well enough to expose your "snake oil salesmen" pitch.

i wrote about this before in this very thread but let me repeat it: your kernel is *not* exploitable because someone posts a working exploit to the public! your kernel is vulnerable because it has an exploitable bug! can you digest that?

Of course I can! It's truth, nothing except truth, the only problem: it's useless truth!

In the absence of "black hats" even bazillion security holes in your system don't matter: there are noone to exploit them. Easy enough to digest. Also easy to understand that this is unrealistic case: we do know that "black hats" dwell out there.

Ok, what about another case: all-knowledgeable adversary. In this case, obviously, upgrade is also entirely useless: you replace one vulnerable kernel with another also vulnerable kernel (all kernels till now had a security bugs and there are nothing to suggest that anyone here have 100% security-bug-free Linux kernel).

Ah-ha. So now we see that the only case where all these security patches and disruptions ever make sense lies in the world where we do have an adversary but where said adversary does not posses an omniscience.

Which basically means that "what knowledge potential attackers have about exploit" is the most important, central question for the layman. It may be pretty murky at times (the only case where answer is 100% clear is when you can say something like "I've personally added this exploit to dozen of rootkit sets which are sold on blackmarket" — and for some reason people don't like to say so even if that's exactly what they did), but it's vital.

Now, situation like this one ("I don't know if this exploit is in rootkits by now or not, but all the ingredients are publicly known thus we can expect it can be exploited soon") is not that much better, but it's still better: you know that probably only expensive rootkit can exploit this vulnerability on custom kernels while cheap ones will only target few popular distributions.

If someone wants to rush to upgrade or not because there are pretty easy to use vulnerability depends on the exact circumstances, but to say "please take it on faith that you should not care because you see an exploit in the wild, you should care because there is an exploitable bug in your system, don't wait with the upgrade till an exploit appears" is exactly to "cry wolf" needlessly. Not all security bugs are equally dangerous (although there are bias: bugs which are obviously high-priority are easy to exploit but from time to time people invent clever ways to exploit bugs which look hard to exploit at first glance) and you do know that most likely both old kernel and upgraded one have exploitable security holes. Thus you need to know what makes this particular bug easy (or hard) to exploit and — more importantly for the layman — how easy (or hard) is it to exploit in reality.

So now back to the question:

do you understand that testing your system this way would only give you a false sense of security?

I understand that now, but it's not at all obvious from the source of the presented exploit. You either need to dig deeper (to try to understand how exploit works and then study the relevant kernel sources) or you need more context (if someone who wrote exploit says that "it's pretty easy to add support for custom kernels — 10 minutes, may be couple of hours if System.map is not present" then it's one thing, if it's "we needed to run this kernel for hours under an emulator to find this offsets" then it's quite different thing).

And I'm ready to admit: you have explained the situation here, that's true — but it was done after some snide remarks which don't enlighten the situation at all. These were entirely unnecessary.