Slashdot Mirror
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."
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.
Linux users typically praise open source software on the basis that vulnerabilities can be found easily and patched by anybody who possesses the knowledge to do so, making open source software more secure. Why should this change now?
He doesn't believe in obfuscating changelogs, just not filling them with security information making it easy to find vulnerable kernels.
It would seem that if the vulnerability is patched in the change log, then it's fixed. I realize that some may need to run on an older kernel, but if a kernel developer found the vulnerability and fixed it, there is little way of knowing if anyone else (read black hat) has already known about it.
When single shines the triple sun, What was sundered and undone, Behold! The two made one! ~Rubbs
As long as the information is in there, isn't it part of their job to read through the changelog, read between the lines, and update appropriately? I have no mercy for the commercial groups that do their own distributions, and quite frankly, if they're going to play with the big boys, anyone who is rolling their own distribution should be put the effort into it to read the changelog for the kernel. It's not like some security hole in a fairly obscure or minor piece of software that they're having to look out for.
The article quote is completely out of context, go read the full thread and see what he really said. His main point is that security bugs are like any other bug. He doesn't see the point in putting code that can trip bugs into the git reports, whether it is a security bug or otherwise.
That said, I don't _plan_ messages or obfuscate them, so "overflow" might well be part of the message just because it simply describes the fix. So I'm not claiming that the messages can never help somebody pinpoint interesting commits to look at, I'm just also not at all interested in doing so reliably.
And from the second email:
> by 'cover up' i meant that even when you know better, you quite
> consciously do *not* report the security impact of said bugs
Yes. Because the only place I consider appropriate is the kernel changelogs, and since those get published with the sources, there is no way I can convince myself that it's a good idea to say "Hey script kiddies, try this" unless it's already very public indeed.
Also, someone is not satisfied with an email from Linus Thorwalds and he drags the discussion over here to /. - This certainly will solve the problem...
(Sorry for RTFA, I should know better)
*snort*
And I thought I'd seen every variant on the usual Slashdot in-jokes.
You win a gold star.
So, what they're saying is when you find/fix a vulnerability you should broadcast on BBC otherwise you will be less safe?
I don't think so. Love it or hate it, obscure security issues do protect some users. Obviously the issues need to tracked and I think changelogs are a good place to do it. There isn't a real reason to inform the world through all channels avaliable. Just fix it, log it, and move on. Anyone who needs to know will know where to look.
This is a an extremely one-sided presentation of this story. Linus makes some controversial but insightful points about the security obsessed culture in the community. This should not have been a "Linus has gone mad" story. This is a legitimate re-evaluation of how security patches are handled.
Read the thread, make your own decision:
http://thread.gmane.org/gmane.linux.kernel/701694/focus=706950
See the Kerneltrap posting which includes a good part of the email discussion.
It looks like Linus' main concern is that publicizing a few bugs as "security" issues will act to hide other real security issues that weren't recognized at fix time; that any effort to publicize security issues will be so incomplete as to be misleading. And I see no mention of these concerns in the linked postings, almost as if the "full disclosure" people posting them are afraid to disclose the potential bugs (which would automatically be security bugs because of the topic) in their own methodologies.
From here
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.
But won't fewer be able to take advantage of security vulnerabilities if it becomes harder to decipher changelogs? Security is not an all-or-nothing situation. The fewer people who know about a vulnerability, the fewer that can exploit it, and that means that users have a lower chance of being exploited.
That's actually an important point about security. You cannot make a useful system without any vulnerabilities. You can only maker it harder to exploit the vulnerabilities, meaning that fewer will be able to exploit them. For example, you cannot make an uncrackable and useful code, but you can make a code so hard to break that very few will even try.
What a fool believes, he sees, no wise man has the power to reason away.
In the old argument, freedom requires responsibility, this is a prime example of the conflict.
In a truly freedom based model, you assume and rely on the fact that Linux users are responsible for their systems, and thus WARNING SECURITY BUG FIX NOW is a good title to an important patch.
In the less free "sharecropper" future of Linux where user's rely on upstream vendors to "take care of them" and take no responsibility for their systems, hiding such warning is great security theater to make them feel more secure. They are not more secure, we all know, but they FEEL that they are and the kernel guys pretend to act more responsibly in this "post 9-11" fear based world.
Its all bullshit and everyone who knows anything knows it. What surprised me was Vixie just saying "patch and trust us" without explaining, with specificity, why.
When even the proponents of freedom start to fear freedom, we are in deep shit.
The more demand for commercial support, the cheaper it will become. That means that eventually the cost to support university Linux-based systems via RedHat, Novell, etc. may become cheaper than the cost of keeping people on staff to do it. The end result is that while the universities may not be doing it for themselves anymore, it's cheaper for them to focus on what they do best. After all, no one seriously argues that society is worse off today because the average car owner cannot rebuild their car like a mechanic.
http://thread.gmane.org/gmane.linux.kernel/706950
I think the OpenBSD crowd is a bunch of masturbating monkeys, in
that they make such a big deal about concentrating on security to the
point where they pretty much admit that nothing else matters to them.
http://img136.imageshack.us/img136/7451/poster68251050mx9.jpg
It is dangerous to be right when the government is wrong.
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.
And if you read about the auditing process here: http://www.openbsd.org/security.html#process
We are not so much looking for security holes, as we are looking for basic software bugs...
Shame Linus has his head stuck up his ass, or he could have read that, too.
http://cafepress.com/spankymm - for the Masturbating Monkey in you!
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
I think what pageexec (the "antagonist" in the referenced thread) was trying to say was that he feels a lot of the developers don't follow Documentation/SecurityBugs in their commits in a consistent way. He's saying that when people post commits for regular bugs, they include a decent amount of data about what they fixed, but if it's a security bug, people are posting a minimal amount in their commits. Apparently in Documentation/SecurityBugs, it says that full disclosure is the policy, but what he's seeing is less than full disclosure in practice. That is what the thread is actually about, Linus' opinions are ancillary to that point.
He's just saying that it seems to him that what is written as policy for kernel devs is not what they're actually doing, so they should either change the policy or change their commits. If the changelogs don't conform to policy, at some point somewhere downstream devs are going to miss something because the policy doesn't match the practice, and that's what's a security risk.
"so guys (meaning not only Greg but Andrew, Linus, et al.), when will you publicly explain why you're covering up security impact of bugs", pagee...@freemail.hu
"I don't cover them up", Torvalds
"by 'cover up' i meant that even when you know better, you quite consciously do *not* report the security impact of said bugs", pagee...@freemail.hu
"Yes. Because the only place I consider appropriate is the kernel changelogs, and since those get published with the sources, there is no way I can convince myself that it's a good idea to say "Hey script kiddies, try this" unless it's already very public indeed", Torvalds
"one reason I refuse to bother with the whole security circus is that I think it glorifies - and thus encourages - the wrong behavior It makes "heroes" out of security people, as if the people who don't just fix normal bugs aren't as important", Torvalds
"I refuse to have anything to even _do_ with organizations like vendor-sec that I think is a corrupt cluster-fuck of people who just want to cover their own ass", Torvalds
http://tinyurl.com/5qyon3
http://groups.google.co.uk/group/fa.linux.kernel/browse_thread/thread/5bdf2e1b8a90142c/abcf79768bb7ce7f?hl=en&lnk=st&q=#abcf79768bb7ce7f
davecb5620@gmail.com
This, in my view, is total nonsense, if you don't mand me saying so, CmdrTaco. The full source is out there for anyone to see, bugs are reported in the kernel mailing list, for anyone to see. How is this in any way shape or form 'security through obscurity'
davecb5620@gmail.com
corrected headline .. :)
davecb5620@gmail.com
The problem is the bogus presumption that there is a class of bugs called "security bugs", and that fixing these bugs is somehow more important than other bugs.
This, in turn, is based upon the PHB contempt for "hackers", and the assumption that "hackers are always changing things for no good reason"; leading to mechanisms to prevent updates from being installed in the name of "keeping the system stable." Far more harm has been caused by this PHB mindset that has ever been caused by bugs in new code.
When a developer has updates, he has already triaged them into "get into the field now" (what he releases) and "can wait a while" (what is in his development sources). What the PHBs, and sadly some ./ers, want is for the developer to do additional triaging of his release updates.
This is unreasonable. It requires the developer to anticipate the interaction of a potentially unbounded set of combinations of updates vs. non-updates. Perhaps there is no security problem with bug A, or bug B, or bug C discovered at different times; but there is a security problem if all three are unfixed. Or perhaps fixing bug C without fixing bug A months earlier introduces a security problem.
Now, with this said; the release version should always have all known critical issues (not necessarily security) fixed. Nobody should ever be made to install a "current release" with known critical issues. This means that the "current release" must be updated as needed to preserve this state.
The Redhats of the world are in the business of backporting some fixed into ancient releases in order to satisfy the PHBs. They make their money by doing that, and charge handsomely for it. I haven't heard of anyone paying Linus (nor, for that matter, most other developers) to provide that type of service. If you want such services, write your checks to Redhat. Don't expect developers to give it to you for free.
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.
"People who do stupid things with hazardous materials often die." -- Jim Davidson on alt.folklore.urban
Most of the controversy is totally misplaced. This is essentially about having
* SECUIRTY ISSUE: fix info
vs.
* fix info
Is that really obscurity?
"Thanks for all the money you paid to us. We've used it to buy off ISO among other things" -Microsoft