In-Depth

What could go wrong?

• By Stephen Swoyer
• June 1, 2005

DBAs and other folks who spend time thinking about data management can be a persnickety bunch. Many DM theorists still insist there aren’t any true relational databases, after all. So, there’s a tendency to dismiss the theoretical concerns of the DM crowd as unrepresentative of the majority of realists. In this case, however, even many DM pragmatists aren’t completely comfortable with what Microsoft is doing.

There’s good reason for that. If you want to get a sense for what could go wrong, you might want to revisit the checkered past of Microsoft’s own Internet Information Services Web server platform. It seems like ancient history now, but Microsoft also famously proposed to bring HTTPD administration and programming down from the mountain—with decidedly mixed results.

In late 1997, for example, the software giant shipped its free Windows NT 4.0 Option Pack, which included the then-new IIS 4.0 Web server. Of course, the NT 4.0 Option Pack and IIS 4.0 brought a lot more to the table, too, including developer-friendly enhancements such as Remote Data Services, a component of Microsoft’s (now ubiquitous) Data Access Components package. RDS, which installed by default with IIS 4.0 and the NT 4.0 Option Pack, was designed to provide controlled access over the Internet to remote data resources through IIS.

By all accounts, RDS worked as advertised. Programmers used it to access resources located on private Internet works by tunneling SQL or ODBC data requests over vanilla HTTP. For those who chose to exploit such capabilities, IIS 4.0 and RDS were welcome.

The problem, of course, was that not everybody wanted, or needed, RDS installed by default, and not everybody wanted or needed to use it. An ancillary issue was not everybody knew that by installing IIS 4.0, they were also installing RDS and MDAC. One consequence of this was that, in the days before Microsoft’s patch-sniffing Windows Update engine, not everybody knew enough to update their IIS installations when Microsoft first disclosed an RDS and MDAC-related vulnerability in July 1998.

As a result, when the first RDS-related exploit appeared 17 months later, hundreds of thousands of IIS 3.0 and IIS 4.0 shops were caught off guard. It was, in the days before Code Red and SQL Slammer, Windows’ biggest-to-date slap in the face.

It wasn’t just RDS, either. The sample scripts and some of the other developer-friendly features Microsoft delivered in both IIS 4.0 and IIS 5.0 have functioned, on several notable occasions, as vectors for system compromise. In many cases, these features (like IIS FrontPage Server Extensions) were installed by default. In other cases, such as Visual Studio Remote Application Deployment, developer-friendly features installed by Visual Studio have been a vector for vulnerability.

The point, skeptics say, isn’t that Microsoft has a history of software quality control problems. Or that Microsoft’s attempts to make its software easier to use also make it more insecure. Both claims might be true, but they’re not the issue. The point is that every concession to ease of use almost always entails a specific cost in some other area—if not in terms of security, then perhaps in terms of reliability or availability, for example.

This is a lesson that Microsoft, with its much-ballyhooed security mea culpa of several years ago, claims to have taken to heart. But are the folks in Redmond poised to repeat the mistakes of the past when they deliver a new developer-friendly version of SQL Server?

Back to feature: Codejockeys Assess the Risks and Rewards of Next-gen SQL Server