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
Wrong. sparcv9, for example, implements a non-executable user stack per default. In POSIX, all memory from the heap is pre-marked non-executable (on architectures that support page protections) unless it is explicitly set by the program to be executable (for example, in JIT compilers) using functions like mprotect(). In Windows, this is implemented as a flag passed to HeapAlloc().
The interface design and OS support is already there, what isn't is people buying non-IA32 CPUs in large numbers.
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.
You state that IIS runs on more servers than does Apache according to a netcraft study. But you do not provide a link. Any particular reason?
Here is a link that shows that Apache far outstrips IIS. As to sheer number of servers vs hosts, well, that comes down to MS requiring a number of machines to do the work of one *nix machine. And yet, sites that use multiple Windows box, typically serve one web site and only count as a single crack even though all boxes were cracked.
A far far better and more informative read IMHO is The Cathedral and The Bazaar. Beware, it's on the long side.
This gives an interesting insight into the open source model through taking over an open source project. It presents lessons learnt, and corresponding cardinal rules when running such a project. It also outlines quite effectively why open source is a viable means to develop quality software, despite the author's initial reservations. In C or C++ even.
I have been using M$ products from dos 3.3 to the present, and only in the last few years have I connected to the internerd. If the problem with M$ software was really all down to its ubiquity as a target for all the malware then you would expect that standalone pc's running M$ OS and apps would work fine. Not so. It has always been bug-filled, poorly designed and badly executed. Even the wordprocessing which has been through umpteen generations in still far from a quality product.
They whose government reduces their essential liberties for temporary security, receive neither liberty nor security.
buffer overflows are only a small part of the problem!!! Microsoft came up with some lame ass BOF protection in their service pack 2 and their propaganda dept. is trying to convince us they solved something!
Today there are still format strings, integer overflows and the BIGGEST part of the problem is default passwords, false advertising, no liability, poor application security, security product vendors, SQL injections and just plain stupidity!
Just take a look at the abstract of my speech at syscan '04 (it's at the bottom of the program page.)
Information Security in Banking: The illusion of Safety by Anthony Zboralski
This presentation will focus on ways to defeat a banks security byways of deception, taking advantage of specific subtleties in human behavior and the bank's network of trust. This session will include three real-life case studies:
Penetration testing major Asian banks; the speaker will show why most security mechanisms can give a false of safety and demonstrate how an attacker can ensure rapid ownership of the most up to date, patched and secure systems without using a single 0 day exploits.
Auditing the security of core banking systems. The speaker will give real examples of insider hacking and fraud (erasure of loan files, manipulation of interest rate and foreign exchange data, vendor tempering with production environment, ATM backdoors, bypassing AS/400 security, etc.
Finally, the speaker will present the results of his Jakarta/RI Wireless Security Survey 2003 and 2004 including disturbing screenshots of ATM transactions and multi-million dollar wire transfers which broadcasted in clear text over wireless networks without the banks knowledge.
From the FAQ:
"In no particular order, OpenVMS components are implemented using Bliss, Macro, Ada, PLI, VAX and DEC C, Fortran, UIL, VAX and Alpha SDL, Pascal, MDL, DEC C++, DCL, Message, and Document. And this is certainly not a complete list. However, the rumor is NOT true that an attempt was made to write pieces of OpenVMS in every supported language so that the Run-Time Libraries could not be unbundled. (APL, BASIC, COBOL and RPG are just some of the languages NOT represented!)"
Peter
As it goes I did - I used Visual J++ before it was even released, back in the day, and supported Microsoft's adaptations (the COM-binding ones at least) to the technology and was sad about Sun's position, which I followed closely.
Now that we've cleared that up (and F*** YOU, ignorant moderator), can I state again that BEFORE the legal dispute (which has nothing to do with this thread) there were reasons Microsoft was interested in Java over Visual C++ (which I used to develop) that continue to this day, sadly in a wholly divergent language rather than a variant implementation.
> Don't forget about Mono (open source .Net tools). The .Net CLR is an open standard. That's what the Mono folks are working off of. The only downside is that Microsoft has a huge head start in the libraries, widgets, and tools. This makes their solution much more useful (for now).
Please don't forget reading the entire post before replying, I specifically addressed the existance of mono.
At any rate...
There is the potential for patent issues with Mono, just as is the case with open source JAVA development.
Also, the original argument said that SUN was the only provider of JAVA technology while it is not. If GNU, Blackdown, IBM etc are ignored, why not ignore mono?
For completeness' sake, I was not addressing the technical argument, just pointing out that the grandparent was rather ignoring the fact that the situation with regards to choice is very similar, and the single provider issue either exists for both or neither, depending on how much you are bothered by the potential of patent issues. (and one could even argue that in case of JAVA, there are non SUN versions of it that will not have patent issues that you will get to deal with as user/developer, ie the IBM version)
In other words, technically mono is a maybe incomplete but viable alternative, but those exist and have existed for a long time for JAVA as well.
Legal status is another thing.
Now the virtual machine and its tools etc still come from one provider...
Now the Virtual Machine and its tools etc still come from one provider?
And also, don't forget about this one...
You need to restart your computer. Hold down the Power button for several seconds or press the Restart button.
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.