There have been three serious advisories against Microsoft IIS in the last two months. The most recent — a buffer overflow in the FrontPage Server Extensions — is exploitable against any IIS installation with FrontPage extensions installed, which is the vast majority of installations.
I do not run IIS. Most of the readers of this blog do not run IIS. The reason this matters anyway is that the consequences of widespread IIS compromise are not contained to IIS operators; they affect everyone on the internet, because compromised IIS hosts become the source for spam, scanning, and the kind of distributed denial of service I have been writing about.
This post is about the structural pattern, not about Microsoft specifically.
The recent IIS advisories
For reference, the three I have been tracking:
ISAPI extension buffer overflow. A specially-crafted URL targeting an ISAPI extension can overflow a buffer in the extension handler, leading to code execution on the server. Various ISAPI extensions are affected, depending on what is installed.
FrontPage Server Extensions buffer overflow. A specially-crafted POST request to a FrontPage administration URL overflows a buffer in the handler, again leading to code execution.
".htr" extension issue. Files served by IIS can be requested with a .htr suffix appended, which causes IIS to serve the source code of the file rather than executing it. This is a separate class of bug — information disclosure rather than code execution — but is exploitable across many IIS installations because the .htr handler is enabled by default.
In each case, the pre-conditions are whatever ships with IIS by default. There is no need for the operator to do anything specific to be vulnerable; the vulnerability exists out of the box.
Why this matters beyond IIS operators
The IIS install base is, on the available numbers, large — possibly 25 to 30 per cent of public web servers. The remainder is mostly Apache.
When a serious IIS bug is published, the typical sequence is:
- Advisory and patch released.
- Within hours, exploit code is in circulation on Bugtraq and elsewhere.
- Within days, mass scanners are sweeping the entire IPv4 address space looking for vulnerable IIS instances.
- Within weeks, a measurable fraction of the IIS install base is compromised — those who did not patch quickly enough.
- The compromised hosts become resources for further attacks: spam, scanning, distributed flooding, hosting of malicious content.
This sequence has played out for each of the three recent advisories. The visible consequences include:
- A spike in compromised-host-originated spam following each advisory.
- An increase in scanning traffic from previously-quiet IPs (the ones recently compromised).
- A few publicly defaced websites whose source can be traced to one of the bugs.
The operator who keeps IIS patched is not in this story. The cost is paid by the operators who don't, and by the rest of us who receive the spam and the scans.
Why this is structural
The specific advisories will be patched. The next round will be patched too. The structural problem is the monoculture.
IIS is one product. It has one codebase. Bugs in that codebase affect every running instance. When 30 per cent of the web's servers are running the same product, a single class-A vulnerability in that product is a single point of failure for a large fraction of the internet.
Apache, by contrast, has the same monoculture problem in its own way. Apache bugs affect Apache installations. The mitigation is that Apache and IIS together cover most of the web — so when one has a bug, only some fraction is affected. Diverse codebases, even if individually buggy, produce structural resilience.
This is the same observation biologists make about agricultural monocultures. A single crop variety is more efficient. It is also catastrophic when a pest emerges that affects the variety. Diversity is operationally costly and structurally resilient.
For the web, the operational cost of diversity is paid by anyone who has to support multiple platforms. The structural resilience is paid for by everyone, even those who would prefer the simplicity of one platform. The economics are not aligned: individual operators benefit from picking the same platform everyone else picks (more support, more documentation, more skills available); the internet as a whole benefits from operators picking diverse platforms.
What an operator should do
For an IIS operator: patch promptly, audit defaults, disable everything you do not need. IIS has a server lockdown wizard that automates much of this. The wizard is genuinely good; the trouble is that it is not the default state of an IIS install. The default install is generous; the lockdown is something you have to apply.
For an Apache operator (which is most readers of this blog), the same advice applies in our context. Disable modules you do not need. Tighten directory permissions. Run as a dedicated user. Patch promptly.
For a non-web operator, the indirect costs are unavoidable. The compromised IIS hosts are scanning your network whether you want them to or not. The defenses are the ones I have been writing about all year — egress filtering, intrusion detection, reasonable access control. These are protective against the consequences of IIS compromise, not the IIS compromise itself.
A small note on Microsoft's response
The Microsoft security response has, in fairness, improved over the past two years. Patches are coming out faster. The advisories are clearer. There is now a security mailing list where advisories are announced rather than buried in the corporate site.
The gap between Microsoft's response speed and the open-source ecosystem's response speed has narrowed. Apache patches typically appear within 24 to 48 hours of an advisory; Microsoft patches typically appear in a similar window for serious issues. This is, structurally, the right outcome.
What has not improved is the defaults problem. IIS still installs with too much enabled, with too many extensions handling content by default, with too many administrative interfaces accessible. The lockdown wizard is a workaround for the fact that the default install is wrong; the right fix is to ship a smaller default and require the operator to enable features.
Apache, in fairness, has the same problem to a lesser degree. The default Apache install enables more modules than most servers need. The discipline of compiling a minimal Apache is one I have written about before and continue to recommend.
The broader pattern — defaults that are too generous, with the burden on the operator to restrict — is industry-wide. Every server product I can think of has this property to some degree. Reversing it is a long, slow project that requires a cultural shift in how products are shipped.
Where I think this is going
For the next several years, I expect:
- IIS advisories continuing at the current pace, with occasional spikes around new feature releases.
- A growing emphasis on "secure default" configurations, both as a marketing point and as actual product behaviour.
- Microsoft, slowly, shipping smaller default installs.
- Apache, slowly, doing the same.
- The structural risk of platform monoculture remaining unaddressed at the policy level, because it is nobody's specific problem.
For my own work, I am not changing what I do. I run Apache, hardened. I read the IIS advisories so I know what to expect when the affected hosts start scanning my network. I keep my own defences modest but consistent.
The wider lesson — which I keep returning to — is that internet security is not, and cannot be, just a property of individual operators. It is also a property of the platform diversity and update discipline of the population of operators as a whole. Improving it requires collective action that current incentives do not generate. This is the political-economy problem of the discipline, and it is going to dominate the next decade in ways that the technical problems will not.