Linux's Security Through Obscurity

An anonymous reader writes "The age-old full disclosure debate has been raging again, this time in no other place than at the foundations of the open-source flagship GNU/Linux operating system: within the Linux kernel itself. It beggars belief, but even Linux creator, Linus Torvalds, has advocated against the sort of openness on which Linux has thrived, arguing that security fixes to the kernel should be obscured in changelogs, saying 'If it's not a very public security issue already, I don't want a simple "git log + grep" to help find it.' Unfortunately, it's not kernel exploit writers who need to grep the changelog in order to find kernel vulnerabilities. On the contrary, it's downstream distributors who rely on changelog information in order to decide when to patch the kernels of their distributions, in order to keep their users safe."

Comments

The idealistic young become the cynical old.

[HungryHobo]

And so the cycle continues.

The thing is that while security through obscurity is a fools game it can also hurt your users to publish exact details of the security vulnerabilities you've found in your own product before many of your users have had a chance to patch the problem.

Re:The idealistic young become the cynical old.

[dotancohen]

The chance I need a random bugfix is very small; if I don't need it, I don't want it. The chance I want a security bugfix is almost 100%.

And where will the manpower for triaging every bug for possible exploits come from? Not all security-related bugs are easily identifiable as such. And even if they were, and then they were marked as such, do you really want the changelog easily greppable by them?

Re:The idealistic young become the cynical old.

[ShibaInu]

Don't THEY have the source code, since the kernel is free? How about a simple diff? Seems to me that if a malicious programmer is bothering to grep the changelog, just looking at the code changes isn't THAT much of a stretch? If Linux is "free" as in speech, keep it that way.

Re:The idealistic young become the cynical old.

[frodo from middle ea]

The problem arises when you are using Linux in environments which must meet certain Government (SOX etc) , Industry standard (PCI etc) requirements on security. To meet these requirements you must routinely audit your systems and when you audit your systems, you need to classify security related bugs (vulnerabilities ) found, and having clearly marked security related bugs, will help these auditors/tools do a better job. May be for a kernel developer , security related bugs are on the same level as any other bugs, but for an end user of the Linux system, it will definitely be the most important bug. Otherwise how are Linux vendors supposed to create security-fix only updates ? Or do you expect every one to blindly upgrade the kernel every time a new point release comes out ?

Re:The idealistic young become the cynical old.

[gmack]

In both. There were some that were Linux only but quite a few affected OpenBSD as well.

It's not that they didn't do a good job and they clearly did a much better job than the SSH daemon they replaced it's just that the Linux distros adopting it increased it's userbase by a lot and as a side affect increased the the number of people who saw a need to look at the code.

Re:The idealistic young become the cynical old.

[Anonymous Coward]

But you can't expect the kernel developers to provide that service.
One point Linus makes is: Only a few of the security related bugs are recognized as such when fixing them. After all they got more important things to do than checking every fixed bug for possible security impacts.
From what you said you'd be installing just those fixes that have a [security] tag. So you'd keep your system open to various vulnerabilities because you figure: Not [security] -> don't need.
That's exactly what Linus wants to prevent (maybe read the discussion ;-))

regards

ac

Re:The idealistic young become the cynical old.

[gmack]

Wow you have managed to go on a complete rant while ignoring everything I said.

What do you think your CIO will say if you get rooted and your answer is "well there was a bugfix but it wasn't a known vulnerability when the patch came out so I didn't install it"?

Bugfixes are bugfixes and even in the case of security bugs you should be testing before deployment. Don't know if you need to install it? Well just read the freaking changelog and see if it affects a driver or subsystem your using. Even the Payment Card Industry standards require you to test security updates before deployment.

Even if it's not a security bug you may very well want to install the patch to avoid a possible crash when your not expecting it. Better a controlled outage than a crash at 4 am.

Re:The idealistic young become the cynical old.

[soliptic]

By hiding it, you're only protecting yourself from second rate hackers. The first rate hackers found the problem and began taking advantage of it well before the development team was aware the problem existed.

I would say by hiding the fact a bug is a security issue would only protect you from third rate hackers. If first rate ones found the problem before the devs did, second rate ones are capable of looking through all the 'innoccously' labeled bugfixes and thinking, "hmm, overflow at line #1234 is it? Let's take a look at what goes on in dumaflopper() then, perhaps it'll be useful for my evil purposes, we'll see...", tracing through the source and working out the nature of the bug and how it could be exploited (or not). Which would leave those who need it spelt out whether and how a bug is exploitable on a third tier.

(This isn't intended as a "corrective" let alone combatitive post, btw. I've noticed often on slashdot people seem to take every post that way, so I shall disclaim it's not such thing, just thinking aloud really...)

Re:The idealistic young become the cynical old.

[10101001 10101001]

Where he isn't right is about OpenBSD - security is a by-product of fixing bugs.

Security is a by-product of a philosophy of "what could go wrong and how do we prevent it proactively"? To that end, I'd say OpenBSD still has a way to go with security. While it might be hard to go through and audit tons of code, it's much harder to create the necessary* provably correct code that one can be sure things can't go wrong. But the OpenBSD philosophy doesn't seem interested in exploring such long-distance considerations, so I'd say it's in the same boat as Linux and Windows. It's just more proactive on the code auditing front.

*It's very difficult to define "necessary" in the scope of a computer system and security. What can go wrong is certainly contextual for many people, so it's quite possible that multiple proofs under multiple well-defined contexts would have to be adopted with people choosing the context best suited to them to obtain the desired security. This, of course, assumes that it's at all possible to prove enough code (I doubt all code needs to be proved) to be certain that, at least within the context of the code**, there is no security problem. AFAIK, we're still very far away from knowing if it's possible.

**The hardware can undermine your code, but you can make allowances for defects in hardware you know about. If the hardware isn't proven correct/consistent, then you will always be on shakey ground no matter how proven your code is. We're still a long ways away from even this. And something like TPM is unlikely to solve the problem.

Re:The idealistic young become the cynical old.

[mabhatter654]

so what happens when the "second rate" hacker finds a way to exploit a bug you didn't rate "security"? Now you've identified bugs, but developers don't check all bugs they catch for security problems, they just fix them. My point is that a bug is a bug, you should patch all of them and run good tests before putting it into production to prove the whole patch works rather than trying to pick and choose parts of the regularly supported patches.

Along the same line, Linus doesn't want to support "security" and "bug fix" patch sets all over the place... the whole point is to move forward... push forward and sometimes take lumps rather than supporting "half patches". Linux developers don't work that way, they patch what's in front of them when they find it. They may have found other dependent bugs when fixing security issues. To just get "security" issues is a whole different kind of work and different cycle.

Re:Linus does not mean obfuscation

[betterunixthanunix]

How is that any better? If I need to weigh security against stability, I need to know whether or not a patch fixes a major security bug on production machines or just changes obscure drivers that I don't even use. If I were to see a sudden increase in the number of attempted buffer overflows, I'm gonna want to check for known overflow attacks on the kernel and userspace programs I am administrating.

My theory? Linus is losing his mind, and he slips too far, we will wind up with a fork of the kernel (NetBSD/OpenBSD style).

Pragmatism

[jandersen]

I have never really seen Linus as a prophet, unlike some, and although I can see the sense in being as open as possible - because that gives developers a strong incentive to fix things - I can also see that it may not be completely stupid to allow developers a bit of time to try to fix a newly discovered security vulnerability. I mean, it is not as if we are talking about keeping things very secret in order to avoid doing anything about it; but most of the time, if the news about a problem isn't bellowed out in public as soon as it is discovered, it buys people just a little bit of valuable time.

Re:Linus does not mean obfuscation

[gmack]

If you want stability just stay on the current branch your on.. ex 2.6.23.x. No new features will be added only bugfixes. Need to know if you need to apply the patch? Just check the change log to see if the bug is in any subsystem you use.

Otherwise you risk someone discovering a bug is exploitable after the patch was added to the kernel.

 

Not the prophet?

[Puffy Director Pants]

But I've already started compiling a book of his wisdom and am preparing to start a church! Oh well, guess any good religion needs an enemy.

Wisdom from Ted T'so, as usual.

[Medievalist]

Read this post to get some perspective:

http://article.gmane.org/gmane.linux.kernel/707044

Linus is being blunt, as usual, and he's telling everybody what his personal policy is towards disclosure. If he finds a bug, he fixes it, and he doesn't rate security bugs as more or less important than other bugs because he's a kernel hacker, and therefore security bugs are not his sole focus in life. He doesn't use any special language to highlight or obscure security fixes in the changelog, he just describes the fix, which is what people are claiming is "security by obscurity".

From that, people looking for something to bitch about have created this kerfuffle; it is a tale told by an idiot, full of storm and fury, and signifying... nothing.(from Macbeth, 5.5)

"Shakespeare really kicks the cap off" -- James Hovenac

Bah! So much polarization

[swordgeek]

Folks, it's not an OMG!!! THEY HID THE BUG AND NOW WE'RE GOING TO DIE!!! issue.

Security through obscurity, for those who remember the olden days, meant not disclosing code, not revealing algorithms, and relying on enforced ignorance on the part of the user/exploiter.

This ain't it. The code is there. The comments are there. Anyone can find it. What Linus is talking about is failing to aid and abet hackers in their attempts. It is simply not ACTIVELY ADVERTISING exploitable code. This is something that seems remarkably sensible.

Unfortunately, anything less "open" than having a courier deliver working exploit code to hackers is labeled "security through obscurity OMFG!!!" by idiots.