Microsoft No Longer a 'Laughingstock' of Security?

Toreo asesino writes "In a Q&A with Scott Charney, the vice president of Trustworthy Computing at Microsoft, Charney suggests that security in Microsoft products has moved on from being the 'laughing stock' of the IT industry to something more respectable. He largely attributes this to the new Security Development Lifecycle implemented in development practices nearly six years ago. 'The challenge is really quite often in dealing with unrealistic expectations. We still have vulnerabilities in our code, and we'll never reduce them to zero. So sometimes we will have a vulnerability and people say to me, "So the [Security Development Lifecycle (SDL)] is a failure right?" No it isn't. It was our aspirational goal that the SDL will get rid of every bug.'"

Comments

rear-view mirror

[Anonymous Coward]

Inasmuch as this constitutes any sort of admission that Microsoft products were not always exemplars of good security, it should not be forgotten that Microsoft has always insisted that they were.

So really, they are not saying anything different than they have always said. "Back then" when their products were insecure, they insisted that their products were secure. Now, they are admitting that "back then" their products were not secure, and are continuing to insist that their products are secure.

Why should we believe them? Once bitten, twice shy, and with good reason.

I say, set a standard

[downix]

I'm thinking (in part to stroke Theo's ego a bit) set OpenBSD as the security standard out there. Every OS, compare it security-wise to OpenBSD. Put a "percentage" for how secure, then we can see hard numbers for how securly an OS is out of the box.

Of COURSE they're not the laughing stock...

[15973]

...now if you'll excuse me, I have to go delete the spam that was sent from a botnet of computers that are running a series of a particular OS that shall remain nameless...

A good example - IIS

[duplicate-nickname]

I think a good example of this is how many security problems have been found in IIS in recent years. For example, go to the MS Security Bulletin site and look up bulletins for IIS 6.0 compared to IIS 5.0 -- http://www.microsoft.com/technet/security/current.aspx.

There are only two "Important" bulletins for IIS 6, while IIS 5 has almost 30 bulletins over the same inital time period. It is amazing how far IIS has come since that nightmare that was IIS 4.

Re:A good example - IIS

[asuffield]

There are only two "Important" bulletins for IIS 6, while IIS 5 has almost 30 bulletins over the same inital time period. It is amazing how far IIS has come since that nightmare that was IIS 4.

You do realise that you are measuring the "quality" of IIS by counting the number of security flaws that Microsoft will admit to having fixed?

You're not counting the number of known flaws. You're not counting the number of flaws that Microsoft knows about. You're not even counting the number of flaws that they've actually fixed. You're interpreting this change in the numbers as indicating an improvement, when it might just as easily indicate that they fix less flaws than they used to.

And don't forget that Microsoft has a long history of not bothering to fix security flaws until significant numbers of exploits have been noticed in the wild. We can only guess at how many unfixed flaws there are in IIS today.

Re:STILL the Laughing Stock!

[Bill Wong]

And you still can't run IE under a separate user account.

Uh, sure you can?
Shift-Right-Click -> Run-As -> The-Following-User?
I do it all the time...

Re:my opinion of MS security

[BUL2294]

Unfortunately, Microsoft's security problems are masked, not fixed. Seriously, software firewalls should not need to exist. All software firewalls do is cripple other code running on the OS (drivers, services, programs, etc). Fix the underlying code and don't default to running services that home users will never need and, presto, no need for a firewall...

Someone at M$: "XP with IE is full of 'critical' security holes."
Someone's manager: "Let's write a firewall and we can get away with calling those security holes 'important' and not fix them."

Windows APIs are inherently insecure.

[argent]

The biggest problem is, of course, the HTML control.

Until Microsoft abandons the entire "security zone" model and makes the HTML control default to a secure or "closed" state completely under the management of the calling application Windows security will never be anything but a joke. The recent hole in Yahoo Instant Messenger, for example, is primarily Microsoft's fault... because the "security zones" should not be able to "fail open". Blaming Yahoo for not 'sanitizing' the input is nuts.

No other HTML rendering library works this way. The two leading alternatives... Mozilla's Gecko and KDE's KHTML (and thus Apple's Webcore)... both implement a closed sandbox. If an application wants the page to have more capability, it must explicitly install hooks to grant it that capability. This way when an application renders a page using Gecko or KHTML there's no possibility of there being prepared holes to attack. In addition, when they DO install a controlled hole in the sandbox, they know that they're the only agency doing so... there's no concerns about some insecure ActiveX control in the system becoming an avenue of attack.

Until Microsoft completely changes the API for the HTML control they won't solve their image problem, and they shouldn't expect to... because until they do this, they have a problem and the image only reflects that.

ActiveX use in the HTML control, of course, is completely insane. Given all the layers of bandaids and patches and dialogs and settings and security levels wrapped around them, it's actually less effort to explicitly install a plugin than to open IE up to the point where you can use a "trusted" ActiveX control. They need to deprecate and eventually eliminate this.

There are other problems, too. Applications have to parse command lines completely, using their own code to break them up into arguments and perform wildcard expansion. Both OS X and Linux use the UNIX "exec" call, which doesn't require the application to add this additional evaluation step. Many of the "URI" related holes found in applications on Windows... including several recent ones involving IE, Firefox, and Second Life... are due to this flaw in Microsoft's APIs.

There's a second flaw in their URI handlers, and that is the inability to separate internal handlers that may expose more powerful capabilities than a sandboxed object should have access to with the ones that are designed for use by untrusted documents. The 'patch' to fix this is to try and sanitise the list of URI handlers that each application will use. This, like any other "sanitization-based" approach, is inherently flawed. They need to create a second registry that only supposedly secure applications will use... and then they won't need to worry about web pages containing links to ".CHM" files.

(Apple, by the way, has copied this flaw from Microsoft. But at least they don't share the rest of the burden)

The lack of a standard mechanism to bind network services to specific interfaces is a third problem. In UNIX most network services have traditionally been run from inetd, so if you replace inetd with something like xinetd or tcp wrappers you can prevent services from listening to anything but the local interface "localhost". This means that a firewall on UNIX is an extra defense, where on Windows it's the only way to keep insecure protocols from accepting connections from external sources.

For Microsoft to get the same reputation for security that UNIX based systems have earned, it will have to correct these flaws. The easiest way, perhaps, would be for it to BECOME a UNIX-based system. It wouldn't take much, so much of the API is already inherited from Microsoft's one-time infatuation with UNIX, and they ship a subset of teh UNIX API with Windows in the POSIX subsystem.

Or, though it would be less desirable from the point of view of people who have to write portable code, they could implement their own secure APIs and make the existing ones a deprecated and eventually optional add-in.

But so long as they keep the current API unchanged in all details, though, they can not solve these problems they're faced with.

Re:MIcrosoft guy says MS's security is ok?

[TheRaven64]

SunOS was famously insecure, as was Irix. Why pick on just two vendors. It wasn't until the '90s that anyone could say 'UNIX security' without laughing. Take a look at the CVS logs from the first year of the OpenBSD project, when they first did a full audit on code much of which dated back to the original BSD UNIX, used as a base by a lot of commercial UNIX vendors and found hundreds of vulnerabilities. Now, OpenBSD enjoys a good reputation for security, but it's taken over a decade of continuous code auditing to get there.

Phone Quality

[PackMan97]

It's funny, I grew up with a phone infrastructure where I never experienced a dropped call -- granted, a less complex (wired) achievement, but had "wired" phone service been invented today, I suspect the standard would have been "less dropped calls", too... because maximized profit dominates the industries' collective motivations, not quality products.

What's really funny is that 20 years ago, wired long distance carriers were waging advertising battles over who had the clearest call. Sprint's "Pin Drop" ads probably set the bar in this respect.

So, while you take the wired phone service for granted, it hasn't been that long since call quality was a very important part of a consumers purchasing system.

Go back another 20 years to the '60s and you still had a significant portion of the phone network that was manually switched by human operators.