Today we released MS11-004 to address a vulnerability in the Microsoft FTP service an optional component of Internet Information Services (IIS). In this blog, we would like to cover some additional technical details of this vulnerability.

First, we want to clarify that the vulnerability lies in the FTP service component of IIS. The FTP service is an optional component of IIS and is not installed by default.

One part that may be confusing is the difference between the FTP service version and the IIS version. For example, the version of FTP service shipped with IIS 7 on Windows Vista and Windows Server 2008 is FTP 6.0, not FTP 7.0. However, you could also install FTP 7.0/7.5 as an optional component on IIS 7 from the Microsoft Download Center. If you are unsure what version of FTP service you are running and if your system is vulnerable; use this procedure to determine if the update is needed for your system.

  • If FTP service is not enabled, the system is not vulnerable.
  • If FTP service is enabled,
    • IIS 6 on Windows Server 2003: Not vulnerable
    • IIS 7 on Windows Vista and Windows Server 2008: By default, IIS 7 uses FTP 6.0, which is not vulnerable. However, if you install FTP 7.0/7.5 for IIS 7 package from Microsoft Download Center, then it is vulnerable.
    • IIS 7.5 on Windows 7 and Windows Server 2008 R2: FTP 7.5 shipped with IIS 7.5 is vulnerable.

Please note there is also a way to automate this process. FTP 6.0 is running with a different service name than FTP 7.0/7.5. Therefore, the idea is to check whether the “ftpsvc” service, the service name of FTP 7.0/7.5, is running or not. In our previous SRD blog Assessing an IIS FTP 7.5 Unauthenticated Denial of Service Vulnerability , we have already talked about the approach. Here we list it again:

A user can determine the status of the IIS FTP service by querying it through the command prompt (running as administrator):

  • Press the “Windows”+“R” key
  • Type “cmd.exe” (no quotes)
  • In the command prompt type “sc query ftpsvc” (no quotes)

If the service is not installed then the following will be displayed:

> sc query ftpsvc
[SC] EnumQueryServicesStatus:OpenService FAILED 1060:

The specified service does not exist as an installed service.

If the service is installed and running then the following will be displayed:

> sc query ftpsvc
SERVICE_NAME: ftpsvc
        TYPE               : 20  WIN32_SHARE_PROCESS
        STATE              : 4  RUNNING
                                (STOPPABLE, PAUSABLE, ACCEPTS_SHUTDOWN)
        WIN32_EXIT_CODE    : 0  (0x0)
        SERVICE_EXIT_CODE  : 0  (0x0)
        CHECKPOINT         : 0x0
        WAIT_HINT          : 0x0

An alternative approach is to scan the file system to detect whether a machine is vulnerable. . If ‘ftpsvc.dll’ does not exist in the %system32%\inetsrv directory, then your system is not affected. If you find a file named ‘ftpsvc2.dll’ this indicates that you have FTP 6.0 installed on the system and are also not affected by this vulnerability. The detection logic on Windows Update, Microsoft Update, and WSUS will handle the above scenarios, so that the update is only offered to IIS 7 systems that have FTP 7.0 or FTP 7.5 installed.

Finally, we would like to clarify the exploitability of this issue. We blogged about this issue in December 2010 here, and outlined why we thought remote code execution was unlikely. We said “these characteristics make it difficult to successfully execute a heap spray or partial function pointer override attack. Because of the nature of the overrun, the probable result will only be a denial of service and not code execution.”

Since then additional research has shown that it may be possible for this vulnerability to be exploited if DEP and ASLR protections are bypassed. No exploit has been seen in the wild, and no exploit code has been made publicly available. To sum up the current situation, while it may be possible to achieve code execution, the probable impact for most customers remains denial of service.

Acknowledgement

Thanks to Nazim Lala in the IIS team, the Japan CSS Security Response Team, and Brian Cavenah in the MSRC Engineering team for their work on this.

Chengyun Chu and Mark Wodrich, MSRC Engineering