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."

What the...

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?

Re:What the...

As the userbase shifts towards more mainstream users and away from the technically abled the percentage of users to whom the "who possesses the knowledge" actually applies drops and the number who are likely to be slow updating their systems goes up.This changes the game a little. I'm a supporter of the open model but I can see where they're coming from.

Linus does not mean obfuscation

Note that the quote from Linus [marc.info] continues:

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.

He doesn't believe in obfuscating changelogs, just not filling them with security information making it easy to find vulnerable kernels.

Isn't that part of their job?

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."

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?

You say you have no mercy for commercial distributors, but the truth is that this sort of obscuration will only increase their business. Companies like Red Hat and Novell have the resources to pay people to spend all day reading through changelogs and deciding whether or not a patch is worth applying (in addition to people to are paid to submit patches). Universities may not have those resources, and their computer centers may only have enough time to quickly check a patch for common security fixes using grep. If it becomes impossible to do that, then all that we'll see is an increase in the number of people who buy support from commercial distributors, because they won't be able to support themselves.

Completely out of context

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.

Summary: Flamebait?

The summary and the linked email from Brad Spengler look very flamebait to me. Linus Thorwalds writes in the quoted mail:

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"?

*snort*

And I thought I'd seen every variant on the usual Slashdot in-jokes.

You win a gold star.

So

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

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...

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.

Looks like Brad is spinning things a bit. Further in the thread a 'Robert Peaslee' writes:

Hi Brad, Your comments are kind of misguided. Linus can be quoted as saying: "my responsibility is to do a good job. And not pander to the people who want to turn security into a media circus." He was referring to individuals such as yourself when making the circus comment, as your message was slightly alarmist and dramatized. Security is important, of course - but Linus' opinions [kerneltrap.org] are completely correct in terms of development of the Linux kernel. I would agree with you if security bugs were actually being hidden, but they aren't. They just aren't given special treatment.

From here [seclists.org]

Torvalds falsely accused of security coverup ..

"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", [e-mail]

"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", [e-mail]

"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]

Re:The idealistic young become the cynical old.

"Get off my lawn!" - Linus Torvalds

Re:The idealistic young become the cynical old.

Realistically, this article is light on the quotes of Linus because the article is trying to make a big deal out of Linus' words "I personally consider security bugs to be just 'normal bugs'. I don't cover them up, but I also don't have any reason what-so-ever to think it's a good idea to track them and announce them as something special. [kerneltrap.org]"

At that point, slashdot and schneier.com are just trolling. Read the whole email [kerneltrap.org] I quote above:

We went through this discussion a couple of weeks ago, and I had absolutely zero interest in explaining it again.

I personally don't like embargoes. I don't think they work. That means that I want to fix things asap. But that also means that there is never a time when you can "let people know", except when it's not an issue any more, at which point there is no _point_ in letting people know any more.

So I personally consider security bugs to be just "normal bugs". I don't cover them up, but I also don't have any reason what-so-ever to think it's a good idea to track them and announce them as something special.

So there is no "policy". Nor is it likely to change.

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:The idealistic young become the cynical old.

He's right - they're just bugs. Where he isn't right is about OpenBSD - security is a by-product of fixing bugs. They don't just fix the bugs, but when a new class of bug is identified the whole source tree is scanned for that type of bug - both kernel *and* user-land. But then Linux is just a kernel, isn't it?

Re:The idealistic young become the cynical old.

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.

Missing the point

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.

Re:The idealistic young become the cynical old.

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.

Re:The idealistic young become the cynical old.

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.

Re:The idealistic young become the cynical old.

Yeah, he thinks security bugs are just like regular bugs. But he's wrong. Most bugs don't bite most users--- the ones that don't can be ignored. Very few people can ignore security bugs--- they bite everyone. 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%.

Re:The idealistic young become the cynical old.

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?

"Dear God, won't somebody please think of the children?"

Re:The idealistic young become the cynical old.

"Dear God, won't somebody please think of the children?"

Actually, as a kernel issue, this affects all the system threads.

Re:The idealistic young become the cynical old.

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.

Re:The idealistic young become the cynical old.

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?