The Lessons of Software Monoculture 585
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."
managed code (Score:3, Interesting)
Not just C/C++ (Score:4, Interesting)
Unlike interpreted languages which for the most part implement all code as either line-by-line interpretation or in bytecode form, compiled languages talk directly to the CPU. Interpreted environments have the additional benefit that they run inside of a sandbox that is abstracted from the hardware by some large degree. Because of this, the running code never actually touches the CPU directly.
Things like the "no-execute" bit on modern CPUs provide an additional layer of security and prevent purposely damaged code from running directly on the CPU. However, until operating systems implement this in their own code, any application that does not want to adhere to the no-exec flag does not have to. This is like flock on Unix which only sets a file locking flag which applications are expected to obey rather than true file locking as implemented on other systems.
Re:Blaming the language... (Score:1, Interesting)
Then any apps that make requests through this kernel get the security benefits.
Re:Sometimes you gotta take a look around. (Score:3, Interesting)
On a somewhat larger scale, within companies you may replace one box with another (running another OS), but you cannot change your complete infrastructure overnight, i.e. replace all network protocols at once. Such changes take years and are a slow and evolutionary process.
Sometimes you have to take a step back and throw away some old cruft and make it fresh and new. However a certain degree of both evolution and also monoculture is unavoidable. If you have a 10000 employee company throwing in new technologies all the time, allowing for too much heterogenity, you shall have a maintenance and system-management nightmare very soon, leading to collapse of your IT infrastructure.
Re:Not just C/C++ (Score:4, Interesting)
Any self-respecting language will produce a binary that does what the source code says it should do, in exact detail. As for complexity or how much detail you get in that control, depends on the language. C and C++ are languages that give you some of the strongest control. Unfortunately, this amount of control can get you to hang yourself if you aren't careful. Use the best language for the problem. (they aren't all the same.) Protected memory CPUs can provide every bit as much protection for the rest of the system as a VM can; it's hardware VM support for memory. That's the point of protected memory. Also, many VMs provide a on-demand compiler that produces native code so the program can execute directly on the CPU because it's faster. Any limits imposed on the language's environment can be done without a VM.
Also, user-mode processes never talk to any hardware but the CPU and memory, as allocated by the OS.
The IBM AS/400 has no protected memory and does not need VMs to provide system security because there are only two ways to get binary code onto the system: 1. From a trusted source or 2. from a trusted compiler that only produces code that adheres to security regulations. The no-execute bit provides hardware negation of a certain type of attack. It does not protect against corruption of program memory, which can lead to crashes and other types of vulns. Yes, like many things, it only works effectively when it's used correctly. The most common form of buffer overrun that can lead to code execution is on the stack. Unless the compiler (or the assembly) produces code that needs the stack to be executable, the operating system can safely mark all thread stacks as no-execute. Although you can move the stack to some private section of memory, the OS is usually aware of where the thread's stack is because it's needed to start the thread and it isn't normally moved. XPSP2 in Windows does this for all threads in system service processes by default when the NX bit is supported, or programs not on a blacklist upon request.
Re:managed code (Score:3, Interesting)
One major disadvantage is that performance will take a hit. Now, if u make drivers
And one more thing, managed code is fine but not having the old samples/examples updated with the new managed code is annoying. An example of this can be seen in the Oct. 2004 update for the DirectX 9.0 SDK; the C# examples use the older deprecated code which has no wrapper classes (and thus will get a compile error). (A way to workaround this is to use the older Summer 2004 or older DLL's as the reference instead of the new ones...but then that begs the question; why bother with Oct. 2004?)
I'm Not Sure Anyone Knows (Score:4, Interesting)
My guess is, and since I do not work at Microsoft or know their culture first hand, is they are a bloated, over managed institution that provides a fertile breeding ground for errors to compound. It's like NASA in some respects, where you just have too many layers of accountability which allows many things to slip through the cracks.
I'm not sure it's fair to blame the programming languages used for errors. Bad code is often proclaimed as a major short coming of C++, but in the end it comes down to the design, programming and process. Many very large and successful software projects have been constructed using C/C++, so I find it a lame excuse to blame the language.
One big problem that many agree on is in the case of Microsoft there is a large market pressure to release things before they are ready. This allows you to get your product out to customers who will then be less likely to use a computers product, even if superior, but released later. Everyone knows the price of bug fixes goes up after the software is released, but I'm sure the mathematicians at companies like Microsoft have calculated the bug cost to profit ratio in releasing the software in particular states and the most profitable option is taken, regardless of acceptance.
I would be interested in knowing what Microsoft's error to lines of code ratio is. Larger than typical, smaller? I mean, Microsoft apparently has really good talent working for them. You would imagine they would produce really good software. What gives?
I Know The Real Cause (Score:3, Interesting)
This is the very reason we have antitrust laws. Face it, Microsoft doesn't have to make quality software because they own everything. They won't strive to make error resistant software until they are forced to.
The best part is, everyone has to pay for this through tech departments, maintenance, paid updates and general time spent fixing things as well as data loss, etc,..except Microsoft.
A relevant quote (Score:5, Interesting)
Re:IIS vs. Apache? (Score:3, Interesting)
IIS runs on about 50% of the physical servers out there.
Further, IIS can be run as a non adminstrator as well, and defaults to this configuration in IIS6, which, btw, has only had 1 moderate vulnerability in it's > 1 year on the market.
Focus on features (Score:5, Interesting)
It would not.
There are several reasons, but the biggest one is that Microsoft added some major features without ever considering the security implications. IE can install software on your system; this means you can use IE to implement Windows Update, which is kind of cool, but it also means that an exploit can use IE to put worms and viruses on your system. Firefox and the other web browsers do not have special permission from the OS to install things. In short, Microsoft spent a great deal of time and effort to tangle IE into the system, and that means that compromising IE compromises the system.
Microsoft was well served, for years, by a focus on features. Word 2.0 could be Word 1.0 plus a hundred new features; no need to redesign, just paste the features on top. As long as the applications ran on unconnected computers, this wasn't particularly a problem. Then as networking became more important, they still got away with it because a corporate intranet is still a pretty tame environment.
But now Microsoft software is out in the wild and wooly Internet and it isn't pretty. Features that were harmless or even useful in a private corporate intranet became big problems: apps that auto-execute scripts; the "Windows popup" service; remote execution; file sharing; dozens to hundreds of features, little and big, that were pasted on without any worrying about security.
Microsoft employs tens of thousands of smart people. They will improve their software, eventually. They need to start designing security in, and they need to give their developers and testers time to get the security really right, rather than trying to patch all the holes after release.
P.S. I think that another reason the free software is usually better designed falls out from the fact that free software is usually the work of small teams. Microsoft can write big specs and then have large teams go to work on them; if the teams aren't careful, their work can be a tangled mess. The free software projects tend to have clean, modular interfaces; this is partly because so often different pieces are coded up by people who don't even know each other. Also, the free software community values good design and good code, while Microsoft values features developed and shipped on time. (Good design and good code help the features to work and to ship on time, but for Microsoft the shipping is what is important.)
steveha
MonoCulture (Score:2, Interesting)
Re:I would agree with TFA if not for one thing.... (Score:2, Interesting)
Apache: the minority product? (Score:2, Interesting)
Better Compilers (Score:4, Interesting)
Comment removed (Score:5, Interesting)
Re:odd ideas about programming (Score:3, Interesting)
What I find lacking in this whole discussion is that nobody seems to run their code through lint or splint.
I think that would narrow down a whole lot of errors.
Re:Not C#, integration (Score:1, Interesting)
Re:Blaming the language... (Score:3, Interesting)
In this particular case, doubly so. It fits just nicely with another "feature" of theirs, namely the ability of a user to erase all traces of themselves. You see, in the old system, users and records were never deleted, they were just flagged as deactivated. In their system, deleting a user, did just that: deleted the record. And because of foreign keys, it cascaded through all tables and erased _all_ records related in any way. Suddenly that user... has never existed, never posted anything and generally was figment of everyone else's imagination.
However... in this case if they weren't utterly incompetent monkeys, they were damn good at faking it. There were a ton of other bugs and issues for which it's hard to find a malice-based explanation.
Stuff like that they couldn't parse the phone numbers in the existing database, so they literally requested that some bugger edits a few hundreds of thousands of records per hand to match their format. (And if you think requesting that is idiotic, let's just say a PHB actually approved it. How idiotic is that?)
Try as I might, I'd be hard pressed to imagine what devilishly clever advantage they'd get out of that. What clever back door can be gained by having one poor soul go manually through that mountain of data? It's just stupid.
Or whereas the system they were replacing ran comfortably on one PC in Tomcat, their architecture needed a _ludicrious_ server farm to support the same load. Think: literally dozens of computers. Took many hours just to start or stop the behemoth.
Again, I'm not sure what devilishly clever 0wnage would result from writing piss-poor unperformant code. Were they planning to DDOS it into submission later? Not much point in that, when you can already make yourself the highest ranking admin and cause more trouble.
So on the whole, dunno, I have no trouble whatsoever assuming that they were, simply put, too stupid for those exploits to have been planned. In fact so stupid that if they had tried to code a back door, it would have probably been too buggy to work.
Re:You need LESS involvement, not more (Score:3, Interesting)
Two words for you: False positives.
It's bad enough when an AV scanner accidently triggers and displays a message about a valid program. It would really drive people nuts if it kept immediately deleting valid programs as soon as they were installed...
Okay okay, I Read the F Article... (Score:4, Interesting)
The writer's attitude about software is simply all wrong and too tollerant.
Statements like "all software has bugs" is utterly ridiculous! There is software out there whose claim to fame is being bug-free/exploit free and continually strive to keep it that way. (Think Qmail and the same group's DNS solution.) Further, if it's possible that a program that can acquire a user's input and then print it all over the screen (think back to the says of BASIC: INPUT "Enter your name", A$
And I don't think that blaming the programming language is the right answer either. C/C++ are not inherently insecure languages. Can secure and safe code be written in these languages? Hell yeah. That would be like saying the French are rude because they speak French. Ridiculous. What is the author's intent in writing this article? I have to wonder...
"...software monoculture isn't good but it isn't bad... it's just the way it is so accept it. It's the programming language's fault not the company or the people who use it..." Can these messages possibly be true?
Regarding the "Popularity" arguemnt (Score:0, Interesting)
Others say bollocks to this and wheel out their poster-child, Apache, to refute this.
I say that it is a combination of three things, in this order:
1. Hatred of MS by so many programmers, network administrators, script kiddies, etc.
This is #1. Don't fool yourself into thinking otherwise. There are people who literally spend all their free time searching for ways to damage MS's software and/or reputation. (I know a few of them personally, as I'm sure you do.) There are companies who's biggest aspiration is to be the subject of an AP story regarding some new MS flaw that they discovered. Did you know there are even websites out there that are totally consumed with hating MS? They insert editorial comments in every MS story, good or bad, and don't treat security vulnerabilites or similar bad news about other platforms the same way.
2. Popularity.
I can show you a dozen programs that are trivially compromised. No one cares to though; because no one is using those programs. Rant about it if you will, but we all know that Popularity plays an important role here. e.g. Script kiddies want to control the most systems of the other kiddies on IRC. Most of the other kiddies are using Windows. You do the math.
3. MS not valuing security above features and/or rapid upgrades.
Arguably, this naive outlook has now changed with MS's security initiatives, the success of XP SP2, etc.
I beleive that all 3 of these things work in tandem to produce the sorry state of MS software security that we have today. (improving though, ever so slowly).
This is well understood to be bullshit (Score:2, Interesting)
Its interesting to see that people still cling to the dead idea that you can design perfection up front if you spend enough time doing it, even though there is very little evidence to support this and mountains of evidence against it.
Misses the big point (Score:3, Interesting)
The idea is to NOT have a monoculture. To have an environment where there are *many* competing platforms and applications, and (becuase they all comply with certain published standards for file and network data formats) any individual (person or business) can choose from among many alternatives, and still be able to communicate with and send and receive data to/from individuals who chose something else.
*Eliminate* the monoculture. The solution is not for MS to fix its bugs. The solution is for MS to not have a monopoly (wether they jump or are pushed)
MS biggest fear is that once they are a monopoly, they will lose *all* market share (and to be honest, IMNSHO, rightfully so, their stuff is crap). MS is desperately afraid of having to compete on the technical merits of their products. Its something they never had to do before.
Re:C# was created because of business politics (Score:3, Interesting)