Linus Torvalds is “Fed up with the ‘security circus’”
There’s been a lot of discussion on the intertubes about some comments that Linus Torvalds, the creator of Linux has made about security vulnerabilities and disclosure.Not surprisingly, there’s been a fair amount of discussion amongst the various MSFT security folks about his comments and about the comments about his comments (are those meta-comments?).
The whole thing started with a posting from Linus where he says:
Btw, and you may not like this, since you are so focused on security, 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.
He also made some (IMHO) unprofessional comments about the OpenBSD community, but I don’t think that’s relevant to my point.
Linus has followed up his initial post with an interview with Network World where he commented:
“You need to fix things early, and that requires a certain level of disclosure for the developers," Torvalds states, adding, "You also don't need to make a big production out of it."”
and
"What does the whole security labeling give you? Except for more fodder for either of the PR camps that I obviously think are both idiots pushing for their own agenda?" Torvalds says. "It just perpetrates that whole false mind-set" and is a waste of resources, he says.
As a part of our internal discussion, Crispin Cowan pointed out that Linus doesn’t issue security updates for Linux, instead the downstream distributions that contain the Linux kernel issue security fixes.
That comment was the catalyst – after he made the comment, I realized that I think I understand the meaning behind Linus’ comments.
IMHO, Linus is thinking about security bugs as an engineer. And as an engineer, he’s completely right (cue the /. trolls: “MSFT engineer thinks that Linux inventor is right about something!”).
As a software engineer, I fully understand where Linus is coming from: From a strict engineering standpoint, security bugs are no different from any other bugs, and treating them as somehow “special” denigrates other bugs. It’s only when you consider the consequences of security bugs that they become more interesting.
A non security bug can result in an unbootable system or the loss of data on the affected machine. And they can be very, very bad. But security bugs are special because they’re bugs that allow a 3rd party to mess with your system in ways that you didn’t intend.
Simply put, your customers data is at risk from security bugs in a way that normal defects aren’t. There are lots of bad people out there who would just love to exploit any security defect in your product. Security updates are more than just “PR”, they provide critical information that customers use to help determine the risk associated with taking a fix.
Every time your customer needs to update the software on their computer, they take the risk that the update will break something (that’s a large part of the reason that that MSFT takes it’s time when producing security fixes – we test the heck out of stuff to reduce the risk to our customers). But because the bad guys can use security vulnerabilities to compromise their customers data, your customers want to roll out security fixes faster than they roll out other fixes.
That’s why it’s so important to identify security fixes – your customers use this information for risk management. It’s also why Microsoft’s security bulletins carry mitigating factors that would help identify if customers are at risk. For example MS08-045 which contains a fix for CVE-2008-2257 has a mitigating factor that mentions that in Windows Server 2003 and Windows Server 2008 the enhanced security configuration mode mitigates this vulnerability. A customer can use that information to know if they will be affected by MS08-045.
But Linus’ customers aren’t the users of Linux. They are the people who package up Linux distribution. As Crispin commented, the distributions are the ones that issue the security bulletins and they’re the ones that work with their customers to ensure that the users of the distribution are kept safe.
By not clearly identifying which fixes are security related fixes, IMHO Linus does his customers a disservice – it makes the job of the distribution owner harder because they can’t report security defects to their customers. And that’s why reporting security bug fixes is so important.
Edit: cleared out some crlfs
Edit2: s/Linus/Linux/ :)
Comments
Anonymous
August 15, 2008
The comment has been removedAnonymous
August 15, 2008
The comment has been removedAnonymous
August 15, 2008
> By not clearly identifying which fixes are security related fixes, IMHO Linus does his customers a disservice... This is a little silly. The Linux kernel is not the sole responsibility of Linus Torvalds. As a Microsoft customer, I don't perceive a disservice because Steve Ballmer doesn't personally identify which fixes are security related fixes. And since Ballmer's responsibilities include marketing and investor relations, Ballmer's comments about Windows security has a greater disconnect than Linus's comments about Linux security. And I don't blame Ballmer, again, his responsibilities include marketing and investor relations. Simply put, Linus Torvalds has no ability to deny anyone information about the Linux kernel. He is not considered an expert on security issues in running Linux, by anyone. This is the second example in a week of Microsoft blogging of Microsoft engineers wagging an accusatory finger for insufficient dedication to security. http://blogs.msdn.com/sdl/archive/2008/08/14/security-is-bigger-than-finding-and-fixing-bugs.aspx This is fine. Microsoft has made very impressive gains in the whole security development life-cycle. But as a Microsoft customer who has to support 50 odd users (some odder than others), the new Microsoft security development life-cycle doesn't fill my body with the warm sensation of total bliss. I still have to deal with Internet Explorer being tightly embedded into the Microsoft OS. I would prefer it if it was not. Obviously, my concerns don't carry much weight with the Microsoft decision makers. My ability to use newer revisions of Microsoft's OS is limited by the slowest developer in the group of enterprise-critical applications I have to support. I cannot selectively patch Windows 2000 workstations, to take full advantage of security upgrades, at any price. Ranting aside, I am more interested in Microsoft engineers talking about how the experiences of Microsoft customer will be improved, than lectures to other software companies. Especially when I have demonstratively less problems and less headaches with the products from those other companies. Because I expect to be using products from all those companies.Anonymous
August 15, 2008
Leo: It should have just been Edit: Sorry.Anonymous
August 15, 2008
Manuel: Microsoft <does> call out security fixes when we distribute them. You're right that we don't disclose security fixes made as a part of the normal part of fixing bugs, but that's because nobody has the opportunity to see those security bugs - if a tree falls in the forest, did it make a noise (if a security bug is fixed but no customer will ever see the security bug was it worth mentioning)? I'm actually NOT wagging my finger at Linus (or at least that wasn't my intent). My intent was to say (a) that I understand where he's coming from and (b) point out that even though at a software engineering level security bugs are no different from any other bugs, when you step back and look at the bigger picture there are critical differences between security bugs and other defects.Anonymous
August 15, 2008
The comment has been removedAnonymous
August 15, 2008
There's one aspect of the ensuing discussion that I don't think you addressed, and which is an important yet perhaps subtle point. Basically, once you start tagging certain changes as "security fixes" it implies that other changes aren't. In reality, the usual reason some bug fixes get tagged as security fixes is because they were found by amateur, or paid, security researchers specifically looking for exploits. However, just because I am not a security researcher and I check in a random fix for some crash, that doesn't mean that the change doesn't have security implications. The way I interpreted Linus' comments, and what I agree with, is that if you care, you need to have every change potentially considered for security implications, by people who care about security, and with the understanding that the typical developer (kernel, or otherwise) probably doesn't have that mindset.Anonymous
August 15, 2008
But Linus’ customers aren’t the users of Linus. Is this another typo (aren't the users of Linux)?Anonymous
August 15, 2008
Mark: Oops, fixed.Anonymous
August 15, 2008
The comment has been removedAnonymous
August 15, 2008
"A non security bug can result in an unbootable system or the loss of data on the affected machine. And they can be very, very bad. But security bugs are special because they’re bugs that allow a 3rd party to mess with your system in ways that you didn’t intend." Some bugs can be worse, as someone pointed out in another forum last year: Some bugs can cause death. If a machine depends on an embedded system that comes with any of those famous non-warranties, that machine is unsuitable for use in hospitals, cars, airplanes, air traffic controller systems, telephone switches, etc. There are some environments where I agree that security bugs are more special than others. Those would be ordinary users' desktops, financial services companies, etc. P.S. About "and about the comments about his comments (are those meta-comments?)", this metametacomment says yes.Anonymous
August 15, 2008
Shog9: You're right, but a patch/fix is a roadmap to exploitation. It's a lot easier to reverse engineer an exploit than it is to find one from scratch. Lurene Grenier gave a fascinating talk at Bluehat where she described how she could reverse engineer a Microsoft patch and produce a weaponized exploit in under 12 hours. And she does that every single month. Btw, you'll note that the vista speech recognition bug isn't yet fixed. That's because the exploitability of that particular bug is relatively low - the various teams <i>did</i> prioritize security bugs and that one came out fairly low on the list. It's on the list, but it's not at the "we need to fix this ASAP" level.Anonymous
August 16, 2008
"Leo: It should have just been Edit: Sorry." Haha, so I was trying to find meaning in a typo? No need to apologise! I bet you've been typing "ETA" a lot lately. I find it nearly impossible to type the word "serve" without turning it into "server" (or "director" -> "directory") and I rarely even notice I've done it until I'm re-reading much later.Anonymous
August 17, 2008
"A non security bug can result in an unbootable system or the loss of data on the affected machine." I have a healthy respect for you and the MSFT SDL team and process, but I also understand that availability of resources, including data, is a key security goal. So, a bug that results in an unbootable system or the loss of data would really be a security bug. A UI bug that renders "funny" (you're font bug, for example)? Not a security bug.Anonymous
August 18, 2008
What is the difference between bug and vulnerability? In my point of view, in a production enviroment, every bug that may lead to a loss event (CID, image, $) must be considered a security incident. What do you think?Anonymous
August 18, 2008
Daniel, that's only the case if some unauthorized user can trigger the loss event. That's the thing that differentiates security bugs from other bugs - if an unauthorized user can trigger the event, it's a security bug, otherwise it's just a bug.Anonymous
August 18, 2008
"He also made some (IMHO) unprofessional comments about the OpenBSD community..." He's been working on his hobby for more than ten years. Why would he need to be professional? I don't think you could characterize many of his most quotable statements as "professional" but people very rarely take offense at them - did anyone with the Open BSD jibe?Anonymous
August 18, 2008
Dave: Actually I was offended by them. Like it or not, Linus is a public figure. Comments like his are inappropriate for a public forum.Anonymous
August 18, 2008
if an unauthorized user can trigger the event, it's a security bug, otherwise it's just a bug. I'm curious to hear an elaboration of this. System A takes information from System B. The information read from System A causes a System B to act in a certain way (which may or may not lead to leakage of data) that is unintended. Is this a security issue or just a bug?Anonymous
August 26, 2008
Tell me one case that Microsoft paid a compensation to the client because of bug/security issue that cause a data loss? I doubt there is such a case. Then why pay MS for claims on paper when the actual result is same in case of product under GPL license?Anonymous
August 26, 2008
RE <Uknown >: Tell me one case that Microsoft paid a compensation to the client because of bug/security issue that cause a data loss? IS this somehow worse than treating Security risks / bugs as though they are not a real priority. This industry is fueled by consumer needs and desires and what they are willing to pay for, not the ambitions of "Glorified Hero's". AS a consumer, I am certainly more concerned with the case where a malicious attack can cost me serious capitol. And I am glad to hear that the limited resources at Microsoft are not being squandered on the silly idea that "a bug is a bug", or that I’d rather see a font look proper on screen than prevent my bank accounts from being drained. There is, among men, a human obligation to prevent or help prevent the products and tools they manufacture from being used to exploit the unexpecting or defenseless. If a manufacturer can reduce the risk to potential victims and refuses to do so then they are guilty of gross negligence. Manufacturers who take an apathetic and indifferent stance while watching these crimes be committed are not only inhumane, but the attitude is against the very beliefs that a republic like the United States was founded on. That being that the health and welfare of the people are in the hands of those same manufacturers.Anonymous
September 03, 2008
A { COLOR: #0033cc } A:link { COLOR: #0033cc } A.local:visited { COLOR: #0033cc } A:visited { COLOR:Anonymous
September 25, 2008
The comment has been removed