[NT] 15 August 2001 Cumulative Patch for IIS

From: support@securiteam.com
Date: 08/18/01 

From: support@securiteam.com
To: list@securiteam.com
Subject: [NT] 15 August 2001 Cumulative Patch for IIS
Message-Id: <20010818165424.91A3E138BF@mail.der-keiler.de>
Date: Sat, 18 Aug 2001 18:54:24 +0200 (CEST)

The following security advisory is sent to the securiteam mailing list, and can be found at the SecuriTeam web site: http://www.securiteam.com
- - promotion

When was the last time you checked your server's security?
How about a monthly report?
http://www.AutomatedScanning.com - Know that you're safe.
- - - - - - - - -

  15 August 2001 Cumulative Patch for IIS
------------------------------------------------------------------------

SUMMARY

Microsoft has released an important patch for IIS administrators. This
patch 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 4.0 Service Pack 5. A complete listing of the
patches superseded by this patch is provided below.
Before applying the patch, system administrators should take note of the
caveats discussed below.

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 was not
susceptible to infection via the worm could nevertheless have its service
disrupted by the worm.
 * A denial of service vulnerability that could enable an attacker to
temporarily disrupt service on an IIS 5.0 web server. WebDAV does not
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.
 * 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.
 * 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.
 * 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.

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.

DETAILS

Affected Software:
 * Microsoft Internet Information Server 4.0
 * Microsoft Internet Information Server 5.0

Mitigating factors:
URL Redirection denial of service:
 * This vulnerability only affects IIS 4.0. IIS 5.0 is not affected.
 * The vulnerability only occurs if URL redirection is enabled.
 * The vulnerability does not provide any capability to compromise data on
the server or gain administrative control over it.

WebDAV request denial of service:
 * 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 vulnerability does not provide an attacker with any capability to
carry out WebDAV requests.
 * The vulnerability does not provide any capability to compromise data on
the server or gain administrative control over it.

MIME header denial of service:
 * 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.

SSI privilege elevation vulnerability:
 * 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.

System files listing privilege elevation vulnerability:
 * 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.

Patch availability:
Download locations for this patch
 * Microsoft IIS 4.0:
   <http://www.microsoft.com/Downloads/Release.asp?ReleaseID=32061>
http://www.microsoft.com/Downloads/Release.asp?ReleaseID=32061
 * Microsoft IIS 5.0:
   <http://www.microsoft.com/Downloads/Release.asp?ReleaseID=32011>
http://www.microsoft.com/Downloads/Release.asp?ReleaseID=32011

What is a cumulative patch?
This patch not only addresses several newly discovered vulnerabilities,
but also includes all previously released patches for IIS 4.0 and IIS 5.0.

What previously released patches are bundled within this one?
The IIS 4.0 patch incorporates the functionality of all post-Service Pack
5 patches delivered for IIS 4.0. The IIS 5.0 patch incorporates the
functionality of all patches delivered to date for IIS 5.0.

Are there any security vulnerabilities affecting IIS that are not
addressed by this patch?
Yes. As discussed in the Caveats section below, several vulnerabilities
known to affect IIS 4.0 require administrative action rather than a patch.
In contrast, there are no IIS 5.0 vulnerabilities that require
administrative action, so this cumulative patch does address all IIS 5.0
vulnerabilities.

Does the patch include fixes for issues involving Index Server and other
products that are typically found on IIS servers?
As a rule, IIS patches do not include fixes for other products, like Index
Server, that are typically found on IIS servers. However, we have made an
exception in the case of the Index Server vulnerability discussed in
Microsoft Security Bulletin
<http://www.securiteam.com/windowsntfocus/5FP0B2K4KU.html> MS01-033.
Microsoft has included it in this patch because of its seriousness with
respect to IIS servers.

What machines should this patch be applied to?
At a minimum, it should be applied to web servers. However, it may also
need to be applied to other systems as well. For instance, Exchange 2000
uses IIS 5.0 if Outlook Web Access is installed. The best way to tell
whether you need the patch is to check the list of services that are
running. If IIS 4.0 or 5.0 are running, you should apply the patch.

What are the new security vulnerabilities addressed by the patch?
There are five newly discovered vulnerabilities:
 * Three vulnerabilities that could enable an attacker to temporarily
disrupt service on an IIS web server. The first affects IIS 4.0 only and
is particularly significant because it can be exploited by the "Code Red"
worm. The second and third affect IIS 5.0 only.
 * Two vulnerabilities that could enable an attacker who already had
considerable privileges on a web server to gain even greater privileges.
The first of these affects both IIS 4.0 and IIS 5.0; the second affects
IIS 5.0 only

What is the scope of the first vulnerability?
The first vulnerability is a denial of service vulnerability. An attacker
who exploited this vulnerability could temporarily prevent an IIS server
from servicing web requests. The vulnerability is being actively exploited
by the "Code Red" worm, and this has been widely, although incorrectly,
reported as being due to a flaw in the patch provided in Microsoft
Security Bulletin
<http://www.securiteam.com/windowsntfocus/5FP0B2K4KU.html> MS01-033. In
fact, this is a completely different and previously unknown vulnerability.

The vulnerability only affects IIS 4.0 servers, and even then only, when
they are operated in a non-default configuration. IIS 5.0 servers are not
affected by the vulnerability. The vulnerability does not provide a means
by which an attacker could gain any degree of administrative control over
the server.

What causes the vulnerability?
The vulnerability results because the code within IIS 4.0 that performs
URL redirection does not correctly handle the case in which a request's
actual length is different from that specified in the request. Such a
request triggers a chain of events that culminates in an access violation,
resulting in the failure of the service.

What is URL redirection?
When you request a web page, you enter an URL like, for instance,
http://www.microsoft.com/technet/security, the web server maps this URL
into a request for a specific file on the server, e.g.,
c:\inetpub\technet\security\default.asp. However, it frequently happens
that content needs to be moved to a different machine or to a new folder
structure. URL redirection allows maintenance activities like this to be
transparent to web site visitors.

For instance, in our example, suppose the content on the web site were
reorganized, and the web page that used to reside at
c:\inetpub\technet\security\default.asp were moved to
c:\inetput\abc\xyz\default.asp. Of course, site visitors would be able to
view the content by navigating to http://www.microsoft.com/abc/xyz, but
the web administrator would not want customers who use the old URL to get
a "page not found" error. URL redirection allows the web administrator to
redirect the file that is pointed to by
http://www.microsoft.com/technet/security, so that visitors will continue
to see the right web page.

What is wrong with the way IIS 4.0 performs URL redirection?
Within a web page request is information that says how long the request
is. If that information is incorrect, and the request's actual length is
longer, it sets off a complex chain of events that ultimately cause the
service to fail.

This sounds like a potential buffer overrun. Is it?
No. The request does not overrun any buffers. This is an important point,
because it means that this issue can only be used to disrupt service - not
gain control of the server.

What could an attacker do via this vulnerability?
An attacker could send such a request to a server in an attempt to prevent
the server from performing useful service.

What would be required to put the server back into service?
The administrator could restore normal service by restarting the IIS 4.0
service.

Why is the Code Red worm implicated in this issue?
When the worm tries to infect a server, it does so by sending a request
that attempts to exploit the vulnerability discussed in Microsoft Security
Bulletin MS01-033. However, the request contains invalid length
information of exactly the type needed to exploit the newly discovered
denial of service vulnerability. As a result, the worm can not only infect
some servers through the vulnerability discussed in MS01-033, but also can
disrupt service in others through this vulnerability.

I heard that this problem is actually due to a flaw in the patch you
delivered in Security Bulletin MS01-033. Is this true?
No. The patch we provided in MS01-033 was designed to prevent a
buffer-overrun vulnerability from being exploited, and it does that. The
vulnerability here is completely different from that one.

If that's true, then why are only servers that have the MS01-033 patch
affected by this vulnerability?
They aren't. Any IIS 4.0 server that performs URL redirection is affected
by this vulnerability, regardless of whether it has the MS01-033 patch
installed or not. However, it is understandable why people would
mistakenly conclude that there is a problem in the MS01-033 patch.

The Code Red worm infects systems by using the vulnerability discussed in
MS01-033 to, in essence, inject modified system software into a server.
The modifications needed to infect an IIS 4.0 system are different from --
and incompatible with -- those needed to infect an IIS 5.0 system. The
designers of the worm had to choose whether to inject IIS 4.0 or IIS 5.0
code into the servers it attacks, and they chose to inject IIS 5.0 code.
As a result, if the worm compromises an IIS 4.0 system, it injects IIS 5.0
code into it, which cannot execute. Instead, the result is that the
infection attempt causes the IIS 4.0 service to fail.

This gives rise to a situation where two completely different
vulnerabilities cause exactly the same effect. If an IIS 4.0 server does
not have the MS01-033 patch installed, the worm causes it to fail.
However, even if the patch is applied to the server, the worm will still
cause the service to fail if URL redirection is enabled -- not because of
the vulnerability discussed in MS01-033, but because of the vulnerability
here. As a result, an administrator of an IIS 4.0 server that is
configured to perform URL redirection could conclude that the MS01-033
patch had failed, when in fact it had not.

Is URL redirection enabled by default on IIS 4.0?
No. The web administrator must enable it.

I have URL redirection enabled. Should I turn it off?
The best course of action is to apply the patch, as it will allow you to
continue to use URL redirection, but without the threat of the
vulnerability. However, if you want to turn off URL redirection, here is
how:
 * In the Internet Service Manager, right-click on the web site.
 * Select the Home Directory tab.
 * In the section titled "When connecting to this resource, the content
should come from:", select anything other than "A redirection to an URL".
 * Click OK to accept the changes.

Does this vulnerability affect IIS 5.0?
No. URL redirection in IIS 5.0 is not affected by this vulnerability.

What does the patch do?
The patch IIS 4.0 to correctly redirect URLs with conflicting length
information.

What is the scope of the second vulnerability?
The second vulnerability is a denial of service vulnerability. An attacker
could use this vulnerability to temporarily disrupt web services on an IIS
5.0 server.

The effect of exploiting the vulnerability would be only temporary - by
default, IIS 5.0 would automatically restart itself after such an attack.
However, any sessions in effect when the attack was carried out would be
severed and need to be re-established.

What causes the vulnerability?
The vulnerability results because of the way that WebDAV handles a
particular type of very long, invalid request. The net effect is to cause
an access violation that result in the failure of the IIS 5.0 process.

What is WebDAV?
To explain what WebDAV is, we first need to discuss HTTP. HTTP, or
Hypertext Transfer Protocol, is the industry standard protocol by which
web content is communicated. It enables clients to request web content,
and enables web servers to either supply the content or tell the client
why it was unable to supply it.

WebDAV is an extension to the HTTP specification. The "DAV" in "WebDAV"
stands for "distributed authoring and versioning", and it adds a
capability for authorized users to remotely add and manage content on a
web server. WebDAV is fully supported in Windows 2000 and ships as part of
the product.

What is wrong with WebDAV?
WebDAV does not properly handle a particular type of request,
specifically, one that is very long and contains a particular type of
invalid data. Because of a flaw in WebDAV, processing such a request would
culminate in an access violation that would cause the IIS 5.0 process to
fail.

This sounds like a potential buffer overrun. Is it?
No. Although the vulnerability occurs in very long requests, it is not the
length of the request that actually causes the vulnerability. In any
event, the request in this case does not overrun any buffers. This is an
important point, because it means that this issue can only be used to
disrupt service - not gain control of the server.

What would this allow an attacker to do?
An attacker could use this vulnerability to disrupt service on an IIS 5.0
server. Exploiting the vulnerability would cause the IIS 5.0 service to
fail, with the result that any ongoing sessions would be lost, and users
would be unable to start new sessions. However, the effect would not last
long, as IIS 5.0 is configured by default to automatically restart itself.

Who could exploit the vulnerability?
Any user who had connectivity with an affected server could exploit the
vulnerability. It would not be necessary for the attacker to authenticate
to the machine.

Would this vulnerability enable an attacker take any administrative action
on an affected system?
No. The vulnerability would only enable the attacker to disrupt service on
the system. There is no capability via this vulnerability to carry out
unauthorized WebDAV commands, compromise data on the system or take any
kind of administrative action on it.

Is WebDAV installed and running by default?
Yes. WebDAV is installed by default on IIS 5.0 web servers.

Could the vulnerability be exploited accidentally?
No. It is extremely unlikely that any user would accidentally create a
WebDAV request with the length and specific malformation involved here.

Does this vulnerability affect IIS 4.0?
No. WebDAV did not ship as part of IIS4.0.

I am running IIS 4.0. Does this mean that I do not need the patch?
No. The patch addresses all of the vulnerabilities described in this
bulletin, one of which does affect IIS 4.0. You should apply the patch if
your system is affected by any of the vulnerabilities discussed in the
bulletin.

How does the patch eliminate the vulnerability?
The patch ensures that WebDAV requests of the type implicated in the
vulnerability are rejected without causing an access violation.

What is the scope of the third vulnerability?
The third vulnerability is a denial of service vulnerability. An attacker
who exploited the vulnerability would be able to disrupt an affected web
server.

In order to exploit this vulnerability, the attacker would need the
ability to place content onto an affected web server. However, best
practices strongly recommend against ever allowing an untrusted user to
install content on a web server. The vulnerability affects only IIS 5.0
servers, and would not enable an attacker to gain any privileges on the
server.

What causes the vulnerability?
The vulnerability results because of a flaw involving the way IIS 5.0
handles MIME information when serving content. If the MIME content-type
information were malformed in a particular way, the service would fail
when trying to process it.

What's MIME?
MIME stands for Multipurpose Internet Mail Extensions, and is an industry
standard protocol for encoding content on the Internet. Although its name
suggests that it only involves email, most Internet content - including
web content - uses the MIME standard to specify what type of information
the content is.

How does content on a web server use MIME?
When a web server receives a request for some content, it needs to know
whether the content consists of text, graphics, music, video data, and so
forth. There is a header in each web content file that provides this
information. In this case, a security vulnerability results in the case
where the information in the header is malformed in a particular way.

What is wrong with the way IIS 5.0 handles MIME information?
If web content on an IIS 5.0 server contains a certain type of invalid
MIME information, it inserts an invalid entry into a system table. This
prevents the server from correctly serving any content until the entry is
removed.

What could an attacker do via this vulnerability?
An attacker who was able to put onto a server content containing the
malformation at issue here would be able to request that content in order
to put the server in a state in which it could not serve any content to
any visitors.

How would the attacker get the content onto the server?
He should not be able to. Best practices strongly recommend against ever
allowing an untrusted user to put content on a web server. If this
recommendation has been followed, an attacker would not be able to exploit
the vulnerability.

How could an affect server be put back into service?
The web server administrator would need to remove the spurious entry in
the system table by performing the following steps:
 * Open the Internet Services Manager
 * Right-click on the virtual directory containing the content
 * Select HTTP Headers, then click on File Types
 * Search for an entry in the list whose MIME type is empty, and delete
it.

What does the patch do?
The patch causes IIS 5.0 to treat content that contains the malformation
at issue here as though it had not specified a MIME type for the content
at all. This causes the content, when requested, to be sent assuming that
the client application will know how to parse it.

What is the scope of the fourth vulnerability?
The fourth vulnerability is a buffer-overrun vulnerability. An attacker
who exploited the vulnerability could gain complete control over an
affected server, and take any desired action on it.

However, the vulnerability can only be exploited by code that is running
on the server. As a result, the attacker would need to already have the
ability to install software on the server in order to exploit the
vulnerability. Best practices strongly recommend against ever allowing an
untrusted user to install software on a web server.

What causes the vulnerability?
The code that processes server-side include files contains an unchecked
buffer. By installing on an affected server a server-side file that
contained a malformed server-side include directive, an attacker could
cause the buffer to be overflowed the next time the file was requested by
a user.

What are server-side files?
Some web pages, such as static HTML files, are processed entirely by the
browser. When such a web page is requested, the web server's role is
simply to find the appropriate file and send it to the client, which
performs all the work. Such files are known as "client-side" files.

In contrast, many advanced web technologies require that the server
perform some processing before sending a web page to the browser. For
instance, an Active Server Page is essentially a program that, when
requested, runs on the server and generates an HTML file that's then sent
to the browser. Files such as these are known as "server-side" files. In
the case of this vulnerability, the problem lies in how a particular type
of file associated with server-side files - known as a server-side include
file - is handled.

What are server-side include files?
Server-side includes (SSI) allow web developers to reduce the work
required to build server-side files. By including an SSI directive in a
server-side file, a web developer can cause the contents of one file
(known as an SSI file) to be incorporated into another file, after which
point the combined file is processed.

For instance, suppose that every web page on a particular site needs to
carry the company's copyright notice. Rather than adding code to every
server-side file to display the notice, a developer might build an SSI
file containing the HTML code to display the notice, and then add a SSI
directive to every web file on the server, instructing the file to
incorporate the copyright file. This would save coding, and allow the
developer to change the copyright notice on every web page simply by
changing it in the SSI file.

What is wrong with the way SSI files are handled?
IIS 4.0 and 5.0 contain an unchecked buffer in the code that processes SSI
directives. If a server-side file were coded to contain an especially
malformed SSI directive, it would cause the buffer to be overrun when the
file was requested.

As is usually the case with buffer overruns, either of two effects would
result. If the buffer were overrun with random data, it would cause the
affected code - in this case, the IIS process - to fail. If it were
overrun by carefully selected data, it could have the effect of modifying
the code that contains the unchecked buffer. For the remainder of the
discussion, we will focus on the latter case, since it is by far the most
serious.

What would this enable an attacker to do?
An attacker who could exploit the vulnerability would be able to change
the IIS process while it was running, in order to make it take some new
action of the attacker's choice.

What security context would the attacker's code run in?
The code that contains the unchecked buffer runs in the Local System
context, so the attacker's code would as well. The Local System context is
the highest security context on the system, so exploiting this
vulnerability would give the attacker complete control over the machine,
and enable him to change web content, reconfigure the system, reformat the
hard drive, or take virtually any other action.

How could an attacker exploit the vulnerability?
In order to exploit the vulnerability, the attacker would need the ability
to create a server-side file and install it on an affected server. Once
this was done, any request for the file - whether levied by the attacker
or another user - would trigger the buffer overrun.

But this assumes that the attacker could install a file on the server. How
likely it is that he could do this?
Under default conditions, untrusted users cannot do this. The default
permissions for both IIS 4.0 and 5.0 deny web site visitors the ability to
upload files to the server, and this vulnerability does not provide any
way to circumvent this restriction. The attacker would need to have
already compromised the web server to some degree - for instance, through
a misconfiguration on the server - before being able to use this
vulnerability.

Nevertheless, the vulnerability should not be discounted. If an attacker
managed to gain some degree of access to a server, this vulnerability
could enable him to significantly broaden the scope of the compromise.

How does the patch eliminate this vulnerability?
The patch eliminates the vulnerability by instituting proper input checks
in the affected code.

What is the scope of the fifth vulnerability?
The fifth vulnerability is a privilege elevation vulnerability. An
attacker who already had the ability to load a program of his choice onto
an IIS 5.0 web server and run it could use this vulnerability to make the
program run in the security context of the operating system itself. This
would enable the attacker's program to take virtually any action on the
server.

The requirement that the attacker already be able to load a program onto
the web server and execute it would significantly increase the difficulty
of exploiting this vulnerability. If best practices have been followed,
only trusted users will be able to do this, and only after their code has
been inspected.

What causes the vulnerability?
IIS 5.0 keeps a list of executables that, by default, run "in process".
The vulnerability results because the list that specifies the names does
so using relative paths as well as absolute paths. This use of relative
paths means that if an executable having the same name as one on the list
were uploaded to any folder on the server and executed, it would run in
process. Once this occurred, the executable could, by definition, gain
system privileges.

What do you mean by running "in process"?
IIS can be configured so that, when a program is run on the server, it
either runs as part of the IIS process or as a separate process. The
former case is known as running "in process", and the latter case is known
as running "out of process".

Running in process provides much better performance than running out of
process, but this comes at a potential cost to security. By design, a
program running in process can always gain the privileges of the parent
process, which in this case is IIS itself. In IIS 4.0, all programs run by
default in process, and as a result, the administrator must ensure that
only trusted code is loaded on the server. In IIS 5.0, programs run out of
process by default, with a few exceptions. The vulnerability results
because of the way these exceptions are handled.

What are the exceptions, and what is wrong with the way they are handled?
IIS 5.0 keeps a list of programs that are trusted and allowed to run in
process regardless of the default settings on the server. The programs on
this list are all ones that ship with the product. The problem lies in how
the list specifies the programs.

What is wrong with how the exceptions are specified?
A security vulnerability results because the files on the exception list
are specified using both absolute path names (e.g.,
c:\folder1\folder2\program.dll) and relative path names (e.g.,
program.dll). As a result, if a program having the same name as one of the
exceptions were loaded into any folder on the server and executed, it
would run in process and would then be capable of gaining system-level
privileges.

What could this enable an attacker to do?
If an attacker were able to load a program of his choice on an IIS 5.0
server and execute it, the code would be able to gain system privileges.
This would give the attacker complete control of the server. He could do
anything he wished, from modifying web pages, to reconfiguring the server,
to reformatting the hard drive.

But this assumes that the attacker could load and execute a program on the
server. How likely it is that he could do this?
Under default conditions, untrusted users cannot load and execute programs
on the server. As a result, it is likely that before an attacker could
exploit this vulnerability, either of two things would need to happen:
either the administrator would need to misconfigure the server, or the
attacker would need to gain authoring privileges on the server through
some other means.

Does this vulnerability affect IIS 4.0?
It does not, but it is important to be precise about why. Recall two
points from the discussion above:
 * The mechanism by which some programs run in process and some run out of
process was introduced in IIS 5.0
 * In IIS 4.0 all programs run in process by default

The vulnerability results because of a flaw in the newly introduced
mechanism that did not exist in IIS 4.0. However, even though this is the
case, it is also true that if an attacker were able to load a program onto
an IIS 4.0 server and run it, the code would, by default, run in process
and the attacker would therefore be able to gain privileges on it. For
this reason, it is extremely important that IIS 4.0 server administrators
only allow trusted code to be loaded onto the server.

I am running IIS 4.0. Does this mean that I do not need the patch?
No. The patch addresses all of the vulnerabilities described in this
bulletin, one of which does affect IIS 4.0. You should apply the patch if
your system is affected by any of the vulnerabilities discussed in the
bulletin.

How does the patch eliminate the vulnerability?
The patch causes the list of programs that should run in-process to be
specified only using absolute addressing.

ADDITIONAL INFORMATION

The information has been provided by <mailto:secnotif@MICROSOFT.COM>
Microsoft Product Security.

========================================

This bulletin is sent to members of the SecuriTeam mailing list.
To unsubscribe from the list, send mail with an empty subject line and body to: list-unsubscribe@securiteam.com
In order to subscribe to the mailing list, simply forward this email to: list-subscribe@securiteam.com

====================
====================

DISCLAIMER:
The information in this bulletin is provided "AS IS" without warranty of any kind.
In no event shall we be liable for any damages whatsoever including direct, indirect, incidental, consequential, loss of business profits or special damages.

Relevant Pages