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
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
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
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,
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
About the Author
Stephen Swoyer is a contributing editor. He can be reached at