Microsoft has disclosed a buffer overflow in the IIS indexing service ISAPI handler. The bug — known as the .ida overflow — is exploitable through a single HTTP request with a long URL ending in .ida. CVE-2001-0500.
The pattern fits what I have been predicting in the broader IIS-vulnerabilities trajectory. A short note on what is brewing.
What the bug is
The ISAPI handler for .ida URLs (used by the indexing service for queries) does not properly validate the length of the URL. A request with a long URL — typically 200+ bytes of crafted payload — overflows a stack buffer in the handler. The overflow gives the attacker control of the instruction pointer; carefully crafted shellcode in the same request gives them code execution as the IUSR user (which has substantial system access by default).
The bug is exploitable from any HTTP client that can reach the IIS server. No authentication. No prior session. A single GET request is enough.
Microsoft published the patch in mid-June. The exploitation cycle is just beginning.
What I expect over the next several weeks
- Public exploit code within days of disclosure.
- Mass scanning for vulnerable hosts within a week.
- Mass exploitation against unpatched hosts.
- Possibly an automatically-propagating worm built around the exploit.
The last point is what I am watching most carefully. The exploitation pattern is exactly the right shape for a worm: a single HTTP request that does the full compromise. From the attacker's perspective, the only barrier between "single host compromise" and "automated propagation" is wrapping the exploit in a small scanning loop.
The scanning infrastructure to support a worm is already mature (as I have written). The compromise mechanism is now demonstrated. The propagation step is small.
What operators should do
For anyone running IIS:
Apply MS01-033 immediately. The patch was published in mid-June; the disclosure was June 18; we are now two weeks into the window. Any IIS server that has not been patched is exposed to public exploit code that almost certainly exists.
Apply URLScan if you have not. URLScan blocks the .ida URL pattern by default in its standard configuration. Even on unpatched hosts, URLScan provides a meaningful defence.
Disable the indexing service if you do not need it. Many IIS deployments have the indexing service enabled but do not use it for anything. Disabling reduces the attack surface entirely.
Watch for exploitation patterns. Snort signatures for the .ida exploit pattern are presumably emerging; deploy them.
What I expect to be writing about
The worm I have been predicting in my 2001 list is now likely to materialise around this exploit. If it does, I will write about it as it develops. The structural lessons will be the same as for previous worms; the scale will, on the available math, be larger than Mafiaboy or Lion.
More as the situation develops.