Slashdot Log In
Linux's Security Through Obscurity
Posted by
CmdrTaco
on Thu Jul 17, 2008 08:31 AM
from the we-all-do-it-sometimes dept.
from the we-all-do-it-sometimes dept.
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."
Related Stories
Submission: Linux's Security Through Obscurity by Anonymous Coward
This discussion has been archived.
No new comments can be posted.
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
Full
Abbreviated
Hidden
Loading... please wait.
The idealistic young become the cynical old. (Score:4, Interesting)
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. (Score:5, Funny)
Parent
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.
Parent
Re:The idealistic young become the cynical old. (Score:5, Insightful)
Parent
Re:The idealistic young become the cynical old. (Score:5, Interesting)
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.
Parent
Re:The idealistic young become the cynical old. (Score:5, Insightful)
No, there was only one openssh bug around that time, the rest were PAM/linux specific issues. And that one openssh bug had nothing to do with it being more widely adopted, it was just an ordinary "bug found in relatively new software" situation.
Parent
Re:The idealistic young become the cynical old. (Score:4, Interesting)
Parent
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!
Parent
Re:The idealistic young become the cynical old. (Score:4, Insightful)
"fixed bug #23456 overflow at line #1234 causing dumaflopper() to return incorrect result - known security problem" or
"fixed bug #23456 overflow at line #1234 causing dumaflopper() to return incorrect result - important update"
would be more appropriate IMO. Letting people know where the security fixes are is important in getting the changes widely distributed.
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.
Further, a better community understanding and acceptance of insecurity would be an even better idea. Too many people out there think "I've secured this box, I know what I'm doing, nobody can get in" when in fact there are very few such boxes out there and the real security layer being utilized is the fact that there are so many other machines out there that are easier to control. If you know you are vulnerable the mindset changes.
Example: "E-mail has lots of viruses, so I don't open up strange email. Now that I have Norton, it protects me so I open up strange email if it has a subject that draws me in." That's a mindset a lot of people have. Norton gives them the mindset they are secure, but the reality is far from that. If everyone knew how insecure they really were, less people would open up spam or virus-laden spam.
Parent
Re:The idealistic young become the cynical old. (Score:5, Insightful)
So, some random - but short, say within 3 days - amount of time later, post a message saying "security fix implemented - please update".
That will alert folks that there's a security issue without spotlighting the problem.
Parent
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.
Parent
Re:The idealistic young become the cynical old. (Score:4, Insightful)
Umm.... the schneier article is almost seven years old and discussing apparently discusses a release of the 2.2 kernel. I think the article was referenced purely as summary of security-through-obscurity issues, rather than an attack on Linus.
Parent
Re:The idealistic young become the cynical old. (Score:5, Insightful)
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.
Surely though, the people who are looking to take advantage of security vulnerabilities, are generally the ones who already have a financial motivation to do so? The people who already have their own dark networks to share or buy and sell vulnerabilities?
Won't they still do this even if it becomes harder to decipher changelogs? The only thing changing then, is that it'll take longer for regular users to see the danger.
Parent
There is no absolute security (Score:4, Insightful)
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.
Parent
Re:There is no absolute security (Score:5, Insightful)
Parent
Re:There is no absolute security (Score:5, Insightful)
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.
Two things to consider:
1) All it takes is one person to exploit your vulnerability. And that one person doesn't even have to know you exist and target you specifically. Most cases involve targets of opportunity.
2) These things don't remain secret. How fast the knowledge is spread only depends on the particulars of the situation. But the knowledge will spread. Sometimes very fast. You're unlikely to be dealing with just one potential attacker.
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.
It depends on what kind of vulnerability we're dealing with. There are known trade-offs in the design of a system and then there's failures in the design or implementation.
Security is never absolute by design. There are always trade-offs being made (inverse relationship between usability and security, investment of resources vs. value of what's being protected, etc.). Hopefully designers understand the issues and have made wise choices. But even the most well thought out system will ultimately have left some possibility of subverting it. Thus exists the concept that security is not an absolute.
Bugs and design flaws are a different issue. These are not trade-offs but unintentional mistakes or miscalculations. These are unintentional flaws. It is entirely possible to design or implement a system without flaws. But of course, designing something without flaws or implementing without bugs is difficult.
Parent
Re:The idealistic young become the cynical old. (Score:5, Insightful)
Read the replies. Linus is not advocating security through obscurity. He just doesn't want a big flashing sign "SECURITY" on security-related bugfixes. He doesn't want them to stand out in any way at all.
Parent
Re:The idealistic young become the cynical old. (Score:5, Insightful)
Parent
Re: (Score:3, Interesting)
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. (Score:5, Funny)
"Dear God, won't somebody please think of the children?"
Parent
Re:The idealistic young become the cynical old. (Score:5, Funny)
"Dear God, won't somebody please think of the children?"
Actually, as a kernel issue, this affects all the system threads.
Parent
Re:The idealistic young become the cynical old. (Score:4, Insightful)
Yeah, he thinks security bugs are just like regular bugs. But [I think] he's wrong.
There, fixed it for you. The fact is that just because from your personal point of view a bug that is potentially useful to gain unauthorized rights does not mean that everybody sees it that way.
From what I have read about Linus, he is a very pragmatic guy. For him, a security bug is just another bug in the code (and in a simplistic way, it really is true).
Some people will be more concerned with those bugs, others will be concerned with bugs that reduce the performance of the OS, others will be more interested in bugs that reduce the reliability (as in, crashing every so often, etc).
The fact is that there are lots of people already classifying bugs, I think what Linus is saying is that he does not consider the job of the kernel guys to do such kiind of classification.
For them, it is just another bug that must be seen.
Parent
Re:The idealistic young become the cynical old. (Score:5, Insightful)
Congratulations your exactly the reason Linus doesn't want a big flashing "Security" sign.
Linus' point was that most bugs can be potential security problems and if you ignore anything but security fixes you risk not patching in the case of a bug being discovered exploitable after the fix goes into the kernel.
Parent
Re:The idealistic young become the cynical old. (Score:5, Insightful)
In the same thread he also says "So as far as I'm concerned, 'disclosing' is the fixing of the bug. It's the 'look at the source' approach."
I don't see any security by obscurity going on here. He fixes the bug, and tells you in the changelog what the bug was.
What he's NOT doing is announcing in advance how to exploit the bug.
So why are so many people getting agitated about this?
Parent
Re:The idealistic young become the cynical old. (Score:4, Insightful)
What Linus IS doing trolling. Plain and simple.
There is a policy, or at least a strong convention, in place for Linux that bug fix commits should explain in a fairly detailed fashion what was the bug was and/or how it was fixed. However, most of the security fixes are vague and general.
Someone pointed this out, and first Linus said there was no "policy." Someone pointed out that, in fact, there was. Then Linus said that wasn't the point, the issue was that he didn't want script kiddies to be able to find potential exploits easily. So someone pointed out that this means that individuals and distros can't tell whether a given bugfix is urgent or not, and Linus replied that the question whether a bug is related to security or not is difficult to answer. Just to make sure that everyone knew he was trolling hard, he flamed OpenBSD for having a better security record than Linux.
It boggles my mind, the extent to which Linus is able to spew the most outrageous bullshit and Linux nutriders will buy it. He's an excellent programmer and deserving of his reputation, but the cult of hero worship that surrounds him drags down the whole community of Linux users (and by extension, Free Software in general).
Parent
What the... (Score:5, Insightful)
Re:What the... (Score:5, Insightful)
Parent
Re:What the... (Score:5, Insightful)
This has nothing to do with the openness of the source code or the disclosure of vulnerabilities. Linus just doesn't want big proof of concepts for exploits in the last version of the kernel(which there will of course be people still running) to end up in this version. He doesn't want to aid script kiddies. Anyone can still find and patch parts of the code base, there's no move away from that.
Parent
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.
Re: (Score:3, Interesting)
My theory? Linus is losing his mind, and he slips too far, we will wind up with a fork of the kernel (Ne
Re: (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 s
Re: (Score:3, Interesting)
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.
Isn't that part of their job? (Score:5, Insightful)
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.
Re:Isn't that part of their job? (Score:5, Insightful)
Parent
Re:Isn't that part of their job? (Score:4, Insightful)
If you don't have the time to perform security maintenance, but someone else does, why shouldn't they be allowed to make a profit for their time?
Parent
You make that sound like it's a bad thing (Score:4, Insightful)
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.
Parent
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.
Re:Completely out of context (Score:4, Insightful)
Agreed. The thing to note is that this cuts both ways.
*Every* bug is a potential security bug. So should we look for ways to try to convert every bug into a security notice? Of course not! Why waste the time? What happens when it turns out that a bug doesn't have security implications? Do we shout "hurray!" and flag it as such?
Linus is entirely correct - a bug is a bug and must be fixed.
Parent
Summary: Flamebait? (Score:5, Insightful)
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)
"Sorry for RTFA"? (Score:5, Funny)
*snort*
And I thought I'd seen every variant on the usual Slashdot in-jokes.
You win a gold star.
Parent
So (Score:5, Insightful)
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.
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]
Pragmatism (Score:3, Interesting)
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.
Wisdom from Ted T'so, as usual. (Score:4, Interesting)
Read this post to get some perspective:
http://article.gmane.org/gmane.linux.kernel/707044 [gmane.org]
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
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]
CmdrTaco indulges in flamebait .. (Score:5, Insightful)
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?
Re: (Score:3, Funny)
http://thread.gmane.org/gmane.linux.kernel/706950 [gmane.org]
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 [imageshack.us]