Microsoft IIS FTP Server NLST Buffer Overflow Clarifications

By Carsten Eiram

Working exploit code was recently published for a stack-based buffer overflow vulnerability in the FTP server component of Microsoft IIS when handling "NLST" commands.

The reason for me writing this blog is to discuss a workaround that many sources, including Microsoft, suggest to prevent exploitation: To remove write permissions for anonymous and untrusted users. I'd like to clarify why this mitigates code execution to a large extent (but not completely) and also why this does not prevent the vulnerability from being exploited to cause a DoS (Denial of Service).

The vulnerability is caused by a stack-based buffer overflow when constructing paths based on results of an NLST command. The data overflowing the bounds of the allocated buffer is based on the name of a directory returned in a result.

On IIS 5.0 it is possible to overwrite the return address stored on the stack to gain control of the execution flow when a function returns.

On IIS 5.1 and 6.0 it is also possible to overwrite the return address, but fortunately for system administrators, these versions are compiled with the "/GS" flag, which inserts a stack cookie to check before returning from a called function; if corrupted, the application terminates. Currently, known tricks for bypassing this security measure do not seem to work for this vulnerability, but it can still be exploited to trigger a DoS, resulting in the service either crashing or dropping active connections before restarting.

As running NLST commands does not require write permissions, any user can trigger the vulnerability by supplying a long, specially crafted argument containing one or more specific characters that would return a result containing a directory. Any directory name longer than a couple of characters, which should exist on most FTP servers in use, is sufficient to trigger the buffer overflow.

While restricting write permissions for anonymous and untrusted users does not prevent against DoS attacks, it does seriously mitigate the possibility for attackers to successfully execute code on IIS 5.0 systems. If an attacker has write permissions, it is possible to create a directory where the characters in the name make it straight-forward to direct the program flow to a desired memory location. Without this, it would require a good portion of luck on the attackers part to execute code as a directory name would by chance have to include characters that could be used to point to a controlled memory location.

In conclusion, system administrators of IIS 5.0 systems can mitigate exploitation by restricting write permissions for untrusted users. However, code execution will at least still be theoretically possible for IIS 5.0 and any user (even without write permissions) on IIS 5.0, 5.1, and 6.0 can still trigger a DoS.

Stay Secure,

Carsten Eiram,
Chief Security Specialist