Linux's Security Through Obscurity 215
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."
Linus does not mean obfuscation (Score:5, Informative)
He doesn't believe in obfuscating changelogs, just not filling them with security information making it easy to find vulnerable kernels.
Completely out of context (Score:5, Informative)
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.
Two sides to this story (Score:5, Informative)
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
I just love the smell of napalm in the morning... (Score:5, Informative)
See the Kerneltrap posting [kerneltrap.org] 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.
Some context. (Score:5, Informative)
From here [seclists.org]
Re:Linus does not mean obfuscation (Score:3, Informative)
I agree.
Here's the danger of not identifying security fixes in your patch logs: If a security fix isn't clearly identified, then customers won't necessarily update it.
I run Windows at work, the IT department there has deployed its own WSUS servers. They only deploy security fixes from Microsoft on those servers (don't ask, it's stupid, but it's what they do). If Microsoft were to hide security fixes in non security updates, then our machines would remain vulnerable to those security bugs.
The theory that somehow hiding the patches will keep customers safe (or deter the hackers from figuring out the vulnerability) is totally bogus. Even though Microsoft is closed source, security researchers can reverse engineer a working exploit from the binary patches in minutes [slashdot.org].
It's important to flag security fixes as security fixes so that customers know that they need to give them higher priority.
Re:The idealistic young become the cynical old. (Score:5, Informative)
At that point, slashdot and schneier.com are just trolling. Read the whole email [kerneltrap.org] I quote above:
It's a flamebait email thread. Linus has harsh words for BSD. Nobody ever said Linus doesn't do that -- but this is not security through obscurity.
His take on security issues is simply: they're bugs. Deal with it.
Re:There is a great quote in the thread (Score:3, Informative)
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.
Missing the point (Score:5, Informative)
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.
Torvalds falsely accused of security coverup .. (Score:5, Informative)
"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 [tinyurl.com]
http://groups.google.co.uk/group/fa.linux.kernel/browse_thread/thread/5bdf2e1b8a90142c/abcf79768bb7ce7f?hl=en&lnk=st&q=#abcf79768bb7ce7f [google.co.uk]
Linus is right (Score:2, Informative)
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.
Re:The idealistic young become the cynical old. (Score:4, Informative)
Linus doesn't want "security only" fixes.. because then EVERY SINGLE OLD VERSION becomes a target...immediately!
Which is better to say:
"fixed bug #23456 overflow at line #1234 causing dumaflopper() to return incorrect result"
or
"fixed security hole #23456 -- firefox calling line #1234 with variable name = "wiggle" caused dumaflopper() to skip password check"
It's better to quietly fix the bugs, identify where they are and what you fixed.. we fixed 25 overflow errors today -- but don't tell which ones tie to a known security error.. don't make cracker's work too easy.
Many bugs are not "security" problems because nobody has figured out how to break it yet. Just because a bug does not match a security notice does not mean it couldn't be a problem after the patch is released!
Worst article this week (Score:5, Informative)
Most of the controversy is totally misplaced. This is essentially about having
* SECUIRTY ISSUE: fix info
vs.
* fix info
Is that really obscurity?