Slashdot Mirror
Microsoft's Goal, Security Through Obscurity?
dave cutler writes "Salon has an amusing little wire article claiming that Microsoft argues that were
they to provide any greater technical detail about protocols and APIs, it would make computers running their operating system far more vulnerable to cracking attacks." Update: 05/09 13:59 GMT by M : The benefit to customers of Microsoft integrating internet services into the operating system, as well as Microsoft's commitment to security, are exemplified in this article which notes yet another remote root hole in Microsoft's code.
Makes you wonder if these things aren't being spun out to get people to use the latest version of MS's products - if for no other reason than to make their systems secure.
Don't use 3d party stuff. Use the latest from MS. It's secure this time. We promise. Really.
Vaguely reminds me of auto glass purveyors out in a parking lot with a bat.
Salon has an amusing little wire article claiming that Microsoft argues that were they to provide any greater technical detail about protocols and APIs, it would make computers running their operating system far more vulnerable to cracking attacks.
It would. It's not a good excuse, but it is true. In the short term, Microsoft cracks would increase.
The OSS community typically acts a lot more quickly than Microsoft has on security problems... when security flaws are found on Windows the patches usually take longer to release.
Also... security flaws under *NIX systems usually are limited to one service... not the Internet Explorer/Outlook Express/MS Messenger Core OS holes that seem to plague MS since everything is so entwined.
Yeah they have the concept of root, it is just implemented for every user.
"...Microsoft doesn't even have the concept of Root."
No, not quite true. Microsoft (Win9x at least) doesn't have the concept of any user type except root.
Once more unto the breach, dear friends, once more, Or close the wall up with our American dead!
However, what most people miss is that obscured code STILL needs to be audited by a neutral third-party. This is where Microsoft fails - they don't appear to have their code audited. Or, if they do, their auditors should be fired.
Security through obscurity should also not be your ONLY parameter. An obscured system should still be using encryption, should still be testing input, and shouldn't have any buffer overflow exploits.
Obscurity can be used effectively. It's not a do-all, be-all, and end-all.
Of course, since Microsoft's API's are still hidden, we don't know whether or not they're using obscurity as their only model. However, it seems, from the alarming number of remote root exploits available it seems evident that Microsoft's claims for obscurity of their API's as a security measure is the only measure that they're taking. Which leaves one of two possibilities:
I tend to believe the latter. But giving them the benefit of the doubt, we can only argue against the former. Which is that trusting your business to Microsoft's security practices is a very risky proposition.
Key to financial independence: Spend less than you earn. Save and invest the difference. Do it for a long time.
If these security vulnerabilities are so easy and obvious from reading the APIs, then why can't Microsoft's programmers find and close the security holes before someone finds them? Don't they read and adhere to their own APIs?
If releasing the APIs means someone is going to easily figure out a way to damage the system, that just demonstrates that Microsoft isnt even trying to secure their products.
Darth --
Nil Mortifi, Sine Lucre
It's my impression that those holes are, in the large majority of cases, discovered by people auditing and examining the code. The auditors then publicize the flaws. I frequently see advisories of the form, "no known current exploits, but..."
On the other hand, security flaws in Windows seem to become publicised when they are used in an attack, too late for many.
PHEM - party like it's 1997-2003!
The problem is that selling your software to most of the computer users in the world means it's not really obscure. Security through obscurity only works if the system doesn't give feedback to attackers. Letting people run the software themselves is like playing mastermind with your passwords: it will still take people a little while to break them, but it is by no means secure.
Security through obscurity has a place in unique, locally developed systems which only grant access to trusted users. In a commercial product it is nearly useless.
Root user, no.
:)
Concept of root - absolutely.
Root is basically a user that can do whatever he pleases with no restrictions (or without restrictions that can't be overridden or removed)
non-NT based windows every has absolute access
NT based windows, administrator has this access.
Think of root as a metaphor
DOS is dead, and no one cares...
If there's a Bourne Shell, I'll see you there
I firmly believe that software should be held accountable to liability laws and consumer rights laws.
That would kill all free software. People could personally sue Linus for bugs in the Linux kernel that caused them problems: "I'm seeking $10,000 in damages because your stupid bottom handler for my POS Promise IDE controller caused me to lose all my data!". The listings on freshmeat would be a pool of future clients for lawyers, and not software projects. Amateurs wouldn't release code for any use whatsoever.
In short: that's a realy, realy, really, really bad idea.
The wheel is turning, but the hamster is dead.
"I guess it's a matter of how hard you make it," Allchin replied. "We have to work on our reputation for security in the marketplace." from Jim Allchin, who oversees the Windows operating system.
This perfectly demonstrates the M$ sekurity mindset - they approach security problems as a PR problem NOT an actual usage or safety issue. What he SHOULD be saying is, "As the dominant OS in the consumer space we need to work to make our OS the most secure for our users because they are the biggest target and the least aware of the threat."Instead he's blathering about their "reputation" instead of actual security.
Bottomline is that M$ doesn't care about security - they only care about there reputation for security. Hence to them obscurity IS security to them and it becomes policy and is encouraged.
=tkk
Bill Gates - Creationist?!?
Microsoft argues that were they to provide any greater technical detail about protocols and APIs, it would make computers running their operating system far more vulnerable to cracking attacks.
I'm not sure about the depth of the State's API and protocol information requests, but this is a perfectly valid statement if you assume detail means code, and it applies to OSS as well. By providing your source code, you provide black hats with an easily accessible opportunity to find your mistakes and use them against you. This is a fact you cannot avoid.
Of course, just describing how your protocols or APIs work should not be a security risk in most cases, unless MS has cut too many corners. As to whether we would see a noticeable increase in MS exploits, your guess is as good as mine.
"The area of penetration will no doubt be sensitive." ~ Spock
IANAL, but I believe that a good bit of OSS would be exempt... why? Because it's not sold and thus does not fall into the "intended purpose" bit of product liability laws.
Red Hat, Mandrake, and others that do sell a product would become liable though, and that'd certainly kill them.
I think that liability with a broad brush would definitely be a bad idea. But negligence is another matter... some of the exploits could definitely be shown as negligence on the part of the software maker (e.g. - you were informed of this exploit 5 months ago and failed to remedy it). This isn't just MS either - Sun, IBM, etc. have all had times where they failed to release a security patch within a reasonable time period after being informed of a vulnerability.
That kind of thing should definitely result in liability on the part of the software company. Similarly, applications that have destructive bugs and don't get fixed should result in liability.
The problem becomes one of defining how long is "long enough", and what should the fines be? Realistically we don't need new laws here. We just need to apply some old ones to a new situation.