Slashdot Mirror
Microsoft vs. Computer Security
ArieKremen writes "The Slate has a piece written for the average user attempting to explain why Windows is `still` grappling with security issues. Although Gates made security and privacy top priority four years ago, not much progress has been made." From the article: "Microsoft customers haven't stopped worrying. A year later, Windows was hit with several nasty worms, including Slammer, Sobig, and Blaster. The viruses caused major traffic bottlenecks throughout the world, which cost tens of billions of dollars to clean up. Vulnerabilities deemed 'critical' have forced the company to release an almost unending stream of patches and fixes to the Windows operating system, Microsoft Office, and Internet Explorer." An interesting look at the whole issue.
Their solution about how to shore it up: don't use IE, Media Player, Outlook, etc.
I hate to sound like a kid, but DUH!
Given, I use Firefox, Thunderbird, and other non-Microsoft programs because I like them better and they tend to work better, but the fact that they're less likely to compromise my system is also a consideration.
Note, though, that I say less likely. We have had bug/security fix releases of Firefox and there was a brouhaha with the GreaseMonkey extension inducing a vulnerability, BUT for the most part it seems the fixes were less frequent than with IE-related patches, plus they usually only compromised the browser, not your whole PC.
That's the big problem with many of the Microsoft glitches. They're not limited to the vulnerable Microsoft application. The vulnerable app provides a gateway for compromising the whole PC.
- Greg
Start a happiness pandemic
It was noted elsewhere that Microsoft spends six billion a year on R&D. If they hired mathematically-inclined software engineers at 100,000 a go, they'd be able to keep a small army of 10,000 such programmers. You can probably reverse-engineer a specification, prove, then re-engineer the code for about 10 lines an hour. Assuming a 40 hour week, that means they could formally re-engineer 208 million lines of Windows per year. Even with all of the standard applications, libraries and utilities, the team should have an iron-clad damn-near-bugproof Windows within 2-3 years. It wouldn't cost them any more than they're already burning on patents for stuff nobody else cares about, and would save three times the total cost of the bugs to the country within a single year.
The overflows are easier. You compile all the applications with something like ElectricFence, dmalloc, or some other debugging malloc. A few tests at Microsoft should then collect a lot of the overflows. You then recompile such that the debugs won't cause fatal errors but will still generate alerts. You have the Windows error reporting tool collect all those alerts and either notify the user at the time & allow them to send, or send in bulk on the next major error. Microsoft can then fix the overflows BEFORE someone exploits them, because the odds are high that they'll be accidentally triggered long before any black hat learns about them. If only because there are several hundred million users, and most will be trying to do things that are impossible or - at the very least - seriously warped.
Of course, they could also get a copy of the Stanford Code Validator, or even just download a copy of splint off the Internet. Both would pick up the majority of coding errors and allow Microsoft to fix them.
Regardless of which of these solutions is used, a company the size of Microsoft should be able to completely and utterly clean their software of 98%-99% of its defects within three to four years. As the article noted, it has now been over four years since the proclamation of taking security seriously, but yet there is no sign of any kind of rigorous campaign to really erradicate faults. Rather, there seems to be much more of a campaign to make users more accepting of the fact that there are faults.
Not everyone can guarantee 99% fault-free software within a reasonable timeframe. There aren't the mathematician/software engineers, for a start. However, maybe it would be possible to have a standards authority that could certify a software product as "mid-grade" (50% bug-free), "high-grade" (75% bug-free) or "mission-critical" (99.99% bug-free). Software providers could elect whether or not to be certified and consumers would then be free to decide how much quality they want to pay for, because they'd know how much quality was there. Consumers would also be in a stronger position to interpret the lack of such certification.
Thoughts?
It's a small world and it smells funny; I'd buy another if it wasn't for the money; Take back what I paid (SoM)
They often become vulnerability vectors, and it is admittedly difficult to take a company seriously that says that they are interested in making a secure system when they cannot even factor that into the "cost of doing business". That's a nice philosophical point, but philosophical nonetheless. If I follow your logic then Firefox would have had zero vulnerabilities the day it was released, and that's not the case now, is it? The "many eyes no bugs" mantra goes south in a hurry when you have a 10-million line codebase and a few hundred actually qualified people looking at it.
Post hoc, ergo propter hoc: One doesn't follow the other.
Having the code available means a larger number of people can find vulnerabilities and a larger number of people can contribute fixes. It does not follow that a less vulnerabilities will be found, although it might follow that a less number of vulnerabilities will be exploited.
However, it may also be that the reason a less number of vulnerabilities are exploited are due to the lower deployment size.
Consider then Apache which has a larger deployment than IIS but fewer critical vulnerabilities. They didn't, but they do now. Server 2003 ships seriously locked down.
That's still under debate, although I suspect you'll refer to your first argument for rationale. Yes... no one writes applications for Windows because its design is "obfuscated". Yes.
Very few people write applications that directly compete with Microsoft. There you go again with the philosophy.
By having additional lockin, Microsoft surely makes it harder for people to compete with them. This does indeed represent a security risk because formats, when understood, can reveal a great deal of information about the programs that interact with them.
In general programs that parse more, tend to have greater bugs.
By intentionally attempting to make their formats more complicated, they have certainly blocked compatability, but they've also decreased security by (again) making their software more complicated. First you complain on (1) that they don't fix bugs to avoid breaking applications and now you postulate that they break compatibility whenever they feel like it so that it works only with theirs. Which is it?
The parent doesn't postulate that at all. You are again exhibiting faulty logic.
By altering the operating system to meet the needs of the applications, they are introducing more parallel, nearly identically developed subsystems, all with increased potential for bugs. This does indeed cause security problems.
It's funny this should come up. I wrote a response to someone's newsletter earlier today.
Here's what amounts to a primary copy|paste:
As far as things loading slowly, a lot of it has to do with the code which is being loaded. In many shops, things such as code reviews are non-existent. And when they occur, they're cursory at best. Programs written in Visual Basic don't have "Option Explicit" (requiring you to declare variables) and when you force someone to add it, it won't compile. One of the biggest gaffes Microsoft made was for programmers to make declaration variables in this fashion. It should be the other way around: force the declaration of variables unless you turn this off. This is a subtle, but crucial indicator of their internal decision-making system and vision.
And speaking of Microsoft, "Patch Tuesday" would be a shadow of its former self if they learned one thing in programming: buffer overflow For those unfamiliar with the term, it means permitting someone to type more than a variable is allocated to handle. The extra characters then alter the program's execution, including turning scenarios turning complete control over to someone running the software. There's a lot of humor about the questions Microsoft asks in their interviews; "Why are manhole covers round? How many gas stations are there?" My joke has become, "Demonstrate code which handles buffer overflows [because we don't know how to do it]".
Gates attempted to demonstrate the priority of security by publicly declaring all software development to be put aside and focused entirely on security issues in February 2002. (Google has started a new event known as "Summer of Code". Students are tapped to gain real-world experience and write OS (Open Source) code during their Summer breaks. I've since referred to Microsoft's dedicated activity aas "Month of Code". Has the error profile changed? No. Has the number of errors changed? Yes. More software on the market with the same error foundation means there are more copies of that problem in everyone's hands. It's not a trick question. Were their code architecture to prevent retro-fitting the solution, they could build it into each no product to hit the market and you'd see the patch count drop over time as new products were released with the underlying fix. This is not a particularly difficult technique to implement and wouldn't add a significant change to their schedule. In fact, the time factor would approach the current schedule as they become familiar with the mindset.
Why don't they do it? No one knows. Programmers with no more than three or four years of experience have learned this shortcoming is the reason Microsoft software is so buggy. And this is without access to Microsoft's source code. No one has put the question to Microsoft. Put their foot down and asked why this is company-wide shortcoming exists. Everyone (media) seems focused upon where Microsoft is going and perhaps afraid they'll commit seppuku (suicide) if they really push it. And if they requested time to investigate it, they should have an answer after a reasonably short period of time, removing, "We'll have to look into why this isn't done" as a response. Were this single issue to be addressed across their product line, I would estimate 98% of the currently reported errors would vaporize. That's not to say a new class of bugs wouldn't develop, but almost all of the reported errors today have a big gathering at every family reunion. We're not dealing with sudoku here; besides, standard sudoku is single digits.
Shortcomings aside, Microsoft has started one internal program: "Blue Hat" - annually bringing hackers in and showing how easy it is to peel open their vaunted software. Apparently, they expected a rah-rah session the first time and it was heard the gasps increased as the spirits fell.
Today's Quiz.
Name each quotation's author.
1. "Success is a lousy teacher. It makes smart people think they can't fail."
2. "People
I work at Microsoft.
The other day, we had to have a little talk with one of our developers; he didn't understand why it was bad that his application generates an error message that writes the administrator password to the Event Viewer logs. What was that I heard about every developer being thoroughly trained in secure coding practices?
Even though security is supposedly top priority, we find ourselves unable to force our developers to adhere to policy and write code that can run under a non-admin or non-system account. The higher ups steam roll over us when we fight the fight.
The problem is that there are two groups at MS; the business side, and the technical side. The business side calls the shots, and they don't listen to the technical side.
Sure, there's plenty of talk about security, but no real action. PR is cheap.
"The whole article is a troll....Its filled with 'feelings' and 'impressions' by people cited as experts, without examination of their claims - nor an inquiry to factual matters."
The article is correct. The reason it is not filled with objective evidence is because there currently no objective, agreed upon method of measuring code or system security. In the absence of objective data, the opinions of experts are the best thing we have.