Today Microsoft published security bulletin MS00-078: a directory-traversal vulnerability in IIS 4.0 and 5.0, exploited via Unicode-encoded URL characters. CVE-2000-0884.
This is exactly the structural class of vulnerability I wrote about in March 1999. It is also, on the available evidence, going to be widely exploited within hours. Worth writing about now while the patch is still ahead of the wave.
What the vulnerability is
IIS handles URLs by decoding URL-encoded characters and then resolving the path. The standard URL decoder handles %2e%2e%2f (the encoded form of ../) — but only after the path-resolution step has done its check.
The specific bug exploits Unicode encoding. URLs can include characters encoded in extended Unicode forms — for example, %c0%af is one Unicode encoding of /. The IIS URL decoder accepts these encodings, but the check that prevents traversal outside the document root is performed on the URL before Unicode decoding.
The result: a URL like /scripts/..%c0%af..%c0%af..%c0%af/winnt/system32/cmd.exe?/c+dir+c: passes the path-traversal check (because ..%c0%af does not match the literal ../ the check is looking for), is then Unicode-decoded by IIS into /scripts/../../../winnt/system32/cmd.exe?/c+dir+c:, and is served as a request to C:\winnt\system32\cmd.exe.
IIS executes cmd.exe with the parameter dir c:. The output of the directory listing is returned to the requester.
This is path traversal of the most basic kind, mediated by an encoding mismatch. It is the same pattern I described eighteen months ago. The defensive principle is the same: check after decoding, not before.
What the impact is
The practical consequences:
Arbitrary command execution as IUSR_machinename. The IIS anonymous-access user is what runs cmd.exe in the example above. By default, IUSR has access to most of the filesystem and can execute many programs. The attacker can browse files, read documents, run command-line tools, download files from the web, install software.
No authentication required. Any HTTP client that can reach the IIS server can exploit the bug. There is no login, no session, no captcha. The exploit is a single carefully-crafted URL.
Trivial to scan for. Mass scanners can probe for the bug with a single HTTP request and a single response check. The presence or absence of vulnerability is determinable in milliseconds.
Widely vulnerable. IIS 4.0 and 5.0, on Windows NT 4.0 and Windows 2000, with default configurations. This is essentially every IIS install in production.
What I expect over the next 72 hours
A short list, written down with the calibrated uncertainty I committed to:
Mass scanning starts within 24 hours. Several scanner kits will be updated to test for the vulnerability before the end of the day. By tomorrow morning, every internet-facing IIS server will have been probed.
Public exploit code by tomorrow. Bugtraq will, within hours, host working exploit code that any technical reader can compile and use. This is the standard pattern for Microsoft advisories of this severity.
Mass exploitation within the week. Operators who do not patch quickly will have their servers compromised. The compromised servers will be used as platforms for further attacks — spam relays, scan platforms, DDoS daemons.
A subsequent worm within months. The combination of trivial exploitation and large vulnerable population is exactly the substrate for an automatically-propagating worm. I expect to see one within 6-12 months.
None of these predictions are dramatic; they are the standard pattern for a serious Microsoft vulnerability of this shape.
What operators should do now
For anyone running IIS, the answer is unambiguous: patch immediately. The patch is published; the install is straightforward; the consequences of not patching are severe.
If patching is genuinely not possible in the immediate window, mitigations:
Disable the affected URL handlers. The bug requires that the URL is allowed to invoke cmd.exe or another executable. Disabling the script-execution handlers for non-essential paths reduces the exploit surface.
Apply URL-filtering rules. Patterns like ..%c0%af and similar Unicode variants should be filtered at the web-server level or upstream. Several products provide this capability; the URLScan tool Microsoft has been developing is the natural choice.
Restrict IUSR's filesystem access. Default IIS configurations have IUSR with broad access. Tightening this — explicit deny on cmd.exe, on the system32 directory, on user document directories — limits what the attacker can do even if they get command execution.
Monitor aggressively. Until the patch is in place, watch the access logs for the characteristic exploit URL patterns. Any matching request indicates an active attack.
None of these are substitutes for the patch. They are partial mitigations for the window.
What this teaches structurally
This bug is not new. The technique is the path-traversal pattern that has been documented for years. The specific encoding-mismatch variant has been described in multiple research publications. The fact that IIS has it in late 2000 is a structural problem with the IIS development process, not a novel vulnerability class.
The broader observation: complex parsing systems with multiple decoders are dangerous when the layers do not agree on what the input means. The fix is not to find every specific encoding; it is to ensure all decoders agree, with the check applied on the canonical form. IIS's failure to do this consistently is the structural issue.
Microsoft's response, in fairness, has been faster than for some past advisories. The patch shipped on the same day as the public disclosure. The advisory is clear and the mitigation guidance is comprehensive. The execution of the response is good even if the underlying vulnerability is a structural one.
What I am doing
For my own infrastructure: nothing direct. I do not run IIS. The vulnerability does not affect me operationally.
For the friends I support: I am sending a brief note with the patch URL and the mitigation guidance. Several of them run small IIS deployments; they have probably already received Microsoft's notifications but a follow-up reminder is cheap to send.
For my Snort sensor: I have added a rule for the characteristic Unicode-encoded URL patterns. Even though I do not run IIS, the alert tells me when scanners are sweeping my range looking for vulnerable hosts. The data is interesting in itself.
For my structured-log analysis: I have updated the patterns my analysis script flags. The web-server logs across my friends' infrastructure will show me, in real time, the wave of probing that I expect over the next 24-48 hours.
A closing note
This bug is a reminder that the structural problems I have been writing about are still, in late 2000, very much present. The IIS codebase produces a steady drumbeat of advisories. The Microsoft development process is not yet at the level where these patterns are systematically eliminated. The defenders' work continues to be reactive.
The long-run answer is structural — better development practices, better tooling, better defaults. None of those are happening fast enough to outpace the steady drumbeat. The operator's task remains, this week as for the past two years, to track advisories and patch promptly.
More as the impact develops over the next few weeks.