Slashdot Mirror
The Lessons of Software Monoculture
digitalsurgeon writes "SD Times has a story by Jeff Duntemann where he explains the 'Software monoculture' and why Microsoft's products are known for security problems. Like many Microsoft enthusiasts he claims that it's the popularity and market share of Microsoft's products that are responsible, and he notes that the problem is largely with C/C++ and mostly because of the buffer overflow problems."
Glancing over a book called "Writing Secure Code" by Howard and LeBlanc, from the Microsoft Press and that touts the following quote on the front cover:
"Required reading at Microsoft - Bill Gates"
Makes me wonder if blaming the language is easier than the possiblity of the code being more sloppy than it should. The book recommends many ways to avoid buffer overflows and such.
There is another kind of evil which we must fear most, and that is the indifference of good men. -- Boondock Saints
From netcraft:
Apache 67.92%
Sure... Minority Product.
Author obviously isn't the most impartial of writers.
Except that the CLI doesn't solve this problem, it just makes avoidable (which it already was to begin with). A developer can still write code to do pointer arithmetic. BTW, what kind of brain damaged designer allows for pointer arithmetic in a garbage collected language?
Pointer arithmetic automatically makes the code unsafe (you actually use the 'unsafe' keyword in C#), and you have to compile it with an /unsafe switch. Resulting binaries are not verifiable by .NET, and you can prevent unsafe code from executing via code security. I can't run C# code that uses pointer arithmetic off a network share because of this.
The Lessons of Software Monoculture
by Jeff Duntemann
November 1, 2004 --
Last summer, much was made of Slate author Paul Boutin's harangue in his June 30, 2004 "Webhead" column. Boutin basically told his readers to drop Microsoft's Internet Explorer like a hot rock and move to Mozilla's Firefox, because of the increasingly nasty security holes turning up in IE. Problem is, Slate is owned by Microsoft.
Ouch.
It really has gotten that bad, and it's easy to be left with the impression that Microsoft creates lousy software, rotten with bugs that allow the black hats to break into our networks and bring the global Internet to its knees. The anti-Microsoft tomato tossers insist that if only Microsoft cleaned up its products, we'd be rid of the security holes and the black hats who thrive on them.
It's not that simple. Microsoft has some of the best programmers in the world working on its products, and books like "Writing Solid Code" from the Microsoft developer culture are seen as classics that belong on every programmer's shelf. Nonetheless, Microsoft software has bugs; all software has bugs, which is a crucial point that I'll return to later.
What we have to understand is that our current problems with Internet Explorer have less to do with bugs than with success. When a product has 90% of a huge worldwide market, there will be problems. It doesn't matter what the product is, and it matters only a little how good it is. What matters is that Internet Explorer is virtually the sole organism in an ecosystem that the world's technology industry depends on. When IE catches a cold, the networked world gets pneumonia.
This metaphor from biology is called software monoculture. Ubiquitous high-bandwidth communication has turned the world of computing from countless independent islands into a single global ecosystem. The fewer distinct organisms at work within this ecosystem, the easier it is for a bug--any bug--to become a threat to the health of the whole.
Worms and viruses that depend on these bugs replicate and travel automatically, and unless they can assume that the next system is identical (bugs and all) to the one they're leaving, they can't propagate as quickly nor do as much damage. If only one in 20 systems allowed such worms and viruses to take hold (rather than nine out of 10) it's doubtful that they could ever achieve any kind of critical mass, and would be exterminated before they got too far.
Software monoculture happens for a lot of reasons, only a few of them due to Microsoft's sales and marketing practices. In the home market, nontechnical people see safety in numbers: They want to be part of a crowd so that when something goes wrong, help will be nearby, among family, friends, or a local user group.
In corporate IT, monoculture happens because IT doesn't want to support diversity in a software ecosystem. Supporting multiple technologies costs way more than supporting only one, so IT prefers to pick a technology and force its use everywhere. Both of these issues are the result of free choices made for valid reasons. Monoculture is the result of genuine needs. Technological diversity may be good, but it costs, in dollars and in effort.
As if that weren't bad enough, there is another kind of software monoculture haunting us, far below the level of individual products--down, in fact, at the level of the bugs themselves.
If you give reports of recently discovered security holes in all major products (not merely Microsoft's) a very close read, you'll find a peculiar similarity in the bugs themselves. Most of them are "buffer overflow exploits," and these are almost entirely due to the shortcomings of a single programming language: C/C++. (C and C++, are really the same language at the core, where these sorts of bugs happen.) Virtually all software written in the United States is written in C/C++. This includes both Windows and Linux, IE and Firefox. A recent exploit turned up in Firefox that was almost identical to one
C/C++ as a language has bugs.
Actually, any program has bugs.
IE and Firefox are both programs written in C/C++.
Therefore,
1. What is wrong with IE is wrong with Firefox
2. The quality of coding is mostly irrelevant to the quality of a program, it being mostly dependent (inversely) on how many people use it.
3. If Firefox gains market share, it will have bugs! It has to! You'll see!!
Listen to little brother crying...
I don't want to read
It seems to be a fundamental battle between speed versus protection. As time goes on and processors get faster, then things should shift toward the protection side.
However, some applications, such as games, may still require being close-to-the-metal in order to get competative speed. Game buyers may not know about extra protection, but they will balk at speed issues. Thus, it still may be better business for some industries to choose speed over safety.
However, if the option for such exposure is avialable, then viruses and other malware may still be able to take advantage of it somehow. The trick is to find a way to allow speed-intensive apps without creating back-doors. Maybe have a toggle switch on the front of the CPU box with two settings:
* Speed
* Safety
Just an idea (that probably needs work).
Table-ized A.I.
The same old canard is being recycled again here... if only OS X, GNU/Linux, et al were more popular, they'd be plagued by security holes just like Windows. Anybody who's thought about this for more than ten seconds knows this is crap for a single reason: not all software coded in the same language (C-ish variants, in this case) is created equally. Some software is just designed badly.
Just as a f'rinstance, here are three aspects of Windows that show just how much design, not installed base, drives vulnerabilities:
None of these issues have anything to do with the language they were coded in. For that matter, they could have been done in .NET. But they do help explain how certain design choices have helped create the Windows Security Pandemic. That monoculture's one hell of a petri dish.
My point here is not to trumpet the marvelous advantages of OS X (or, say, Linux) over Windows. It is simply this: there is no Law that says that the number of vulnerabilities automatically increases with popularity but without regard to design. "Duntemann's Assertion" (aka Ballmer's Baked Wind) ain't like Moore's Law.
The parent post is NOT saying that you can "design away bugs". In fact, the parent specifically says that bugs cannot be eliminated. The idea is to contain bugs and malicious code so that they can do a minimum of damage.
I can download a malicious or buggy Java applet through a web page. The amount of damage it can do is minimal since it has to ask permission to access my system and it runs in a user-level managed environment.
If I download a malicious or buggy Windows executable and run it then I am basically screwed. By default Windows provides no containment for native code. An application can erase my hard drive or crash my OS.