COMMAND
IIS
SYSTEMS AFFECTED
IIS 4, 5
PROBLEM
Following info is based on a Microsoft Security Bulletin MS01-044.
This advisory addresses the patch which is a cumulative patch
that includes the functionality of all security patches released
to date for IIS 5.0, and all patches released for IIS 4.0 since
Windows NT(r) 4.0 Service Pack 5. A complete listing of the
patches superseded by this patch is provided below, in the
section titled "Additional information about this patch". Before
applying the patch, system administrators should take note of the
caveats discussed in the same section.
In addition to including all previously released security patches,
this patch also includes fixes for five newly discovered security
vulnerabilities affecting IIS 4.0 and 5.0:
- A denial of service vulnerability that could enable an attacker
to cause the IIS 4.0 service to fail, if URL redirection has
been enabled. The "Code Red" worm generates traffic that can in
some cases exploit this vulnerability, with the result that an
IIS 4.0 machine that wasn't susceptible to infection via the
worm could nevertheless have its service disrupted by the worm.
This vulnerability only affects IIS 4.0. IIS 5.0 is not
affected. The vulnerability only occurs if URL redirection is
enabled and does not provide any capability to compromise data
on the server or gain administrative control over it.
- A denial of service vulnerability that could enable an attacker
to temporarily disrupt service on an IIS 5.0 web server. WebDAV
doesn't correctly handle particular type of very long, invalid
request. Such a request would cause the IIS 5.0 service to
fail; by default, it would automatically restart. The
vulnerability only affects IIS 5.0. IIS 4.0 is not affected.
The effect of an attack via this vulnerability would be
temporary. The server would automatically resume normal service
as soon as the malformed requests stopped arriving. The bug
does not provide an attacker with any capability to carry out
WebDAV requests.
- A denial of service vulnerability involving the way IIS 5.0
interprets content containing a particular type of invalid MIME
header. If an attacker placed content containing such a defect
onto a server and then requested it, the IIS 5.0 service would
be unable to serve any content until a spurious entry was
removed from the File Type table for the site. The vulnerability
only affects IIS 5.0. IIS 4.0 is not affected.
In order to exploit this vulnerability, the attacker would need
to have the ability to install content on the server. However,
by default, unprivileged users do not have this capability, and
best practices strongly recommend against granting it to
untrusted users. Credit goes to John Waters of Deloitte and
Touche.
- A buffer overrun vulnerability involving the code that performs
server-side include (SSI) directives. An attacker who had the
ability to place content onto a server could include a malformed
SSI directive that, when the content was processed, would result
in code of the attacker's choice running in Local System
context.
In order to exploit this vulnerability, the attacker would need
to have the ability to install content on the server. However,
by default, unprivileged users do not have this capability, and
best practices strongly recommend against granting it to
untrusted users. Credit goes to The NSFocus Security Team.
Following is their advisory.
Microsoft IIS supports SSI (Server Side Include) function. IIS
use ssinc.dll as a SSI interpreter. By default setting,
extensions like .stm, .shtm and .shtml would be mapped to
interpreter process (Ssinc.dll). SSI supports "#include"
directive, mostly in this form:
<!--#include file="Filename"-->
When processing "#include" directive, ssinc.dll would check for
the name of the directory under which the .shtml file resides,
append it before the include file and form a new path string.
For example, create a file named "test.shtml" with the
following content and save it under "wwwroot/abcd/":
<!--#include file="ABCD"-->
The new path string would be "/abcd/ABCD". Ssinc.dll would copy
it to a buffer of 0x804(2052) bytes.
When obtaining Server-side include filename from test.shtml,
ssinc.dll would perform length check for it. In case that it
is longer than 0x801 bytes, ssinc.dll would cut it to 0x801
bytes and append '\0' at the end. Thus, the include filename
(including the trailing '\0') won't be longer than 0x802(2550)
bytes.
But it does not check the length of the new path string
appending current directory name. Thus, if we set the contained
filename to be a string longer than 0x801 bytes and save
"test.shtml" under a directory (name of which is longer than 9
bytes), a buffer overflow would occur and overwrite the EBP and
EIP saved in stack completely (The trailing '\0' would overwrite
the first argument).
As ssinc.dll is running in LOCAL SYSTEM context, in case that
an attacker carefully form the overflow data, he might change
the procedure flow and run arbitrary code with SYSTEM privilege.
To launch an attack, the attacker would need the following two
conditions:
1. Privilege to create file or directory under Web directory.
2. Ability to access created file through Web service.
Exploit:
1. Create a file "test.shtml" with following file content:
<!--#include file="AAAA[...]AA"-->
Number of 'A' should be over 2049.
2. Create a directory "a" under Web directory. Copy
"test.shtml" to "a" directory.
3. Request "test.shtml" through web browser:
http://webhost/a/test.shtml
4. IIS would return a blank page which indicates that an
overflow has occurred. Meanwhile the trailing '\0' has
overwritten the last byte of saved EBP.
On the contrary, in case that the contained file has a shorter
name like 'AA', IIS would return a SSI file '/a/AA' error
message when receiving the request.
- A privilege elevation vulnerability that results because of a
flaw in a table that IIS 5.0 consults when determining whether
a process should in-process or out-of-process. IIS 5.0
contains a table that lists the system files that should always
run in-process. However, the list provides the files using
relative as well as absolute addressing, with the result that
any file whose name matched that of a file on the list would
run in-process. The vulnerability only affects IIS 5.0. IIS 4.0
is not affected.
In order to exploit this vulnerability, the attacker would need
to have the ability to install content on the server. However,
by default, unprivileged users do not have this capability, and
best practices strongly recommend against granting it to
untrusted users. Credit goes to Oded Horovitz. Here is their
advisory.
The exploit allows a GUEST user (who has the rights to execute
code on the system) to elevate his privileges. Once the exploit
is executed, it allows an attacker to run arbitrary code on the
machine with SYSTEM privileges. Usually, by using certain
well-known attacks, the user can upload the exploit to the IIS
virtual directory, and then remotely execute it. Alternatively,
anyone with a valid username and password can log into the
system, upload the exploit file into the IIS virtual tree, and
then execute it.
IIS supports three different modes of process isolation. These
modes control how well the IIS process is isolated from the
processes that are being invoked as part of the request
processing. Due to a weakness in IIS, several dll files are
always executed by the least secure isolation level regardless
of the actual process isolation settings. By adding or
replacing one of these dlls with a malicious version, an
attacker can run arbitrary code with SYSTEM privileges.
SOLUTION
In addition, this patch eliminates a side effect of the previous
IIS cumulative patch (discussed in the Caveats section of
Microsoft Security Bulletin MS01-026) by restoring proper
functioning of UPN-style logons via FTP and W3SVC.
A patch is available to fix these vulnerabilities. Please read
the Security Bulletin
http://www.microsoft.com/technet/security/bulletin/ms01-044.asp
for information on obtaining this patch.