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."
Wasn't this why C# was created?
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.
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
Perhaps you could RTFA and then refute specific points rather than reading the blurb and making a blanket statement with nothing to support it other than your reflexive thinking.
Any compiled language is susceptible to security holes. The problem is that the process of turning source code into binary code is opaque to the developer. He puts some code through the compiler and some binary object code pops out. Things like memory offsets, code areas, data areas, and all these esoteric issues that need to be dealt with are simply left to the compiler to decide.
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.
This is idiotic... The language is simply a tool. If you dont know how to use a hammer without crushing your finger,use screws, or dont and stop blaming the hammer for losing your pinky.
How do you know he's not just making a joke? How do I know you're not ust making a joke? What's the point of these discussions?
As a programmer, I feel the continual march of progress in computing has been hampered as of late because of a major misconception in some segments of the software industry. Some would argue that the process of refinement by iterative design, which is the subject of many texts in the field -- extreme programming being the most recent -- demonstrates that applying the theory of evolution to coding is the most effective model of program 'design'.
But this is erroneous. The problem is that while extremely negative traits are usually stripped away in this model, negative traits that do not (metaphorically) explicitly interfere with life up until reproduction often remain. Additionally, traits that would be extremely beneficial that are not explicitly necessary for survival fail to come to light. Our ability to think and reason was not the product of evolution, but was deliberately chosen for us. Perhaps this is a thought that should again be applied to the creation of software.
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. One only has to compare the security woes of Microsoft or Linux with the rock-solid experience of OpenBSD for an example. It makes little sense from a business perspective as well; it costs up to ten times as much to fix an error by the time it hits the market as it would to catch it during the design. Unfortunately, as much of this cost is borne by consumers and not the companies designing buggy products, it's harder to make the case for proper software engineering -- especially in an environment like Microsoft where one hand may not often be aware of what the other is doing.
Don't be fooled into thinking open source is free of the 'monoculture' mindset, either. While it is perhaps in a better position to take advantage of vibrant and daring new concepts because of the lack of need to meet a marketing deadline or profitability requirement the types of holy wars one might have noticed between KDE/GNOME or Free Software/Open Source demonstrate that there are at least some within every community that feel they hold the monopoly on wisdom.
Try not. Do or do not, there is no try.
-- Dr. Spock, stardate 2822-3.
Can someone confirm this at NetCraft?
...that with .net - a patch to the framework can fix the buffer overflows (and other bugs) which are discovered and the benefits will be instantly seen by all applications using it. With C/C++, etc - you need to scan and fix each individual application for bugs. Its easier to fix the runtime than individual apps because every exploit would generally be exploiting the runtime (as long as its managed) which would make the runtime very robust. WIth C/C++, each time you discover a buffer overflow or similar exploit in an app, it does say anything about other apps which might have similar problems.
Chirayu Krishnappa
From netcraft:
Apache 67.92%
Sure... Minority Product.
Author obviously isn't the most impartial of writers.
[...]popularity and market share of Microsoft's products that are responsible [...] the problem is largely with C/C++ [...]
Yup, that's 2 bullshits in one sentence.
I am putting myself to the fullest possible use, which is all I can think that any conscious entity can ever hope to do.
Secondly, its record speaks for itself- windows, outlook, and IE are exploited because IT'S SO FREAKING EASY. Sure, you can maybe sort of lock out users from core system functions, but you can't lock out applications from altering core system files. Hello, the Registry! Hello .dll and .vxd! Just visit a Web site and poof! ownz0red. Just leave your winduhs system connected to the Internet, and bam! Instant spam relay. such a friendly lil OS!
Really dood, you call yourself a programmer- you should know better. Face the facts. If you can.
we will end no whine before its time
It's really not that hard to avoid buffer overflows in C/C++. It's not the fault of the language, but of the programmer. Obviously, avoiding buffer overflows is an added thing to think about when coding in C/C++, but I've worked with enough Java programmers to know that no language can compensate for a poor/ignorant programmer.
It's just an excuse, plain and simple.
Buffer Overflows are avoidable with good programming practices and good code maintance. This what Microsoft failed at. Furthermore they are a nice juicy security target so their multitude of mistakes are taken advantage of. Market share is only one part of the equation, one most not overlook "quality".
Microsoft had it's chance to make good, stable, reasonably priced OS's but they took the easy road of quickly pushing out products out the door, numerous un-ethical marketing and fear marketing programs, very unethical buisiness practices and they have only themselves to blaim that linux now threatens them in the long term...hiding behind patents won't work in the long term...the only thing that will work is good, stable operating systems...its not like cpu architectures wear out...so a good operating system will last a very long time. Only an idiot would want 5000 versions of windows when linux is availible.
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
I mean why can't a company with the financial resources of Microsoft invest some back into solving these kinds of problems. If buufer overflows are determined to be the problem then Purify and get on with it...
How do I know you are not making a joke about the other people making a joke?
Once again, another defender of Microsoft's software fails to explain why IIS, with it's smaller market share, has had far more vulnerabilities and more severe vulnerabilities than Apache.
I think what all MS apologists ignore is the security in depth that exists in *NIX systems. They ignore issues like a vulnerability in Apache may not result in a root compromise, because it is running as an unpriviledged user.
The real "Libtards" are the Libertarians!
how do i know any of you actually exist. How do i know i exist. Fuck, there goes sleeping for the night.
Maybe I'm just ignorant and ill-read, but I've never even heard of Writing Solid Code, which according to the article is a classic. I somehow missed it while reading The Art of Computer Programming, The Dragon Book, The Structure and Interpretion of Computer Programs, Software Tools, and the like.
I'm also amazed at the idea that competant programmers in a decently run company can't avoid writing software full of bugs because C and C++ lead to buffer overflow errors. They're easy enough to avoid. I've never had one in anything I've written and its not as if I've never had a bug.
I really don't think C/C++ are to blame for ActiveX vulnerabilities.
This guy is way out there
Microsoft
Just think, if code was perfect, then there would be no need for upgrades; a valuable source of revenue.
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.
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
That's not to say all of the security problems in software are the "fault" of C++ (if you're careful, you can use it securely), but the runtime checks that C++ neglects in favour of execution efficiency certainly play a large part. I would expect C/C++ (in it's current form) dies off as the dominant language of software development within the next 5-10 years because the additional execution efficency will become less and less significant with hardware improvements.
I am the maverick of Slashdot
Being the most popular always came with negativity. Honestly, why would anyone care about writing virii, worms and other means of computer assault on Linux. It fills an extremely small gap in the number of consumer desktops used worldwide. It is more fun to hash the Big Redmond Giant.
You don't make something opensource if you wanna make money. That is a straight up fact. Have there been successes? Oh yeah, there have been plenty. If you wanna make the big bucks you keep it in house so no one can profit off your work. However, your company can't make money if you are continuously working on a product and not selling it. So does Microsoft release buggy code? Yeah.
It is a matter of money. Bill Gates didn't start Microsoft because he wanted to touch lives, he made the company to make money. That is the general reason anyone starts a company. Dollar signs.
So you have deadlines. A good example is the rush developement and release of EQ2. Hell you can even compare it to any EQ expansion. Full of bugs, exploits, instability, etc. Why? Money. You don't make money programming to make it perfect. You make money by having a product good enough that people will use it. Why else has EQ maintained a stable subscription base over five years. Granted there have been jumps in either direction but it has been stable enough to open more servers.
Expansions like Gates of Discord, Luclin, Omens of War and Planes of Power all had more than their fair share of bugs. Money is the underlying issue. The expansions were good enough to release but not solid.
The same can be said for Microsoft. Windows is good enough but can always be fixed through patches. If they are gonna keep it in house forever, then they will never make money.
Microsoft's got billions of dollars and thousands of developers, in a market where there are many thousands more developers looking for jobs. Why don't they write a tool that search/replaces C/C++ source code for buffer allocations and replaces them with calls to a class or struct with bounds checking? It's not a trivial problem, but if they put their money where their mouth is, their pledge to prioritize security would match this whining about C/C++ buffer bugs. Unless their agenda is merely to herd everyone into programming C#, at the expense of the massive losses while legacy C/C++ code is still in vogue.
--
make install -not war
The claim is that windows gets attacked so much because it's the most popular... but consider the following:
Look at the different web servers in the world, and look at what percentage of them run Microsoft's webserver and what percentage of them run another system.
Now take a wild guess which webserver actually has the greatest number of exploits for it floating around. Anyone who pays any attention at all to their access logs on their webserver will tell you they get almost insane numbers of IIS exploit attempts on their webservers each and every day.
But Microsoft doesn't have the marketshare in the web server market to justify the disproportional number of attacks it gets, yet it's _CLEARLY_ in the lead for being attacked.
Conclusion: Microsoft's view that they are being "picked on" because they are in the lead is false. They are being picked on because they are highly accessible target that develops software that is easy to exploit, and Microsoft is simply too stubborn to admit that it has a real problem, insted amounting to blaming it on something resembling "jealousy".
File under 'M' for 'Manic ranting'
Then run your IIS as an unpreveliged user. Windows allows you that flexibility.
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
OpenBSD and OpenVMS are written in C. Qmail and djbdns are written in C.
Is it difficult to prevent buffer overflows? If you are reading a string, either use a string class, or read only as many characters as the character array can store. (What a novel idea!) If you are writing a string, among other things, set the last possible character of that string to null, just in case.
These are but single simplified examples, but it is not impossible by any means, or even all that difficult, to write solid code.
Among other things, the problem is that it takes individual effort to make sure every static-sized buffer isn't abused. As Murphy would tell you, human error is bound to crop up--increasingly so as the complexity of the project increases. I believe there was a post on the formula for this not too long ago.
As to the solution, well, that's a tough one. Higher level languages (Java, C#) help reduce these problems (and help reduce performance as well), but are just a band-aid. Perhaps the Manhattan Project (no, not that one) will come up with something better.
Until then, try to avoid products which have proven themselves to be full of holes year after year, week after week. And no, this doesn't just include all Microsoft server software. BIND and Sendmail come to mind.
Computer Science is no more about computers than astronomy is about telescopes. --E. W. Dijkstra
This article makes me wonder about the potential security problems with overflows in open source code. Are we more vulnerable than m$? or should we all switch to openBSD?
I'm not convinced this man, Microsoft or anyone else for that matter knows why they have the problems they do. If they did, I'm sure Microsoft would be very interested in obtaining this information so they could make higher quality software.
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?
"If you are a dreamer, a wisher, a liar, A hope-er, a pray-er, a magic bean buyer
so please correct me if I'm mistaken, but IIRC vector<T> and the like aren't boundary checked, are they? If they aren't, then C++ code using the STL containers could be just as susceptible to buffer overflows as C.
I he seriously trying to say non-compliant software would be more secure???
"Standards are good, and you'll pry C and C++ out of our programmers' cold, dead hands."
You know, maybe there's a point here. Perhaps if everyone switched to some other language, bugs and exploits would trend down. But there's more to it than this, and this isn't the biggest issue.
If you want to remove the errors from your code you have to dedicate the time to do so. Microsoft have shown that they are not willing to do so - they optimise for speed, integration and good looks rather than security and effectiveness.
And now they're falling apart on their traditional specialty too, because their software is like Swiss cheese. You can use it to make a sandwich, but you can't build on it.
As people have pointed out, Microsoft is not the monolith most laymen assume. Oh, sure, you and I see a Microsoft logo or picture when we turn on our computer, but who knew that most of the Internet was running on Linux, BSD and a handful of related OSes? Who knew that most of the world's fileservers were Novell? These are the real targets in the networked world, yet it's IIS that gets it. It's Windows 2000 Server that gets it.
Duntemann is right - Microsoft don't hire total retards to write their programs. Given the opportunity, they have shown that they can do what they're supposed to do. But they aren't supposed to do security, so they don't.
Microsoft may be changing their minds now. They are certainly marketing in that direction, but who knows? They're one of the most successful marketing companies in the world, but their lies are wearing thin (remember all those blue screen TV ads for Windows XP?)
It's no accident that they're using the languages they are at Microsoft, and it's no accident their work is inefficient and full of holes. They neglected these areas on purpose so that they could focus on "it runs fast and it comes with the computer."
*#*#*#*#*#******* I love peanut butter sandwiches!
Most buffer overflows are the result of simple laziness. For almost all cases, it is possible to write a generalized set of functions or, in C++, a class to manage dynamic buffers. There are, in fact, umpteen million implementations of resizeable buffers. This is not a flaw in C or C++ any more than a gun is flawed because it can be used to shoot yourself in the foot. Being careful and alert is a prerequisite for using most powerful tools.
Of course, it grieves me to be in the position of defending C++, since the whole type-safety nonsense was largely a response to the lamentable fact that some programmers can't bother to read a function prototype or treat void pointers with respect.
But then, C++ is a perfect example of the futility of attempting to design tolerance for carelessness into a language. C++ did indeed fix many of the problems of C, but as Microsoft and many others demonstrate, sloppy, careless coders are perfectly capable of writing sloppy, careless code in any language. Buffer overflows may be impossible in Perl, but have you noticed any shortage of buggy, poorly conceived code in Perl? Java? Python? For every correct implementation, there are countless trillions of incorrect ones. How are you going to plug that hole with a yacc grammar?
The currently dominant languages have a lot to recommend them. And for most of them, there are excellent tools for checking the correctness of code, enforcing good programming practices, generating accurate and up-to-date documentation, and so on. But if you don't use them, or you don't put serious and careful thought into design, implementation, and maintenance, you're going to produce buggy software in whatever language you're using.
Lack of competition and poor design and implementation are Microsoft's problems. Buffer overflows are just the characteristic symptom of careless coding in C and C++. If Microsoft switched to Java or Eiffel or ML tomorrow, the buffer overflows might vanish, but something else would take their place.
Proud member of the Weirdo-American community.
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.
Where the problem with Microsoft has got a lot more to do with their management forcing competitors products into the ground ensuring that they get those high 90s market share figures.
Microsoft is rather better known for poor security tactics.
The argument that it's some inherent flaw in C doesn't hold water, as it can be not only programmed around, but a multiple layer approach to security would as a minimum ensure that each bug found had limited damage, instead of the typical issue in MS products which is that a single hole will render the entire system to be a remote control for anyone on the Internet. This is the same for viruses on the windows platform, and part of the basic structure of how the OS handles commands sent between software. (Such as the famous trick to elevate your priviledges in 'secured' windows boxes.)
In the end, shipping an OS with just about every internet service and port open by default is not a fault in the C programming language. It's a filthy oversight.
I fart, therefore, I am. The rest of comment has been typed out to avoid the lameness filter, thank you for your time.
The subject says it all. There are very good C/C++ programmers and there are very bad C/C++ programmers. Is the language really the problem? Sure overruns and exploits can happen with C/C++, but look at Linux and how it compares to Windows. Both are build on C/C++ and both have different histories wrt to security issues associated with application programming errors irrespective of language. I'm not saying that windows is bad or linux is good. I am saying that the issue is a little over-generalised in my opinion! :-)
After further review, the main reason they have error and exploit prone software is because they can. They don't care because it does not effect their sales at all. I'm sure they would prefer better systems, but really it is not a priority. The real priority is stomping out competitors with their monopolistic strategy.
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.
"If you are a dreamer, a wisher, a liar, A hope-er, a pray-er, a magic bean buyer
This business of security in Microsoft's products
has got nothing to do with coding - and everything
to do with marketing. Else, would someone like Dave Cutler (be forced to) put out an O-S like Windows NT?
The point isn't that C/C++ is full of bugs, or allows bad code, or wether the programmer is bad, or whatnot.
.net managed version of IE will be fairly free of such bugs.
Face it, there's no such thing as a perfect programmer. Nobody writes perfect code. And while you might never have written a buffer overflow bug in your whole life, chances are that if you work on a team, that team will produce such a bug, if it's possible in the tool you use.
No, the problem is, as the author of the article points out, with market share.
Nobody bothers attacking Firefox or opera. Why ? Because the virus, worm, whatever wouldn't spread past the friends of the virus writer.
No, in order to get the virus to stay in business, you attack the majority of people, and to do that you attack the operating system or software most people have.
And most people have Microsoft and IE, so this is the best way to spread the virus. Hence, you start digging into those pieces of software to find holes.
"Nobody" digs into Firefox in the same way. If you think that your testers or programmers are enough to find bugs, think again. When you have scores of teenagers all having the time of their life digging into these tools, having a couple of hundred programmers isn't going to stand a chance of having the same time to look through the source.
If for some odd reason Firefox, Opera, or whatnot, should become the next big browser and gain a 70%+ marketshare, it will be attacked too. And when that happens, you'll know that it will have the same security problems as everything else.
Chances are that by this time, the
"A poor workman blames his tools"
is it to just to make sure that EVERY time you use a buffer, you make bloody sure it wont overflow. even if it means trucating the data being poured into it up to the buffers capacity?
It is well known and widely-accepted that you can write bad code with good language. AND you can write good code with bad language.
:-)
And, of course, a nice virtual machine or bytecode interpreter/runtime compiler can make zillions of check of your code to deal with your lazyness. But hey, who said the VM itself is secure? Alot of VMs I know of are written in guess what? C/C++
What I am afraid of, however, is M$ is implying that C/C++ is so flawless and that is really has to be replaced with C#.. just a short step and bright future awaits us. And people take all that as Gospel
Comment removed based on user account deletion
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.
Y'know, on the face of it, assuming Microsoft's gaping secuirty holes in it's default Windows distribution could be attributed to its massive popularity. a twist on the old OSS saw that many eyes make all bugs (or holes big enough to drive a herd of mastadons through) obvious. This is usually a canned reply by Windows Partisians to Linux/Mac/Etc. Partisians when they gloat about the latest OE bug or self-installing spyware package.
But it doesn't hold much water when you look at the wider world, where Microsoft doesn't dominate.
Oracle and MySQL dwarf SQL Server's installed base, yet it's the Microsoft product that's caused the most headaches to IT security teams over the years. Ditto Apache vs. IIS... Apache is everywhere, source code is available and documented, and it is nowhere near as hackable as IIS, assuming admins of equal ability managing either system.
I think it's just that Microsoft's monopoly position has extinguished any sense of urgency in meeting it's customer's actual needs.
SoupIsGood Food
The article says that IE is exploited so often because it is so popular. If Mozilla were as popular as IE, would it be just as often exploited?
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
lf(1): it's like ls(1) but sorts filenames by extension, tersely
Actually, yes. Look at them:
http://www.netcraft.com/Survey/index-200109.html
While this survey is from 2001, the number of hosts on apache and IIS are not too different from what they are today. The important part of the survey though, is the section titled: Operating Systems used by Computers running public Internet Web Sites, June 2001. Windows runs > 50% of the web servers.
People always misinterpret the Netcraft numbers. They list HOSTNAMES, not servers. Since Apache is used far more often on multi-site hosting servers, it has a higher percentage, but not a larger market share.
If you need web hosting, you could do worse than here
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.
The main reason was that Microsoft and Sun didn't get along with each other on Java development. This ended with the termination of Microsoft's Java licence by Sun, a lawsuit and a settlement that said Microsoft has to leave the Java market.
The next move by Microsoft was to introduce C# as an alternative to Java. If it also solves the buffer overflow problem (I don't know C#), that is a beneficial side effect.
C - the footgun of programming languages
Jeff argues that monocultures are inevitable. This is not true. There are mechanisms in place in this country for breaking up monopolies. These techniquest have been used for nearly 100 years, since the presidency of Theodore Rosevelt. Using them in the past has brought great benefit to both consumers and businesses. In particular, one could break up Microsoft by splitting the application group from the OS group. One could furthermore split the browser out of the OS. Much of Jeff's argument depends on the false premise that monocultures in the computer world are inevitable, and can't be avoided. Take this point out, and the article has a very different flavor.
"C and C++, are really the same language at the core, where these sorts of bugs happen."
That really tells you the author doesn't understand C++. Of course, that suggests the conclusion is flaky.
The problem he alludes to is that it is possible to compile C with a C++ compiler (with very little exceptions, e.g. int class; won't work). That means your buggy C program probably will compile as well. Most C runtime bugs aren't caught suddenly at C++ compile time.
However, the two languages are distinct. C++ string processing isn't done with char pointers, but with a class. In C, you'd use strcat() to append to a string. That can overflow. In C++, you use string += , which automatically grows the left-hand side.
The new version of MSVC++ deprecates these C string functions. This clearly shows you don't need them.
First of all, they seem to be very susceptible to 'Not Invented Here' (NIH) which leads to them re-inventing solutions to problems that have long been solved by UNIX and in the academic community (and usually better, too).
Secondly, they have a lot of smart designers and programmers - the problem is that they know this and are arrogant to assume that they can therefore develop better and more perfect software than anything that's gone before. This leads to over-complex designs that are too hard to implement in robust ways.
Depressing though it is, it really does seem as though 'worse is better' is one of the most reliable ways of getting robust software (even if it just gives up and aborts without even attempting the job asked of it, sometimes).
--
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.
It's yet another paid-for-by-Microsoft article. What do you expect?
It's a bunch of handwaving trying to mask the inherently crap quality of MS products. Spread enough lies and they become the truth.
Aren't we simplifying things just a leetle bit here? Yes, monoculture is not good, because it creates the basis for a scenario of total failure, and C in the hands of the more witless sort of programmer can certainly be lethal (although, ANY language in the hands of a stupid programmer is a bad idea. Just look at the host of Visual Basic crap).
However, as far as I can see, by far the largest problem on the internet is the way Microsoft has built powerful programming capabilities into a number of their products, and the way things just happen automatically by default. Perhaps it is getting better, but only slowly. To illustrate: I work in an office where most users have Windows on their desktops, but I use Linux. We have had on average something like 3 or 4 major alerts about email worms per month in the last year, and it has affected everybody else except me. Is this because Windows is a monoculture and programmed in C? Or is it because Microsoft stupidly decided to build in functionality that supports these worms?
The truth is that no matter how many buffer overflows there may be in Linux, BSD etc, we are not likely to ever have problems with email worms - unless some idiot puts the necessary functionality in place.
In the story we can see the same common misunderstanding: "If Linux will be big, it will suffer same vulnerabilities as MS". MS has really succeeded in teaching the world that!
Well Apache is big already and yet has clearly better security-level than the comparing MS-product. There must be something different in the process of either making software or fixing the holes!
C/C++ causes security problems.
.NET framework probably written in C/C++
.NET code guaranteed to have security problems.
Therefore all
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
The only 'logical' way to eliminate buffer overflows was already know 30+ years ago: Don't make data areas executable!, that simple!
Now if after 30+ years, computer industry still is unable/uninterested to fix that simple problem, That's the real problem!
Stop blamming the tools (languages/etc) or the people (programmers/admins/etc), is the system stupid.
What's in a sig?
The farmer blames his swimming pants.
Better compilers have a role to play. There was a great deal of work done on Ada compilers to be more intelligent about generating code for error checks. This greatly reduces the speed penalty for safe code.
Mea navis aericumbens anguillis abundat
2. Microsoft's Marketing - Yes, Microsoft are now a victim of their own lies as a result of convincing the public at large that their products are easy to use & maintain and that PCs never go wrong.
As an example, I just built a PC for a friend of mine who has never really worried about computers until it became apparent that her son needed Internet access to do some of his school homework. The sheer amount of information overload I had to give her was just frightening - update and run rhe virus checker regularly, update Windows regularly, update spyware programs regularly, don't use insecure passwords, don't duplicate passwords across different applications, etc. I ended up typing out 3 pages of hints and tips for her in the end.
3. User ignorance and greed - This follows on from 2. because far too many people have fallen for the Microsoft hype and have no clear understanding of how to keep themselves secure when on the Internet. Add to this that everyone wants something for nothing and the result is a whole heap of ignoramuses file-sharing all manner of nasty programs purely because they want their free music.
I don't care what anyone says but this will never happen with Linux. Linux will never be a mono-culture because the fact is that installing and using Linux automatically creates a learning curve meaning that anyone who uses it immediately starts becoming a more knowledgeable computer user. Sure, it takes a long time to become an expert but when you do, it is relatively easy to maintain a system to only run the services you need and to keep those updated. That's why viruses will never spread through a Linux user base because no two Linux machines are every entirely alike and because Linux users don't suffer from the same ignorance that plagues the Windows community.
I, for one, welcome it. I do not want inexperienced users flocking to use Linux purely because of the cool factor. The fact is that moving from Windows to Linux is like changing from being a child to an adult - the first step is to accept that you are responsible for your actions, not anyone else.
Gentoo Linux - another day, another USE flag.
as every time with M$'n'bugz story, I want to repeat my thesis:
..."
;-)
M$ continually misleads and milks the dumb users that it created.
the worst side effect M$ has spawned over the years, is the
propagation of computer semi- or illiterate users, that are
lead into the illusion of a bulletproof environment that will
do-for-them-what-they-want.
It starts with ignoring any available textbooks, throwing away manuals, thrashing installation guides along with the packaging even before even trying the 'plug-and-pray' ritual, moving on to the belief that anything can be resolved by clicking 'yes' or 'no' to
any set of questions asked by the system. Naturally, this is nerdy behaivour, too.
When something goes wrong, its "fix my computer, you incompetent
phrase for the post-sales, support, sysadmin or any nearest computer-literate person all over again. Here is the difference: a nerd fixes things hands-on, our joe-illiterate-user, on the other hand, blames the nearest nerd!
It's the spoiled brats who defend the main part of M$ market share and most its earnings - since M$ has lead them to believe it can
deliver them an omnipotent tool without the need to learn, maintain or comprehend anything.
M$ deliver now, fix later-or-never politics
that is in clear contrast to the beliefs of its last faithful users,
nicely complements the situation above to create the ultimate "business" model that is beyond any parasitic capabilities.
The only solution offered is buying newer products and paying for support into infinity...
sorry for tipos - blame the M$ IE I just used
Wow, what a genius article.
.Net sucks, after using it solid for 6-8 months, I say that with conviction.
The problems are not the fact that C/C++ can overflow faster than a toilet at a "bulemics anonymous all you can eat buffet" - but that M$ do not invest the time to make functional (hah) code secure, well tested, and usable (with right features) because they *know* that by the tiume this gets an issue, they will be flogging us the getCurrentYear() + (Math.random()*2) version.
Thier bad programming works in thier favour.
Now, C/C++ are pants for making sure you cannot pwn teh w0rld easily. M$ just doen't help things.
Now Jaaaavaaaaa on the other hand *overlooking bad implementations of MIDP with a rush to market on antiquainted handsets* has a nice little bytecode security thingy TM(C)(R).
Unless you use a non-official JVM which may not bother with such things.
Java is fairly damn l33t, after using it for 4 years solid.
Yes, it has problems (name one problem it has that affected me, and you win an ascii cigar!)
#hostfile 0.0.0.0 primidi.com 0.0.0.0 www.primidi.com 0.0.0.0 radio.weblogs.com
Fake plastic submarine.
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.
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;
This guy wants an ASCII cigar. Where's Trollkore when you need him?
If anything at all was done in a manner similar to how software is developed -- with critical parts of the system handled by people with no education or experience, under constant stress, with specifications changing faster than they are implemented -- it will be a constant, never ending disaster. A C or C++ programmer working in decent conditions is not any more prone to write code with buffer overflow than, say, an engineer designing a vehicle is prone to make another Ford Pinto. The problem is, no one would dare to place and engineer working on a car into working conditions that are considered acceptable for a software developer.
Contrary to the popular belief, there indeed is no God.
The problem however is that, well, no language or library ever can force you to stop making mistakes.
What about libsafe ?
Interesting theory. I wonder how they came up with it. I happen to strongly disagree. This sounds more like microsoft trying to justify the poor job they've done in configuration management and quality assurance. Not an issue of software development tools.
Yes, although C and C++ has the capabilities to create such issues such as buffer overflow. Every good programmer I know understands the implications of using such functions and avoids it. If Microsoft programmers don't understand it then maybe microsoft should hire better programmers. In terms of the problems that exist in windows I don't believe this to be the case. And since I work in the tech support field I think I can call myself an authority on the subject. All the problems that I've ever seen in windows can not only be reproduced through testing they come up time and time again. They span multiple versions of windows and are never fixed despite the fact that microsoft knows about them. They've even created small patches to fix the problems when they crop up but have never worked to prevent the problems from occuring again.
This is why I don't buy your argument on the software Monoculture. One problem I see almost every day is a problem known by its error message "Operation was attempted on something that was not a socket.:" This problem has been around since microsoft created Windows NT and effects Windows 2000 and Windows XP also. Microsoft in all this time has not fixed the problem. They know about it. I mean I've personally sent customers to microsofts technical support department to have the problem repaired. Microsoft has an article on support.microsoft.com on how to fix the problem. If they can fix it then why don't they fix it so that it doesn't happen again? I'll tell you why. Because they can't be bothered. Every time someone calls Microsofts tech support for this problem its $30 and thats a major source of revenue.
The prevous problem is not the only problem I've seen on this issue. Take for instance the problem with spyware recently. Spyware is installed on peoples computers through security vulnerabilities in the Internet explorer browser. They know the exact security hole that causes the problem. Its the feature that allows you to place an Icon in the address bar with your website URL. They just recently published service pack two. You know what their solution was? They put a popup stopper into Intenet Explorer a solution that creates more problems then it fixes.
Lets take another problem and this one is the most damning of all. This problem has manifested itself in every version of windows since Windows 95. And It has been a problem since then. I mean you will run into this issue if you are running Windows 95, 98, ME, NT, 2000, and Windows XP. Microsoft knows about it. They even created a little function in windows to fix the problem in windows XP. Its having to reinstall the TCP / IP stack. Although fixing the problem has gotten easier in Windows XP. They have a nice menu item when you right click on Local Area Connection in the connection screen of the control panel. However, you still have to do it. Why haven't they fixed that. Its because they get paid $30 every time someone calls about this problem.
These aren't buffer overflow problems. They constitute for 90% of the problems I deal with every single day. They are problems that span multiple versions of Windows and have never been fixed. This argument is completely wrong I can't believe people are buying into it.
Using container libraries costs extra time and effort
No, it doesn't. The first times, when you don't know how to do it, perhaps, but after that, using them is much faster and easier than developing ad-hoc solutions everywhere.
and it is less efficient than error checking that is built into the compiler, for example.
And less efficient than error checking built into the compiler ? Why ? It's error checking done by the compiler, only the error checks aren't hardcoded in the compiler, but implemented by the standard library.
Also, using container libraries is not something that the C/C++ compilers help enforce; that is, if some module doesn't use it, nobody ever gets warned about it.
It's because of backwards compatibility with C. If you program in C++, you're supposed to use the standard library containers. The thing is, without the backward compatibility with C, C++ wouldn't have been quite as successful, anyway.
We need better tools to help people avoid it, and plain C/C++ apparently isn't enough for real-world programmers not to make these mistakes.
It's enough, only if properly used. There's no need for new tools. What's the point of creating new tools when the old one are rarely ever used properly, anyway ? I also though that C++ sucked until I learned to use it properly.
The real problem is that Microsoft doesn't let its programmers finish what they write. They are moved on to other projects, or the software is shipped before it is ready. This is just one example: Can Microsoft squash 63,000 bugs in Windows 2000?
In my experience, Windows XP has been the Windows ME of the Windows 2000 family.
Now, with Service Pack 2, Windows XP is beginning to look shippable.
A very good social skill to have is to be able to recognize when you are being abused. (This is not a reference to Bush supporters.) The pattern has been this: There begins to be a discussion about some problem created by Microsoft lack of idealism. Then people begin fighting among themselves, and the original subject is forgotten.
What this article boils down to is this: All software is exactly the same, so you may as well use Microsoft software. All software is written in C/C++, so you may as well use Microsoft software. What this bullshit actually means is: Microsoft is really scared shitless!!! .
By the perception of illusion, we experience reality
The truth is that no matter how many buffer overflows there may be in Linux, BSD etc, we are not likely to ever have problems with email worms - unless some idiot puts the necessary functionality in place.
Yes, exactly! Unix had a great head start compared to Windows. It was developed with a multiuser environment in mind. Legions of students have been banging on VAX machines, just to become root; both locally and remote. This led to a high awareness to security issues back then, when the system was being designed and stress-tested.
OTOH, Windows evolved form single-user CP/M, then DOS and acquired networked capabilities way too late in the development process. Adding security as an afterthought is extremely complicated. Especially when you want to (or have to) retain backward compatibility with tons of legacy software.
In short: Unix had to prevail in a hard environment when it was being developed. It remained (mostly) secure afterwards. Windows didn't have to prevail against attacks in its early days, and it never acquired the necessary level of "immunity" later.
cpghost at Cordula's Web.
Wow, we must be remembering two different browser wars. I recall MS winning over Netscape because it was a buggy piece of shit, and IE was able to run for longer than ten minutes without crashing all your open browser windows. Nutscrape also had incredible difficulty printing an html page.
Anyway, its nice to see Slashdot drag out the myth of 'software monoculture' at least once a week. They say it like it is a proven concept, like gravity, when it is actually only a problem to pseudo-intellectual pseudo-nerds on Slashdot, who spend all day blaming their burnt toast and bad hair on Microsoft.
...just further lockin.
d ea l_analysis/
I just can't see what relevance this has to anything these days. It's painfully obvious that organisations just don't care. Or the message isn't getting through. I give you this as an example:
http://www.theregister.co.uk/2004/11/08/nhs_ms_
The NHS is about to become the biggest single monoculture of all time. And yet, in all that happy fluffery of content ministers, there's little consideration of security. One unsecure laptop let loose in that environment and it all falls down - life-vital equipment, records and the PPT diagram for next years rolling lockin.
In other words, end-users buy software that's buggy if they think they're getting a good deal, and that doesn't always include risk-management. As a result, we (and I use that term advisedly) in the commercial world become bug-writers. OTOH, in this market-place, OSS, or code which could reasonably called more secure and I believe that most OSS code is, doesn't seem to have much of a niche. This USP is ignorable when standardisation is all that's called for.
h.
Patriotism is a virtue of the vicious
...he notes that the problem is largely with C/C++ and mostly because of the buffer overflow problems.
Oh, please! Every good programmer know how to handle memory allocations because *he knows how the machine works*! If we have so many buffer overflow problems today is because the great majority of the programmers out there don't understand/care about something that is the base of their work.
Think this way: you are a mechanic that builds internal combustion motors. But you don't understand how internal combustion motors works. So, will you build a good or a bad motor?
(And yes, you can build other types of motors if you don't understand/care how internal combustion motors works - and it is like using a different language).
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
I'm not as expert as the larger part of the people commenting here but I'll toss my ideas in a bit largely gathering from what I have learned over the past few years.
I don't think it's entirely fair to compare a relatively simple service to an entire operating system. What I mean here is saying stuff like "look at Apache... it fares far better than..." Okay, it holds the largest share of web servers but when you consider that the points of access are so very limited, it's a lot easier to secure access to it.
Microsoft seems to have a culture that doesn't care about anything but the result and the path taken to get the result is almost inconsequential. We see this through the ill-will it spreads throughout the business community with its nazi-like BSA. We see this through its illegal business practices (and I will say illegal because it has been ruled as such and I haven't seen any deviation from their tactics in the slightest). And speaking from almost direct experience with looking at their "expert-written code" someone very close to me who is by no means an expert coder had the opportunity to correct many aspects of their Soloman and connected projects.
Microsoft is also suffering from backward-compatibility pains. They established long ago a policy that requires backward compatibility. This means they have to not only correct the problems of their code in the past, but also maintain the quirky results of poor coding in the past so that applications exploiting the bad code can continue to run as expected. This is partly due to their "keep'm upgrading" drive since people wouldn't buy upgrades if it broke their software when they did. (Goes back to overly aggressive market drive that someone else mentioned)
With Microsoft, the notion that "you get what you pay for" should apply where it needn't be applied to Linux and the software that runs on it. We should expect more from a "professional" product than we do from one built by a collection of amateurs and ProAms. (I'm not knocking the writers and maintainers of Linux -- just pointing out where expectations should be coming from.) And yet we find the opposite is true. We find that we expect to see reliable experience with Linux and a faulty one with Microsoft. This may not be YOUR personal view, but it's the view of too many professionals out there who use and maintain the machines running both OSes.
Is it sufficient to say that "Microsoft sucks" or do I need to lay it out as I have above? They operate with little to no conscience at the business level and at the development level -- it shows in everything they do.
The argument of "Apache is widely used and is more secure than IIS, so you can't claim that Windows is attacked more simply because it's more widely used" is somewhat true, but misses a crucial point. Server software is not (usually) subjected to the same level of user stupiduty as desktop software.
Many of the 'security' problems in Windows are not just the result of sloppy programming by Microsoft. When you combine Microsoft's lack of attention to security with the stupidity of the average user, *THAT* is where the real problems start.
I have a few friends who have bought their first computers over that past couple of years and I would set them up with a firewall, tell them to buy an AV program and set up Mozilla for web browsing and e-mail, and tell them not to use IE. And within a few months I would be getting calls from them -- their computer is slow, it's crashing, etc....
And when I would investigate, I would find that their computers were full of garbage because they clicked on every piece of crapware that they came across. And their inbox is flooded with spam because they give their email address to every program and website that asks for it.
Here's what I mean. I have a bunch of machines at home that my kids use. They are automated up the wazoo to the extent that is possible. Real time scanners for viruses, spyware, popup blocking, firewalls, cookie scrubbers, the works. And they all work more or less to the extent they're supposed to but they require the person in the chair to take action when they shouldn't.
Why for example is it a GOOD idea for AVAST's real time scanner to tell me it found a virus and then not doing anything about it? It knows it's there, kill the damn thing. Don't give me a message popup from the system tray telling me you found it. My kids ignore it and I for one don't really want to know. And don't bother writing a log either - just email it to me once a month or something.
So the problem is that while we have these neato tools, for some odd reason the authors feel required to cripple their own tools so that we KNOW what they are doing? How stupid is that?
Problem with OS is not so much that apps are less prone to exploits, its more to do with worm-propagation, its practically harder to infect as linux system, since there is no clear path of entry where bad-apps can expect to be run by a user. Outlook/IE has a large install base, "everybody" knows how to send those progs things that auto-run, so there is a easy way into the target system.
/etc/motd to "looser you could be dead now"
To be real effective in spreading to linux/BSD systems, the hole needs to be in some listening daemon, like mail/dns/ntp.
I was hacked myself some 10 years ago with a dns-exploit, luckily it was by a friend, he just hacked into my system and changed
Even then I guess that what really helped him was that my smtp server at the time happily anounced what distro and what CPU I was using.
With windows you generally know all the dependant libs/dlls, with NIX you have to take an educated guess, like designing your worm to be effective against a given release of RedHat running i386, and that either has applied no patches or all patches up to but not including the last one.
"This is the future. This is what we built. This is what we wanted. It must have been. Because we all had the fucking choice, didn't we? It is only our money that allows commercial culture to flower. If we didn't want to live like this, we could have changed it any time, by not fucking paying for it.
"So let's celebrate by all going out and buying the same burger."
I am Sartre of the Borg. Existence is futile.
...and here's what I have to say about it:
...) or anything as trivial as that can be without bugs, adding complexity doesn't mean adding bugs along with it. It has been shown time and time again that many exploit possibilities are visible in the source code simply because the writers are using unsafe coding practices (think gets();). With those facts in mind, it is conceptually possible to write bug-free, exploit-resistant code. The fact that the author of the article states otherwise doesn't make it true. The fact that the author states otherwise is an attempt to convince the reading public that we should expect and accept bugs rather than strive to a loftier goal. (There will be dirt in the world, so let's all live in filth happily... there will be disease in the world, so forget about prevention.)
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?
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.
Nature deals with breakdowns in a complex system with evolution, and a very important part of evolution is the extinction of particular species. It's a sort of backtracking mechanism that corrects an evolutionary mistake. The Internet is an ecology, so if you build a species on it that is vulnerable to a certain pathogen, it can very well undergo extinction. By the way, the species that go extinct tend to have limited genetic diversity. -Bill Joy
Senthil
I think the problem isn't a lack of good programmers, that's for sure. MS has the best programmers money can buy (are YOU for sale?) But their programmers have to work within the framework set down by management and marketing, and that's where some big problems get set in. The programmers cannot solve the basic problems - all they can do is try to work around them.
Many of the problems with MS products boil down to design-architecture issues that the programmers absolutely have no say over, that are decided for legal or marketing reasons. The programmers aren't the ones that decide to come up with a new, more bloated and more obfuscated set of file formats every release of office. The programmers aren't the ones that decided IE had to be split up into libraries and 'integrated' with the shell to create a legal defense. The programmers probably didn't have much to say about the general tack of MS over the years towards more and more 'integration' of code - which makes it practically impossible to do a good security audit.
They do their best to work within those decisions, and they make herculean efforts at times, I'm sure. But you can only patch a fundamentally wrongheaded design so far.
=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Friends don't let friends enable ecmascript.
Transfer to floor sweeping any coder who is caught allocating I/O buffers off the stack. Haven't they figured that out *yet*?
People who build fault-tolerant systems start with the assumption that things will go wrong, and that includes software bugs and malicious injected code. Rather than trying to make faults never happen, an impossible task in practice, the system is designed to survive in the presence of faults, and minimise the damage they do. One of the key lessons from that work is that you create real boundaries around things, and prevent the faults crossing those boundaries. All Unix-like systems tend to have at least some kind of boundaries that are enforced, and it is relatively easy to tighten them up so that when things go bad, the damage does not spread too far or too fast.
These hard boundaries are also interfaces where you have to be explicit about how the pieces fit together, and so it is easy to substitute one implementation for another, and from a different supplier. Well defined boundaries make it hard to tweak the API to dislodge inconvenient competitors. Making everything deeply intertwined makes it hard for anyone to interface to your system without your permission, but those vital barriers to the propagation of faults go away.
We are never going to eliminate all faults, but there is a lot that can be done to reduce the damage they cause by using the right underlying system architecture and attitude to the overall system design. Robust design seems to require a significant degree of openness, and I think that this is where Windows is lacking.
The prettiest girl in school is always the one who is the most singled out and attacked by her peers. If you want to point out the 2nd prettiest girl to Microsoft, it is RedHat. In case you haven't noticed, they take the most flak from the same people who whine about Microsoft.
The real Microsoft motivation, behind the apparent motivation, is maintaing their monopoly position!
How can an outsider write compatible software, when everything is tightly integrated with everything else? It's just an impossible task! One not only must emulate ALL of those tightly integrated pieces, one has to faithly emulate many of the bugs too!
Recent news releases manifestly demonstrate that Microsoft themselves can't handle the software maintenance costs of the amount of integration that they have chosen! So, by definition, their products can't be emulated by anybody, even themselves!
That, by the way, also explains the need for their incessant releases!!!
Some say Windows has so many security vulnerabilities due to its popularity in the market.
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).
While the server-OS market share in 2001 was about 50% Windows, that simply tells us, that in no way the IIS-share could have been more than 50%, as IIS does not run on any other OS besides MS-Windows.
FYI a number of httpd-servers which are not made by Microsoft run on Windows, like: IBM Dominio Go, IBM-Websphere HTTPD (based on Apache), Netscape-Server, NCSA, CERN and many others.
On the same Netcraft page further down, we read: "Linux has gained 1% and Windows 0.3%, at the cost of the other operating systems. In fact the 0.3% Windows gain is largely a technical improvement, due to Unknown dropping 0.6% because of improvements in Netcraft operating system detection. The trend is of Linux steadily increasing".
There was no point in time, where IIS had a bigger market share than Apache, neither counting by hostnames, nor active sites, nor by ip-adresses.
BTW: I'm webmaster of a wellknown european e-commerce site running IBM WebSphere on MS-Windows, and soon we'll migrate to Linux (for security, performance and TCO reasons!).
than: "no easy threats on whole" ==> "more (no fewer) distinct organisms".
(Logic 101)
In order to allow for diversity, you need to support open standards. If people are free to choose which applications they use for their email, web-browsing, and document writing (etc.), they would probably choose to use many different utilities. For instance: if my organization uses POP3, I am not relying on any particular server/client to use it. In the *NIX world the open standards paradigm is governing... but is it so in the MS world? Forcing everyone to accept your "Total Domination" by using proprietary protocols/formats has its price. Maybe it is time to start playing ball with others?
We are always hearing about this Apache thing as to disprove attacks being focused on the biggest targets. "Why is IIS attacked more when apache runs virtually all of the internet?", hardly anyone seems to question this assertion.
People keep saying how their apache server logs are filled with code red and nimbda probes as evidence of how many IIS servers are being broken into.
Code Red and nimbda are really old worms, the exploits they attacked were patched years ago. The fact that the traces still show up in logs is evidence that there are a lot of unpatched IIS5 machines out there, machines that havn't been patched in the last two years. If a similar number of Apache servers were being left unpatched for that length of time how would they be faring?
Why are these old machines still around to keep spewing this stuff? Because IIS5 was installed and active by defualt on new Windows 2000 server installations and the admins never figured out they were even running it let alone that it was highly insecure out of the box and should be locked down and kept up to date with patches. Anyone running Apache is most likely doing so deliberately and is at least trying to keep it up to date and locked down.
Is IIS being broken into on a daily basis?, probably, but so is Apache as hacks on various high profile open source projects have shown.
Is a patched and up to date IIS6 server being broken into more often than the most recent Apache? I don't know, but somehow I doubt it.
IIS6 and Server2003 are some of the first products to benifit from Microsofts focus on security.
So far there have been very few updates required for IIS6, and it is disabled and configured in a locked down state out of the box.
The Grandparent has shown that attempted attacks on both IIS and Apache are roughly equal in scale, how many of those are successful with competant admins is rarely discussed.
If you stop counting the exploits of unmaintained and possibly unknown IIS5 boxes as examples of problems endemic to all versions of IIS you would probably find that there is not such a clear devide between them.
Also the Netcraft server usage figures are probably misleading. They count the number of servers hosting sites with different domain names.
A lot of sites run on shared hosting services running apache which probably means there are fewer actual apache servers than the count of domains would tend to indicate. Also a lot of IIS servers are being used for corperate intranet applications which are not supposed to be externally acessible and without a domain name, these servers are not counted by netcraft at all.
The few IIS servers that are (deliberately) on the public internet tend to be serving up large internet applications for businesses and so present a much larger target to potential hackers than the vast number of shared hosting accounts with a few php scripts running someones blog or homepage running on apache.
"Taligent is still pure vapor. Maybe they'll be the last who jumps up on Openstep... "
Given that all the .NET languages boil down to the same compiled runtime "language", and given that C++ is a .NET language, could somebody explain how problems endemic to C/C++ are kept from spreading to all languages in the .NET family?
.NET. I'm much more familiar with Java and prior generations of Microsoft languages.
I plead ignorance on
I am surprised you got modded funny. Scripters in my firm certainly think C++ is obscure, arcane and is the cause of all exploits, not bad programmers and bad programming techniques.
Buffer overruns are a problem because you can put executable code on the stack or the heap. Most other CPU architectures have an execute bit for pages that let you make the text area read-only and executable and everything else read-write and non-executable. The I86 archetecture does not have this - if it did then this type of attacks would be impossible.
.
it costs up to ten times as much to fix an error by the time it hits the market as it would to catch it during the design
Are you sure about that factor?
What if there are 100,000,000 users?
1. Keep the code as simple as possible.
2. Use the UNIX model of software development: One function, one task.
3. Write as much code as possible with rules 1. and 2. in mind.
Even then, subtle bugs may crop up due to subtle errors in program design, error checking, processing instructions, etc. For example, I had some code that was using 0 as input in error. Debugging the code led me to conclude that my data structures were not large enough. Changing a single symbolic constant fixed that problem. I re-ran the code with the 'fix' and had no further problems.
These are program bugs worth finding and fixing--not more obvious stuff like division by zero errors, or errors in user input validation.
Henceforth, everything shall be written in Forth.
I'll use my own experience as an examples. I once found such a bug and had to fight to get it fixed. The reason I had to fight was because it hadn't done any damage yet. I'm sure my experience would be the same in many large corporations. A bug won't get fixed until after it has caused damage or been publicly exposed as a risk.
And sadly, I can't really blame those who didn't want that particular bug fixed. They knew the politics involved. In order to get the buffer overflow bug fixed, they would probably have to take many code changes that may not have been safe. I'm sure this story is familiar to anyone who as ever upgraded software.
The solution? Simple. Good coding practices. Good review practices. Good testing. Good management.
Throw in a talking bunny rabbit and you'll have a good fairy tale.
We could eliminate the entire virus/worm propagation problem by making a few hundred different builds of each release of programs like IE, IIS, and Windows, with each build having an added, random-sized dummy variable in each system call. The existence of a random-sized placebo variable on the stack would make each build's buffer overflows occur at different addresses. Bingo, no more homogenous population of buffer overflows!
Shucks, maybe I should have patented that idea before letting it out...
About the word "if": If bullfrogs had wings, they wouldn't bounce around on their little green butts.
With Bill Gates as Chief Architect, I doubt that their products will improve much. His track record as a designer is terrible. Contrast him with Steve Jobs; Steve has a great aesthetic sense as witnessed with the Apple II, Lisa, Mac, Mac desktop, Next Step, iPod, etc.
Isn't that simply a ten dollar word for inbreeding?
Mit der Dummheit kämpfen Götter selbst vergebens.
Interesting article about the team that writes software for the Space Shuttles for NASA. Their approach is not a viable business model, but their devotion to quality is admirable.
. ht ml
http://www.fastcompany.com/online/06/writestuff
lists are code for LISP
scripts are data for scripting languages
We all use vonNeuman architecture machines these days. The machines which separated data and code were called "Harverd Architecture" and were abandoned long ago.
In short, their architectural problems stem from poor cohesiveness, and excessive coupling.
Loading assemblies with unverifiable code is a privilege
If normal users are not given the "Execute Unmanaged Code" privilege in a .NET environment, then how can normal users run video games? Or is the CLI efficient enough to implement digital signal processing and realtime garbage collection such as that required in video games as fast as unmanaged code?
Buffer overflows are not caused by C/C++. They are caused by lousy programming techniques and lousy programmers. Any language can be brought to its knees by crappy programming.
Didn't OpenBSD put the stack in memory pages that had the execution bit turned off?
Anyway: buffer overruns are not the only possible way to attack a system. Format string vulns are just as easy to explore; even though they are less widely known.
You may want to have a look at The Shellcoder's Handbook, by Koziol et. al. for the gory details. BTW, it's an excellent book!
cpghost at Cordula's Web.
he claims that it's the popularity and market share of Microsoft's products that are responsible
People have been hacking Windows with absolutely no problem from day one. Nice try.
I am NOT a number! I am a - oh wait, I'm number 761710. Look! 761710!
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.
.
If C/C++ is the culprit for all these problems in software, then what is to blame for all these problems outside of software?
English?
Everyone writes lousy software, only some learn more from their mistakes than others. If they are not writing secure code then they should go get some training on what 'secure code' is, because you can write it in almost any language, or not. The tool is not the problem, if you just don't understand what you are doing! Sorry, I don't take "excuses" when it comes to writing bad code, you either do a good job or you should find another profession, um, like washing Windows(tm) (I just love to watch the sparks and steam afterwards). The world will be a much better place with cleaner Windows(tm)!
This paper is almost complete rubbish. The bias against C/C++ is absurd. Why not blame the hammer for carpenters' injuries?
From my experience in the software industry, the biggest problem I have encountered is that management assumes that developers are unable to design any software. Instead they have business, marketing and sales people write up requirements (english majors who usually do not understand logic flow or coding). The requirements contain cases which totally break consistency and flow, creating possibilities for an error. Having worked at companies of various size, the larger the corporation the more non engineers control the design.
Another major issue is that the difference between good and average programmer is huge. Mixing of good and average programmers usually results in code that will have bugs. Average programmers don't always understand what good programmers do with their code and their additions often break the consistency of the code. This is a hard qualitative idea to explain, but I am sure many have been faced with it at one point in their life or another.
And on the final note: those that are not good at what they do always blame the tools for their problems.
How many times have I logged in to /. to find someone from a .edu account tell me my software would be better if I wasn't such an idiot and used to modelling technique developed by their research group, composed of individuals who have never written code outside of a class assignment. Gee, don't you think that if UML made the world's problems go away we'd all be using it?
Sure design and specification is useful, no one is saying you should just start hacking out a major product, but come on, bugs are going to happen and they are going to be things you didn't think of when you are toying around with your specification tool.
I had three big problems with the actual article: (1) C is not C++, there are subtle differences; (2) the problem isn't the C runtime libraries; and (3) C++ programmers have several techniques that avoid buffer overflows (using vectors instead of arrays, for instance). The C spec (like the C++ spec) simply says how libraries are supposed to behave, not how they are supposed to be implemented. In fact, the C++ spec permits a garbage collector.
"Garbage in-Garbage out." Miniscule Soft has a lot of garbage code. "A poor workman blames his tools." The Thane has many drones who are poorly trained. Two quotes, yes two. No one expects the spanish inquisition.
With this new information we should be able to eradicate all software bugs within a month. Thanks for your insight!
I'm a huge C fan, using it since nearly two decades in many application domains. I love C and know how to handle it. However C is not really well suited to less experienced application programmers. You can shoot yourself in the foot quite easily; not just once, but many times!
Anyone who considers writing non-system level software should really think hard if C or C++ is the best solution. Often a Python, Ruby or Perl program would do just as well, with the added advantage of being more rapidly developed, and more secure w.r.t. buffer overruns. If speed is a bottleneck, go ahead, and write parts of it in C. Of course, big stuff like, say, toolkits, libraries, high performance servers etc... should still be written in a compiled language (C or C++ would be just fine).
cpghost at Cordula's Web.
The critical thing for attacks isn't the percentage of the population, but rather the size of the population. The fact that some platform (Microsoft, C/C++) has reached the critical size where there's a lively body of hackers writing viruses and worms for it means it'll take a smaller population for other platforms to get attacked, because a lot of the attitudes and techniques are portable.
Let me point my finger and blame something too :)
The real problem with C/C++ are the standard libraries and string (char *) type! If the standard C string type and functions had length control/check, most of the buffer overflow problems would have been avoided.
Of course, there are some resource/speed costs in this solution, but the default should be having everything checked automagically. Let the few that need the extra speed spend extra time programming/using external libraries.
C++ string is quite safe in regard to buffer overflow, but many still use C libraries -- at least the C string libraries should be made unavailable by default for C++ programs. Damn, I can't even do in g++: string str("foo.bar"); ifstream file( str ); -- I have to convert str to char *!
As many pointed out, buffer overflows are not the only security problem out there.
ps.: have you ever checked the return code of a printf ?
'Notice how the only discussions shifting the blame of Microsoft's appalling computer security record involve extremely vague and inappropriate analogies?
What this article basically boils down to is the argument of "Windows appears to be less secure than other operating systems because it is the most popular, and therefore has the highest number of security threats."
A document published recently, "Security Report: Windows vs Linux" by Nicholas Petreley, contains an excellent counter-argument to this, based on evidence rather than theories.
Another problem with this article is that it compares organisms to computers, and doesn't even include computer users in the analogy. Unlike organisms, malicious computer code can be programmed to adapt to flaws in other operating systems, or, from the scope of the analogy, adapt to infect other types of organisms. In addition, Windows includes an automatic update feature, so in theory, Windows could even update itself and patch the flaw before a significant amount of damage is done. Furthermore, computer users will always have the power to protect their computer.
But as we all know, this never happens. Some of the reasons for this are:
Microsoft's security model and its implementation mean that Microsoft products are easier to crack. Just look at your ActiveX remark.
Here's a nice page about getting rid of some adware crap and how Microsoft makes it so difficult to do: (http://www.kayodeok.co.uk/weblog/200410/02/cws.h
That's where the infection rate comes in. It doesn't matter how many are written, it matters how well the spread.
There could be 10,000 viruses, worms and trojans written for Linux, but if they can't spread from machine to machine (due to Linux's security model), then they aren't a problem.
To me, that is what causes the problem. Again, if there are 10,000 viruses, worms and trojans, but they can't spread, there isn't a problem.
I'm sure more would exist. The question is, whether they would spread. If there is a 1,000x increase in the number of Linux viruses, does that mean a 1,000x increase in the number of infected machines?
Microsoft's #1 problem is their security model and the implementation thereof.
With Microsoft, you have to continually update your anti-virus signatures.
Why? A virus is a failure of the security model. Why are we patching a DETECTION system when Microsoft should be repairing the implementation.
The reason is that Microsoft cannot repair their implementation. Their security model is fatally flawed. All they can do is blame the end-user for not keeping a 3rd-party RE-ACTIVE detection system up-to-date.
Why hasn't the OS been evolved to be more resistant to these problems?
While there IS a buffer overflow problem with C, the real reason is Microsoft's ubiquity coupled with the ability to plugin third party executables and applications. BY allowing plugins to browsers, and office apps we leave the door open to malicious mischief if we don't know the originator of the plugin. By being ubiquitous, we make the spread of one malicious program that much easier. Users like being able to add to IE, Outlook, Excel, etc., and they like the fact that they don't have to test a wide variety of browsers and e-mail clients. Ubiquity is the ONLY reason Linux and Apple don't have widely distributed viruses and worms.
>he notes that the problem is largely with C/C++
>and mostly because of the buffer overflow
>problems.
I note "..that the highway death problem is largely with cars, and mostly because of the speeding problems."
If you use such a comparison, you can easily see the flaw in the statement.
The problem isn't with C++ it's the idiots writing the code with unchecked buffers.
Likewise, the car isn't the problem, it's the idiot driver.
C++, like a car, will only do what you tell it to. It can't think for you.
l8,
AC
s/talk/code/ and s/behaved/designed/.
Confucius say, "Find worm in apple - bad. Find half a worm - worse."
They have not provided a reverse compatible, but sandboxed environment for programs not specifically flagged as being XP ready (whatever that means).
Windows XP provides this. Press Win+L, switch to your most limited user account that you have created for purposes of testing unknown programs, and then run the program. When you're done, Win+L to switch back to your normal account and read the logs to see where the program threw permission violations.
Code not such flagged should be quarantined and restricted by the OS.
Microsoft already does this on its Xbox console. The unmodded Xbox won't run anything that's not specifically signed by Microsoft as being Xbox ready (whatever that means -- a licensed developer should know Microsoft's lot check guidelines in more detail).
He assumes that if everyone runs away from IE (or MS in general), that they will all be running to the same thing, and create another monoculture.
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.
In the article the author says, "When IE catches a cold, the networked world gets pneumonia". This is where the argument breaks down for me. If you extend the metaphor. When IE catches a cold, Microsoft responds like a country covering up a SARS epidemic. Microsoft may have hundreds of qualified programmers, but there are thousands on the internet ,that could help fix the problem in an open source atomosphere. Instead, they have a go it alone strategy, for fear of losing market dominance. I do not beleive we are affected by a monoculture, but more affected by not being able to participate in it.
Most of the Mozilla security issues I've seen are high-level issues (XUL, tabbed browsing, shell://).
The presence of ActiveX is a high-level issue, no?
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.
The point being that when you don't know what you'll eventually have to build, no amount of intelligence, forethought, or design will solve that problem. You build what you know you need, and flow along with changing requirements.
I don't think this is true at all. I think there are many cases where clever people can think ahead quite a bit and get a system in place to handle future unanticipated needs - because those needs typically fall into a known domain, where needs are not always completey unknown.
Why would a couple buy a house with four bedrooms for only two people? Because they might have kids. They don't know if the kids will like sports of computer games or what have you, but they provide a space with room to grow. And yes sometimes they have to move as that space is not enough, but the benefits of optimizing a purchase for future needs are readily apparent - and so it is with software where software that has a little breathing room in features to make changes later can be more productive than building only what you need at the moment.
The blessing and curse of software development is that everything you are doing is necessarily new in some way. If someone has done it before, why would you be writing it again? That combined with the push to solve the difficult problems in software rather than hardware (because software is *easy* to change!?) means each project is an exploration.
Why would you do it again... that's the million dollar question. But many people do. Even within the same company I have seen many simultanious projects spring forth, all doing the same thing.
But the clever can benefit from this, but looking over ground that has been pre-trod and incorperating ideas from these software forefathers into new designs.
And to the extent that the exploration is into more and more unknown territory, you need the steps of iterative and "agile" processes to get yourself a good feedback loop into your problem domain.
But sometimes it's better to go up a hill and take a look around to see what the problem domain really is and what it might be like, rather than taking things ones step at a time.
There are really not that many new problems being solved in software development, especially in corperations. I would almost say that an interesting methodology would be to start out saying "we are not using original ideas from any member. Instead the whole project will be composed of ideas taken from other projects. If you have an idea you must find an example of the idea in use before incorperation". Then design becomes a research effort.
"There is more worth loving than we have strength to love." - Brian Jay Stanley
Under NT you ARE an administrativer user, full time, when you are allowed to be one. And generally you have to be to run a lot of programs.
Compare to something like OS X or Linux where having admin access means you have the ability to use sudo with a known password - which you have to give before doing something to the system.
I know that's a simplification with how admin users in Linux and OS X work, but the point holds.
"There is more worth loving than we have strength to love." - Brian Jay Stanley
and pintos only blew up because they were popular.
Cwm, fjord-bank glyphs vext quiz
"he notes that the problem is largely with C/C++ and mostly because of the buffer overflow problems"
More accurately, brain-underflow problems.
Can someone show me a buffer-overflow problem that couldn't have been anticipated and avoided by a responsible, diligent, professional developer?
Yes, it's tedious, especially when having to use repeated reads for asynchronous input in TCP, but it CAN be done, if you can be bothered.
User-agent: isn't the only way to detect Wget. If a browser is getting more than n files per minute, if it's waiting a constant time between getting files, if it's not getting images at all, or if it's waiting a comparatively long time between getting an HTML page and getting its images, then it might not be an interactive graphical web user agent. If it's not coming from an IP block known to harbor Google, MSN, or Yahoo! spiders, then it might be an allegedly malicious spider such as a spammer's e-mail address harvester.
People have focused mainly on the C/C++ library issue Jeff Duntemann notes, but there are some JUST PLAIN WRONG premises set up by ol' Jeff.
First, that monoculture is a result of best of breed... Hey Jeff! Did you hear about the anti-trust case? When the browser is integrated into the desktop and shipped with every major hardware vendor's box, its not really best of breed is it. It's not really a choice. You use what you are given, and what the vendor/corporate IS/whatever tells you they will support.
Then you have the funny comment about Writing Solid Code. This book isn't on my desk. Yeah its given to every new hire at Microsoft so they can fit into the culture... but lets talk about that culture where you say they have "some of the best programmers in the world." I've been recruited by Microsoft twice. Suffices to say, I didn't sign up. I like to be empowered to do what I do best... and Microsoft does NOT promote that. Software development processes are the pervue of the individual project leads. Most leads at Microsoft are lifers who are SO involved in the culture, that any advancement in software engineering or best practices for software development are as foreign topics as igloos to pygmies. On the various projects I almost worked on, all of them had the same process. First, get marketing/management to set some deliverable deadline. Second, get 50 or so developers coding under a lead. (What about design?) Third, 2/3 of the way through, at 100 testers that end up coding to meet the deadline. Last, meet the deadline, or go back into the pool...
How the bejeezuz do you expect anything quality to come out of that process?
I also asked about code re-use when I was there... Surprise surprise, did you know that its actually not mandated that any software reuse any code? In particular, standard library code! A nameless project had no less than 8 different hash table implementations that all did effectively the same thing!
There are some old jokes that come to mind...
At Microsoft, quality is job 1.1.
If Bill Gates had a dollar for every time windows crashed... no wait, he does.
Microsoft: Innvoation through Assimilation.
and from my Microsoft mug circa 1986...
Microsoft: One company does it all.
/\/\icro/\/\uncher
- If it were that simple, than there should be no buffer overflows in modern C/C++ programs. But it apparently isn't that simple, for several reasons. Using container libraries costs extra time and effort, and it is less efficient than error checking that is built into the compiler, for example. Also, using container libraries is not something that the C/C++ compilers help enforce; that is, if some module doesn't use it, nobody ever gets warned about it.
False on ALL counts! Allow me to introduce you to the Better String Library for C and C++. This library handles strings and growable block buffers in general.- Because of its superior API (closer to higher level languages, and a superset of what C/C++ has to offer) it is Easier to use than the C/C++ alternatives. (The functions do more and do things that other languages have done with strings for a long time.)
- Because of its superior architecture (length delimited) and implementation (uses the fastest corners of the state of the art in C/C++ compiler technology) it is Faster than the C/C++ alternatives. (I've got the benchmark numbers to prove it)
- It comes with the optional bsafe module that creates link overrides to the standard C library functions where buffer overflows occurr most often and which are redundant to functionality in the Better String Library. I.e., deprecation of bad C library routines can be Enforced.
- And, of course, the API is completely buffer overflow safe.
This library has been thoroughly tested, its portable, its open source , and is currently used in projects such as Myriad and the Small Language. I assert that moving away from C/C++ in an attempt to escape buffer overflows is not only misguided, but unnecessary if you use the the Better String Library. The whole "using C/C++ inevitably leads to buffer overflows" idea gets thrown out the window if you are using it. I would encourage any C/C++ programmer to try it out before concluding that you need to move away from C/C++.The problem is bad architecture from the start. Its good user friendly ideas slapped onto a terribly insecure type of system.
The programming bugs and OS security holes are a big part of the problem. But what about the so-called "features" that Microsoft desides to implement. Or rather how they deside to implement them. I am refering to the Outlook script execution that leads to so many worms spreading through the internet and the Active X "feature" in IE that lets so many spyware/adware programs find their way into a computer. Even the Word script execution that led to the Word viruses a while ago.
If any of these "features" was indeed found necessary, (I'm not so sure that they all are) then they should have been implemented in a way that did not lead to so many security holes.
The programming language choses is of little importance when the actual design provides for the security holes.
-- ssoorrrryy,, dduupplleexx sswwiittcchh oonn.. -Quote found on actual fortune cookie.
Mr. Spock was the character from Star Trek.
Dr. Spock is the author of books about raising kids.
I don't have the time to read through every post here, so if somebody has mentioned my point already, I apologize.
It seems to me that author of the article is stating that because both IE and Firefox are written in C/C++ that they have the same vulnerabilities. If this were the case, wouldn't Firefox be susceptible to the same attacks as IE?
Subj: Letters to the Editor Re: The Lessons of Software Monoculture http://www.sdtimes.com/opinions/guestview_113.htm I believe your article lost a lot of credibility with the line "What we have to understand is that our current problems with Internet Explorer have less to do with bugs than with success." So many make this mistake, it is easy to fall for the FUD that comes out of Microsoft. If this were true, then why is it nearly all of the severe and remotely exploitable web server hacks happen to Microsoft's IIS? Apache runs nearly 70% of Internet web servers, while Microsoft is a minor player at 21%. http://news.netcraft.com/archives/web_server_surve y.html
While Apache users did have to deal with the Slapper worm some time ago, the high-profile IIS attacks are endless. Worms and other attacks against IIS have been blamed for a regional power outage, rendering ATM's across the country useless, and taking out entire airline operation centers to name a few. "But then what happens if Mozilla or the Mac get too popular?" you say? Apache is 'too popular' now, and has been for some time. But I don't see Apache in the headlines over...and over...and over...regarding vulnerabilities.
Yes, nearly every piece of software has it flaws. But only Microsoft can stake a claim of costing society billions of dollars. (With IIS flaws alone)
Sendmail delivers the majority of the Internet e-mail. There are competing e-mail solutions from GroupWise, Notes, on down to Eudora and a plethora of other POP3 clients. But why is it every e-mail virus is referred to as a Microsoft Outlook virus? Have you ever heard of a GroupWise virus? Any worm attacking Mozilla Mail?
Word Perfect used to be the King of office suites, before that it was WordStar. There are still numerous alternatives to MS Office out there, with Open Office being the media's darling at the moment. But have you heard of anything called an "X" Document Macro Virus where "X" has equalled anything other than Microsoft Office? Microsoft macro viruses were infecting PCs long before MS totally dominated the office software sector.
In light of this, do you _really_ believe the "Microsoft is such a big target, that's why they suffer from all the bugs" FUD?
This guy is nothing but a mouthpiece for Microsoft C#. The real problem with C/C++ is it has libraries developed by comities. The industry is polluted with poor programmers in general because no-can-do professors insist on using Java to teach under graduate computer science.
Recall that most of the security bugs and buffer overruns in applications come from the standard runtime library (CRT) and NOT the native NT or Win32 APIs. Dinkumware and/or Microsoft could have done a much better job wrapping the CRT around Win32 here. And while I'm speaking out, the STL implementation that Plauger built is an absolute abomination (i.e. horse shit).
Microsoft did not need to "invent" another language (Microsoft C#) - they needed to innovate a better runtime library, period!
Perhaps Jeff's blame on the C/C++ language itself should be directed elsewhere.
-MerkX
I reckon this is in relation to a growth problem. Bugs start because code that was designed to do one thing is used for a variety of other things. Causing a component/function/method that was orginal designed to do something little ends up being a core function. E.g I wrote a function to check if a directory was a sub directory of another directory. (For a very small app that I was using on my desktop only) so there was very little error checking on the directory names. Now a little later on another nameless drone (developer) need to check if a directory was a sub directory so they copied the function from my code and started using it on a production system. Before you know it that code is being hacked by evil doers... Not really my fault is it ?
Formal methods, although useful, are not a silver bullet for producing bug free code. They may help to reduce bugs, but they cannot eliminate bugs completely. To quote Frederick Brooks from "No Silver Bullet: Essence and Accidents of Software Engineering" "Much of the effort in modern programming goes into testing and the repair of bugs. Is there perhaps a silver bullet to be found by eliminating the errors at the source, in the system-design phase? Can both productivity and product reliability be radically enhanced by following the profoundly different strategy of proving designs correct before the immense effort is poured into implementing and testing them? I do not believe we will find productivity magic here. Program verification is a very powerful concept, and it will be very important for such things as secure operating-system kernels. The technology does not promise, however, to save labor. Verifications are so much work that only a few substantial programs have ever been verified. Program verification does not mean error-proof programs. There is no magic here, either. Mathematical proofs also can be faulty. So whereas verification might reduce the program-testing load, it cannot eliminate it. More seriously, even perfect program verification can only establish that a program meets its specification. The hardest part of the software task is arriving at a complete and consistent specification, and much of the essence of building a program is in fact the debugging of the specification. "
Hmmm.. That's an interesting statement. The standard is more pervasive, yes. But any single implementation? No. Apart from Microsoft's ;)
A monoculture is heavily structured on fixed rules.
These rules may be used to the detriment of said monoculture. (In mathematics, the concept applied here is called diagonalisation.)
The complexity issues in working around any flaw in the basic programming of the system, no matter how minor, will quickly balloon out of control.
The only way to properly address these issues is to work from scratch, being very careful not to make wrong moves that cannot easily be undone.
John_Chalisque
The problem with a lot of programmers is they take something like stdio and think that's how it should be done. ie: FILE *file=NULL; char buffer[256]; file=fopen(filename,mode); if(file!=NULL) { fread(buffer,256,1,file); /*or worse fgets(buffer,256,file)*/
fclose(file);
}
First of all the buffer isn't dynamic and not wrapped or protected in any way.
Second, if I read over the end of the buffer without remembering the allocation size I'm screwed.
The buffer is never zeroed, so I don't know what's
in it to start with.
For a lot of programmers this is the normal technique. No structured data, lots of global variables, no planning, no modularity, no modular testing, no error checking, no code documentation. Spagetti!
Let's hope they're not working on anything that's mission critical, like medical life support equipment.
For once there's a level-headed view of the current security problem that isn't written by another Linuxhead mouthing off. Phew.