Maybe running such an old kernel is a bad idea

Posted Nov 21, 2012 3:52 UTC (Wed) by alison (subscriber, #63752)
Parent article: New Linux Rootkit Emerges (Threat Post)

One commonly hears that running "stable" releases on machines whose security is paramount is safer. I'm no expert, but I can see that running newer releases could often be better even if most security patches are backported. After all, new releases will *accidentally fix* some security problems as well as accidentally reducing them.

Maybe running such an old kernel is a bad idea

Posted Nov 21, 2012 6:42 UTC (Wed) by LightDot (guest, #73140) [Link]

New releases will also accidentally introduce completely new security problems, cause regressions, etc. I'd say that's about as likely as accidentally fixing some existing bug, if not more likely. So no advantage here.

I'm sure this argument has been repeated ad nauseam by now, I'm just too lazy to see if there is any actual research data to back up one of the views... Eh, still too lazy. Let's just leave it at empirical "if I look at what big dawgs are running, ie. Fedora or RHEL/CentOS/SL, that alone should count for something"...

Maybe running such an old kernel is a bad idea

Posted Nov 21, 2012 7:08 UTC (Wed) by Rearden (subscriber, #35172) [Link]

I've always understood the explanation for running the "stable" or LTS variant of a particular distro to be also to minimize potential breakage when updating packages in regards to other software running on the machine. That is, the stable variant isn't going to do a full version upgrade of a package without a very good reason. This makes it less likely to get yourself in a scenario where you update your server (perhaps for a security vulnerability) and then find that you're web app or some other custom coded software then breaks because your update for security also updated a library. Additionally, a stable variant typically has security-only fixes from newer versions of a package ported back into the old version of that package carried in the stable variant.

Maybe running such an old kernel is a bad idea

Posted Nov 21, 2012 10:13 UTC (Wed) by robert_s (subscriber, #42402) [Link] (6 responses)

I was considering this the other day in the context of the "safest" version of Firefox to run - deployed exploits often being adapted for a specific _build_, might the ESR version be the most economical version for attackers to target seeing as it will be in use the longest? (the answer is probably no - a relatively small percentage of people run ESR in the first place)

But I think it's more "security through obscurity" than actual "security bugs being accidentally fixed" that may help you there. Running obscure or frequently changing versions of things could give you an amount of invulnerability to opportunistic attackers toolkits of pre-built, version (and often build)-sensitive exploits.

But I think the argument for such a thing is relatively thin, as it will give you little protection against an "advanced persistent threat".

Maybe running such an old kernel is a bad idea

Posted Nov 21, 2012 15:10 UTC (Wed) by imgx64 (guest, #78590) [Link] (5 responses)

But I think it's more "security through obscurity" than actual "security bugs being accidentally fixed" that may help you there. Running obscure or frequently changing versions of things could give you an amount of invulnerability to opportunistic attackers toolkits of pre-built, version (and often build)-sensitive exploits.

"Security through obscurity" does not mean running uncommon software/software versions. It means that the security mechanisms are a "secret", as opposed to the keys of such mechanisms.

Maybe running such an old kernel is a bad idea

Posted Nov 21, 2012 15:21 UTC (Wed) by robert_s (subscriber, #42402) [Link]

No, I know that, but the approach I was describing conceptually smells of security through obscurity.

Maybe running such an old kernel is a bad idea

Posted Nov 21, 2012 15:55 UTC (Wed) by alison (subscriber, #63752) [Link] (3 responses)

What we typically term "security through obscurity" would more appropriately be termed "security through secrecy." The point that the latest release of a rapidly developed application presents a less attractive target than the version included in widely deployed LTS release is certainly correct. Cliff Stoll's book _Cuckoo's Egg_ was about how true obscurity can have an unintended protective effect. Firefox, for example, now releases frequently enough that attackers may not finding targeting the "latest stable" version worth their effort.

Moving target

Posted Nov 22, 2012 9:06 UTC (Thu) by man_ls (guest, #15091) [Link] (2 responses)

A moving target is usually of no help in this situation. As we have seen in kernel vulnerabilities, an unpatched hole in version n is likely to be carried over to n+1, so whatever attack works on one version will work on the next -- until fixed once and for all. So it is 0-day or no-day.

With stable versions, security fixes are backported from latest releases. There is an increased maintenance burden, but otherwise security should be similar. Again, 0-day or no-day. The advantage of quick releases is mostly decreased maintenance.

Moving target

Posted Nov 22, 2012 20:08 UTC (Thu) by redden0t8 (guest, #72783) [Link] (1 responses)

Except as Robert S points out, even if the vulnerability is still there, the actual exploit implementation often has to play catch-up to work on the new version.

Moving target

Posted Nov 23, 2012 9:47 UTC (Fri) by nix (subscriber, #2304) [Link]

So it helps us defend against *badly-written* rootkits? I suppose insofar as most rootkits are badly written (just as most software is badly written), that may be helpful. But it only takes one guy to come out with a well-written rootkit...