Posted on 05/29/2002 8:21:28 AM PDT by Dominic Harr
By Tim Mullen
May 27, 2002
The success of "SQLSpida," the worm that targets MS-SQL servers set upon the Net with a blank "SA" password, is testament to how badly basic security education is still needed.
As always, I place primary blame on the administrators of these boxes-leaving the SA password blank on any installation is a rookie move. To do so on a production machine placed on the Internet is just plain stupid. You have probably guessed that my use of "primary" infers a secondary party in responsibility; and indeed it does: Microsoft.
Microsoft has been riding the fence between marketing a concept of "trustworthy computing" and delivering a product that caters to the least common technically proficient denominator. Most products have been specifically designed to allow anyone who can click "Next" to perform a successful installation, but when it comes to their defense of insecure default software settings, they have a matter-of-fact way of telling everyone that they should know better.
For instance, Microsoft knows that the default application extension mappings in IIS are deadly, and we are blamed for not removing or remapping them; yet they are all enabled by default, and one must drill down deep into the interface to turn them off. In default installations of SQL, the SA user can perform remote system-level functions, yet they allow the password to be blank, and they don't even give us the functionality of renaming the account. Administrators are expected to set proper ACL's on system files, but even in their Advanced Server product, Microsoft assumes the admin to be so inept that Windows Explorer hides the contents of the WINNT directory so that the user won't monkey with them.
Litchfield says he provided fully-functioning exploit code to Microsoft, and it still took them a week to respond with simple confirmation they were able to recreate the issue.
It is time for Microsoft to start shipping products with more secure default settings, and to require a certain level of expertise from the administrators of these systems.
Vendor Notification Alerts
But safer out-of-the-box settings are not the only thing we need -- clouds continue to billow on the vulnerability landscape. Too many software vendors are so busy working on the Next Big Thing that they are unnecessarily putting their customers at risk by sitting on security patches for their current products.
If you are not familiar with David Litchfield or Next Generation Security Software, then you should be. Litchfield probably has the world record for discovering the most buffer overflows. And like many other security professionals, he won't disclose details of his exploits to the public until the vendor can release a patch.
But how long is one to wait for the vendor the get their act together? How long must customers' systems lay in wait of exploitation before a patch is released?
Last month, Litchfield discovered a remotely exploitable vulnerability in Sun's iPlanet. Though Sun has already developed a patch for this critical issue, Litchfield says, they have decided not to release it until the end of next month so it can be included in a rollup package. So much for customer service.
And if you think the current scans for SQL Server are high, you ain't seen nuthin' yet. Litchfield has also discovered a heap based buffer overflow in SQLServer 2000 that allows an unauthenticated attacker to gain remote control over the server in the context of the SQLSERVER service. Just the mention of this type of exploit makes a blackhat's mouth water in Pavlovian response.
But even though he provided fully-functioning exploit code to Microsoft, Litchfield tells me it took them a week to respond with simple confirmation they were able to recreate the issue. This is simply unacceptable. Litchfield claims similar discoveries that even eight months later have still not been addressed by Microsoft.
Enter the Vendor Notification Alerts (VNA). Litchfield has decided to roll out an interesting vulnerability alert system somewhere between "full" and "wait for a patch" disclosure.
These VNA's will disclose the vendor and problem product, along with general exploitation protection methods, without giving away too much detail about the vulnerability itself. In this way, the heat can be turned up on the vendor and customers can be alerted to the fact that problems exist, but a blackhat won't get enough information to design an exploit.
To date, 15 such issues exist with other products, including more issues with Oracle, and can be viewed on NGSSoftware's web site.
In addition, Litchfield's "Typhon II" vulnerability assessment tool will have checks for most of these vulnerabilities built into it. Though I'm not one to make public endorsements for commercial products, I can tell you that purchasing a product that alerts you to problems vendors haven't even addressed yet is most definitely a smart thing to consider.
Any successful company knows a customer's interests should come first. If the timely distribution and maintenance of critical security patches for their products is too much for a vendor to deal with, they should get out of the software business. Hopefully NGSSoftware's VNA idea will catch on, and patch production can take priority without exposing the customer to unnecessary risk.
And there in lies your biggest problem -- all good developers will be very critical of software with flaws. And MS has a lot of software with a lot of flaws.
So in your mind, MS needs 'yes men' salesmen like you and B2k, not 'critical' software developers.
It'll be interesting to see how far such a strategy will go.
I'm about bored with your sales pitch, so unless you've got something new to add . . .
What you don't understand is a lot.
And since I know you've been explained the truth about the JCP by several people, your lack of understanding is clearly cultivated.
Oh well, you know what they say: "It ain't done til Lotus won't run".
Aren't you proud of your Brittney?
I'll take the young new thing over your old hag, any day.
I and about a dozen others have tried explaining this to you, and you still refuse to admit the truth, so I'll leave you to your denials.
And I've criticized Sun, Apple, Oracle, HP, and MS loudly and regularly here on FR.
You know, ironically, that 'never criticize MS' attitude that is likely the single biggest cause of MS's quality problems. A good developer is, by definition, required to see and admit flaws in their products. That is the only way to *fix* flaws. So by selecting it's employees based on their 'yes-man' attitude, MS is stuck with a bunch of developers who can't admit bad things about MS or MS's products. This means they can't fix what they don't admit exists.
Hence, MS software has about ten times the bug rate of other companies. MS even has more bugs that Oracle, which is saying something.
Oh, yeah -- you don't admit to any of this. You don't see any MS quality problems. You believe that all this talk about MS quality problems is just "anti-MS hate speach" by "ABM Bigots". You believe there is a "vast conspiracy" out to get MS, and that MS is the "innocent victim" in all this.
In spite of Mr. Gate's directive to stop being blind to internal quality and security problems, you're still locked into pure denial mode.
And, "It ain't done til Lotus won't run"!
A "small number"?
Remember recently, at the Security convention, when the crowd laughed at the mention of MS's "Trustworthy Computing" intiative?
So you think only a "small number of misguided folks" consider MS's quality to be poor. Funny! You're the one in the minority, a small 'clique' of MS-funded yes-men who can't admit unpleasant truths about their corporate masters. Interestingly enough, it's the same small 'fringe'
I don't think you believe this drivel. I think you're just making this up, in a pathetic attempt to sell MS. No one could be that delusional.
Then again . . .
This thread is dead, and I'm out.
Disclaimer: Opinions posted on Free Republic are those of the individual posters and do not necessarily represent the opinion of Free Republic or its management. All materials posted herein are protected by copyright law and the exemption for fair use of copyrighted works.