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."
I thought that's why Microsoft was pushing for "managed code" with the .Net framework. Though I think it's some what ripping the idea(s) from Sun's Java. But I'm sure even with .Net, there will still be buffer overflows. Well...the GDI+ exploit is one prime example of that fact.
An interesting distinction to make is that .NET code itself isn't vulnerable to buffer overflows. GDI+ is an unmanaged component (likely written in C++), and is vulnerable. The problem is that .NET exposes GDI+ functionality through its graphics classes, and since those classes are part of the .NET framework, .NET itself essentially becomes vulnerable to buffer overflows.
Microsoft appears to be shifting its APIs to the managed world, either as wrappers to legacy APIs, or new APIs built completely in the .NET world (or both as is the case with WinFX). So to expand on your post, as long as legacy code is used, yeah, buffer overflows will still be possible, but by shifting more code to managed world the likelihood of such vulnerabilities will hopefully diminish.
That's kind of like ending up with a "null pointer" eh?
http://www.rootstrikers.org/
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
Obviously it's all the fault of C++... because no other vendor but Microsoft uses this obscure and arcane language...
It's odd to refute specific points of the article when its basic premise is flawed, but the one that applies is "all software has bugs". This is a defeatest attitude that is contradicted by the existence of formal methods for proving a piece of software to be bug free, and even of automatic theroem provers for showing software to be bug free (such as ACL2). This is the part that I was complaining about, and it is fair to criticise that without having to go into the finer points of the rest of the article.
To further expound on my original complaint, the article argues that microsoft's bad reputation is due to the popularity of its software, but this is only valid if it is impossible to make software better than Microsoft. The article seems to lean this way by stating that Microsoft has some of the smartest developers around working for it, but having the smartest developers doesn't mean that it produces the best code. Microsoft has earned its bad reputation by allowing so many bugs into such critical software like an Operating System.
The problem is that nobody writes perfect code.
Yes, we're all nerds, and we're all arrogant. We all like to act as if _our_ code is perfect, while everyone else is a clueless monkey writing bad code. _Our_ bugs are few and minor, if they exist at all, while theirs are unforgivable and should warrant a death sentence. Or at the very least kicking out of the job and if possible out of the industry altogether.
The truth however is that there's an average number of bugs per thousand lines of code, and in spite of all the best practices and cool languages it's been actually _increasing_ lately.
Partially because problems get larger and larger, increasing internal communication problems and making it harder to keep in mind what every function call does. ("Oh? You mean _I_ was supposed to call that parameter's range before passing it to you?")
This becomes even more so when some unfortunate soul has to maintain someone else's mountain of code. They're never even given the time to learn what everything does and where it is, but are supposed to make changes until yesterday if possible. It's damn easy to miss something, like that extra parameter being a buffer length, except it was calculated somewhere else. Or even hard-coded because the original coder assumed that "highMagic(buf, '/:.', someData, 80)" should be obvious for everyone.
And partially because of the increassing aggressiveness of snake oil salesmen. Every year more and more baroque frameworks are sold, which are supposed to make even untrained monkeys able to write secure performant code. They don't. But clueless PHBs and beancounters buy them, and then actually hire untrained monkeys because they're cheap. And code quality shows it.
But either way, everyone has their own X bugs per 1000 lines of code, after testing and debugging. You may be the greatest coder to ever walk the Earth, and you'll still have your X. It might be smaller than someone else's X, but it exists.
And when you have a mountain of code of a few tens of _millions_ of lines of code, even if you had God's own coding practices and review practices, and got that X down to 0.1 errors per 1000 lines of code... it still will mean some thousands of bugs lurking in there.
A polar bear is a cartesian bear after a coordinate transform.
Methodology matters.
I would agree with TFA if the author were comparing Internet Explorer 4 with, let's say, Netscape 6 or Opera 7. If he were, then I would whole-heartedly agree that IE is a victim of its own popularity and that software monocolture is an "evolutionary" reality mirrored in biological systems.
But...
There is a difference between how IE code gets written and how Mozilla code gets written. I'm not going to make any asinine qualitative comparisons between the skills of Mozilla contributors and MS staff (I respect both), but let's face it....
YOU know the difference between writing a commercial product with an unrealistic deadline, a list of new features four pages long (most of which are crap) and under the direction of non-technical managers who like Gantt charts and daily productivity reports and writing a project for your own self-satisfaction.
Mozilla code is written incrementally, with the goal of quality in mind, under public scrutiny (no peer review beats public scrutiny) and many of the contributors are doing it because they want to do it and want to do a good job. It's their pet project.
Compare the quality of code you write for work or in college under strict deadlines, and the code you write for fun.
- How many alternatives algorithms do you go through with each?
- Do you settle for "good enough" when you are writing code for yourself?
- Are you doing your own corner-case QA as well as you could be when you make that check-in into the company CVS when you know that QA will most likely test it (as an intern, I used to share a desk with QA guys, the catch is that they love to cut corners).
Not to mention endemic problems with large corporate projects of any type: corporate pride which prevents people from going back on bad decisions (ActiveX and IE security zones), lack of management support (how many top coders are still actively developing IE? any?), and all kinds of office politics. Many of these are avoided with well managed open source projects.
Cheers,
AC
BTW, what kind of brain damaged designer allows for pointer arithmetic in a garbage collected language?
Umm, one who knows that it is required for proper interoperability with existing libraries? One who knows more about language design than you?
The CLI actually isn't a "garbage collected language". First, it isn't a language - it is a language infrastructure (the LI in CLI). Second, garbage collection is available to the languages, but not required. It is a complete virtual machine, and straight C/C++ ports just fine to it, including all the buffer overruns.
However, there is a convention for "safe" programming. If you follow the convention, the assembly loader can verify that there are no buffer overruns or similar problems in your program. The price you pay is access to low-level constructs such as pointers, since their use cannot be verified.
Loading assemblies with unverifiable code is a privilege, which allows security to be maintained.
I think it all boils down to: the decision was the right one, it was well implemented, so stop talking about stuff you know nothing about.
It makes no sense to choose the option of continually hacking at a program until it works as opposed to properly designing it from the start.
There is something to this, I guess. But that's the real trick, isn't it? The problem is that real life isn't like programming class in college.
In class you get an assignment like "write a program that sorts text lines using the quicksort algorithm." This simple statment is a pretty solid specification; it tells you everything you need to know about how to solve the problem. How many features does this project have? As described, exactly one. You might get fancy and add a case-insensitive flag; that's another feature.
In real life, you get a general description of a project, but the project implies dozens to hundreds of features. Your users may not even know exactly what they want. "Make something like the old system, but easier to use." You might spend a great deal of time designing some elaborate system, and then when the users actually see it they might send you back to the drawing board.
So the best approach is generally to try stuff. You might make a demo system that shows how your design will work, and try that out without writing any code. But you might also code up a minimal system that solves some useful subset of the problem, and test that on the users.
Another shining feature of the "useful subset" approach to a project is that if something suddenly changes, and instead of having another month on the project you suddenly have two days, you can ship what you have and it's better than nothing. As I read in an old programming textbook, 80% of the problem solved now is better than 100% of the problem solved six months from now.
Note that even if you are starting with a subset and evolving it towards a finished version, you still need to pay attention to the design of your program. For example, if you can design a clean interface between a "front end" (user interface) and a "back end" (the engine that does the work), then if the users demand a complete overhaul of the UI, it won't take nearly as long as if you had coded up a tangled mess.
One only has to compare the security woes of Microsoft or Linux with the rock-solid experience of OpenBSD for an example.
I'm not sure this is the best example you could have chosen. Linux and *BSD build on the UNIX tradition, and UNIX has had decades of incremental improvements. Some bored students in a computer lab figure out a way to crash the system; oops, fix that. After a few years of that, you hammer out the worst bugs.
But UNIX did start with a decent design, much more secure than the Windows design. Windows was designed for single users who always have admin privileges over the entire computer; it has proven to be impossible to retrofit Windows to make it as secure as it should have been all along. The Microsoft guys would have done well to have studied UNIX a bit more, and implemented some of the security features (even if the initial implementation were little more than a stub). As Henry Spencer said, "Those who do not understand UNIX are compelled to reinvent it. Poorly."
steveha
lf(1): it's like ls(1) but sorts filenames by extension, tersely
His argument, spelled out, seems to be:
Personally I find this argument to be quite baseless, and I'll believe it when I see it. Even if he is correct and Firefox might have as many bugs (because hey, it's written in C/C++), he doesn't seem to've provided any logical reasoning for people who are about to move to change their mind.
Even Jeff Duntemann admits that MSIE supposedly has at least as many bugs are Firefox. Given this reasoning, there's the choice between deploying MSIE (which is proven over and over again to be unsafe and full of security holes), and Firefox (for which nothing is proven).
It seems very shallow --- he's pitting something proven versus something unproven, and essentially claiming that we should assume they're both identically bad. I'll take my chances with Firefox, thank you very much. If everyone flocks to Firefox and it suddenly becomes a big security risk, I'll deal with it at the time.
The real problem isn't C bufferoverflows. It's Microsofts ultra-agressive stragetegy to purge every single piece of non-Microsoft software from the marked. During the browser wars, Microsofts one single aim was add more and more features to IE. Security, if at all, didn't matter a lot. What was important was to get another release as soon as possible. As long as Microsoft maintains it's hostile strategy, it will never produce any piece of software that can be considered safe. Not even if they'd switch to managed code entirely.
"A poor workman blames his tools"
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.
In theory you are right, and better tools already exist. E.g., Java has array bounds checking by language definition. E.g., dunno abound Microsoft Visual C++, but I've used C compilers before which could generate code with array bounds checking. (TopSpeed C, for example.) It didn't even require any IDE macros, it just plain and simple generated them in the code automatically, if told to.
The problem however is that, well, no language or library ever can force you to stop making mistakes.
E.g., Java does throw an Exception if you try to overflow a buffer, but that's not an automatic magic talisman against bugs. You still can't let any ex-burger-flipper loose on the keyboard and say "nah, they can't have bugs or security problems. The language won't let them." What happens in practice is that:
1. People catch the exception and ignore it, on account that "it can't happen." Or even write "catch (Throwable t) {}" blocks. (Catch anything whatsoever and ignore without as much as a line in the log.)
2. Which in turn can make the program malfunction in more subtle ways. Even if you don't ignore exceptions is forgetting that the exception may have skipped some code. E.g., closing files or database handles is the most benign, in that it just causes the program to eventually run out of resources and crash.
A less benign case is when the code skipped was, for example, the login authentication. Carefully malformed data might not execute random code, but allow the user to escallate their rights to super-user.
And while a buffer overflow might have turned your machine into a spam zombie, this will instead give them all your business data on a silver platter. Nicely formatted, indexed and searchable too. And allow them to change it too.
3. In a twisted way, a secure language is the worst language because it causes complacency. Yes, it's a bit of an exaggeration, but bear with me while I make a point. Thinking "nah, we're secure because we use Java" (or SSL, or whatever) is the arch-nemesis of security. That way lies madness and skipping a real security analysis.
E.g., where I work, we had a failed project coded not by us but by a team of uber-expensive consultants from a BIG corporation. Utterly incompetent monkeys, but expensive consultants anyway.
It allowed a user to change their id to another user by merely editting the parameter in the URL. Since user id 0 was the super-admin, there you go, an easy way for everyone to escalate their privileges.
It also allowed anyone to access and _edit_ any data, including other users' data and passwords, again by simply editting the URL. Including, yes, changing the passwords for the admin and then logging in as admin.
It also allowed users to embed HTML text and even JavaScript in their text, which would be faithfully included in the page without quoting. Just in case you wanted to cause a JavaScript exploit or redirect to be displayed in other users' or admins' browser, you know.
What was worse, though, was that it didn't quote text used to build SQL statements either, basically allowing anyone to exploit the program into giving them all the data in the system. (If they didn't already get to it via the previous two exploits. As they say, three's a charm.)
Etc.
Again, personally I'd rate that as _worse_ than a buffer overflow. Attacking a company's own web programs via buffer overflows, and finding your way from there to the data, is something only a die-hard black-hat would do. Even ordinary script kiddies with rootkits won't bother doing much more than installing a spam zombie or warez/porn ftp server there. Whereas this presented an intuitive, menu-driven, user-friendly way to own a company's business data. And _change_ that data as you see fit.
In a nutshell, that's what happens when you start thinking that the language or libraries are a magic talisman. The moment you think "nah, we don't need a security analysis, because the holy Java will protect us"... that's when you are the most vulnerable.
A polar bear is a cartesian bear after a coordinate transform.
While I really deeply respect J. D. (he wrote my first Pascal book, that pretty much put me on the structured programming track), I don't agree, and not with nyda either.
The bigger security problems of Microsoft software are three fold:
- indeed bufferoverflows are a C program, but most other OSes have this too.
- Microsoft is under hacker fire. True, but so is e.g. Apache, and that project has a much better trackrecord
- which brings me to the actual point: the main software development problem of Microsoft is the deep integration of systems, and the total unmanagable chaos as a result. Everything is integrated with everything.
P.s. C has a quite small and straightforward runtime, and this IMHO has a mitigating effect on C software development. The runtime is very predicatable, compared to e.g. JVM, CLR, and the various scripting languages
How may of you can honestly say "I have never, ever created an interface without possibility to change expected behaviour"?
How may of you can honestly say "I have never, ever made a mistake while coding or designing program logic and flow"?
If you answered "I can" to all three you are lying!
That is the essence of secure software. We all make mistakes, including seasoned, paranoid veterans as myself. Some of us less others more, noone make NO mistakes. The more complex a system is the greater the risk of a fatal mistake...
The only way to make secure software is;
I agree, Raging Guppy. I have worked with C and C++ software in Linux, OS/2, and Windows environments for the longest time. I can appreciate the fact the author is trying to push... that C/C++, by their nature, allow the possibility for memory corruption and overruns that can be potential security breaches. I will remind you that Linux servers are used extensively and just as much as Microsoft servers in many cases, if not more. These servers are not vulnerable to the problsm that exist on the Microsoft platform. Microsoft has had YEARS to straighten out IE, but has failed to... in fact, the software gets worse as time goes on. It seems analogous to an old canoe with holes that keep popping up because of rotting wood... for how long can you keep patching it till all you have are patches keeping it together? While writing this, I got 3 IE popups come out of nowhere! I am not even using IE, nor have I ever, in the past 1 year. I use firefox, exclusively. Why is this firefox program already super-ceding my wildest (albeit lowered) expectations of IE? Why is Microsoft not improving on things that have existed as problems over the course of 3 or more different OS revisions? These are but many of the myriad of unanswered questions that Microsoft executives always avoid answering somehow.
It is possible to write bad code in any computationally-complete language. (Corollary: Any language which makes it actually impossible to write bad code is computationally incomplete).
It's also possible to write good code in a language that lets you write bad code. Perl has a bad {and IMHO undeserved} reputation, but there are two words that will keep you safe: use strict;
There is a reason why C does not implement bounds checking. It is because the creators of C assumed any programmer either would have the sense to do so for themself, or would have a bloody good reason for wanting to do it that way. It's like a cutting tool which will let you start the motor even without all the guards in place. For the odd, freak case where you have to do something the manufacturers never thought of, it might be necessary to do things that way {think, a really unusual shaped workpiece which fouls on the guard no matter which side you try to cut it from, but which is physically big enough that you can hold it with both hands well clear of any moving machinery; two arrays where you know, from reading the compiler source code, that they will be stored one after another in memory where b[0] just happens also to be referenceable as a[200]}. The fact that I can't think of a plausible situation off the top of my head certainly doesn't mean there isn't one.
Bounds checking as a matter of course would serve only to slow things down needlessly. Yes, the ability to exceed bounds can be abused. But you don't always need the check, and UNIX/C philosophy eschews performing any action without an explicit request. Sometimes the check is implicit. For instance, if you do a % or && operation, or are reading from a type such as a char, you already know the limits within which the answer must lie; so why need your programming language re-check them for you? And if you're only reading a value from an array and you don't actually set too much store by what comes out {maybe it's just some text you're presenting to the user}, then you could quite conceivably get away without doing any bounds-checking.
Powerful tools are by definition potentially dangerous, and inherently-safe tools are by definition underpowered. But that isn't the problem. The problem is that programmers today are being brought up on "toy" languages with all the wipe-your-arse-for-you stuff, and never learning to respect what happens when you don't have all the handholding in place.
Of course it's easier to blame the language, and more so when you are trying to sell people an expensive programming language that claims to make it harder to write bad code {and quite probably harder to write code that runs on anything less than 2GHz, but that's not your concern if you don't actually sell hardware}.
PS. It's my bold prediction that before "no execute" becomes a standard feature on every processor, there will be an exploit allowing stuff labelled NX to be executed. It requires just one clueless user somewhere in the world with access to a broadband line, and ultimately will royally screw over any software that depends on NX for correct operation. More in next topic to mention this particular red herring.
Je fume. Tu fumes. Nous fûmes!
he notes that the problem is largely with C/C++ and mostly because of the buffer overflow problems.
Most of the security problems that really turn into a bear with Windows aren't buffer overflows. They're layering problems. Windows doesn't have a strong distinction between different layers, it doesn't really have any internal security boundaries. It's got a complex privilege model that's wide open to privilege boosting, and applications have to be granted far too many privileges to do their normal operations... and because privileges can't be associated with applications that means a user has to be given all the privileges ANY application he uses will ever need. On top of that, "security zones" mean that if you can trick some component (the HTML control, of course) into thinking you're in the right zone it'll grant you full "local user" privileges and let you run any damn executable or script you want.
On the server side, there's all these spooky connections between application services and network services, so that you can't keep the system from leaving listening ports into important services open, and you can't firewall them off unless you want to shut down native network support completely.
THIS is the problem with Windows security. It's not just that it's a monoculture, it's a culture with security flaws baked into the APIs that can't be fixed without breaking applications.