What's the scope of the vulnerability?
An attacker who successfully exploited this vulnerability could gain complete control over an affected commerce web server. This would give the attacker the ability to take any desired action on the server, including changing web pages, reformatting the hard drive or adding new users to the local administrators group.
The vulnerability only affects web sites that use Microsoft Commerce Server; those using IIS are not at risk. Also, if a recommended tool has been applied to the server, the seriousness of the vulnerability would be significantly reduced. Specifically, if the URLScan tool were in use, the vulnerability could only be used to cause the service to fail, after which point it would automatically restart itself. The URLScan tool is not installed by default.
What causes the vulnerability?
The vulnerability results because an ISAPI filter that supports user authentication on Commerce Server 2000 contains an unchecked buffer. By providing specially malformed authentication information, an attacker could create a buffer overrun condition.
What's Microsoft Commerce Server?
Commerce Server is a web server product that's tailored for building e-commerce sites. It provides tools and features that simplify developing and deploying e-commerce solutions, and also provides tools that let the site administrator analyze the usage of the site.
Is Commerce Server different from Internet Information Server?
Yes. Commerce Server uses Internet Information Service (IIS) to provide basic web server capabilities, but also includes additional features and functions. Of particular importance in this case is the fact that the vulnerability lies within a component that ships as part of Commerce Server 2000 but not IIS. Because of this, IIS servers are at no risk from this vulnerability.
What's an ISAPI filter?
ISAPI (Internet Services Application Programming Interface) is a technology that enables developers to extend the functionality provided by a web server. An ISAPI filter is a dynamic link library (.dll) that uses ISAPI to respond to events that occur on the server.
What's the ISAPI filter associated with this vulnerability?
The vulnerability lies within the AuthFilter ISAPI filter. AuthFilter provides support for a variety of authentication methods. The vulnerability results because the code that processes the authentication data in several of these methods contains an unchecked buffer.
What would this vulnerability enable an attacker to do?
The vulnerability could enable an attacker, by providing data that overruns the buffer in AuthFilter, to overwrite memory within the Commerce Server process itself.
What would this enable an attacker to do?
Depending on the specific data the attacker chose, either of two effects could occur:
| • | If the data were randomly selected, the Commerce Server process would fail. |
| • | If the data were carefully selected, it could be possible for the attacker to alter the Commerce Server software while it was running. |
If the attacker provided random data, what would be required in order to restore normal operation?
Nothing. The Commerce Server process would automatically restart itself. However, any user sessions that were in process at the time of the attack could be lost.
If the attacker provided carefully selected data and altered the Commerce Server process, what could the modified process do?
The modified process would be able to take any action the attacker directed it to. The Commerce Server process runs with LocalSystem privileges, so the attacker could gain complete control over the server and taken any desired action on it.
Could this vulnerability be exploited by accident?
No. Authentication data for web sites is almost always submitted via a web form which, if properly implemented, would filter data like that used to exploit the vulnerability. (The sample web forms that ship with Commerce Server 2000 show how this should be done). The vulnerability could only be exploited by an attacker who sent malformed authentication data directly to the server, bypassing any web forms.
Is AuthFilter installed by default?
Yes. This is an appropriate default setting, because e-commerce sites virtually always require authentication support.
Commerce Server 2000 can also be configured to use other authentication methods. If another authentication method is used, then the system is not affected by this vulnerability.
I've installed the URLScan tool on my server. Will it prevent attacks via this vulnerability?
By default, URLScan would prevent an attacker from using the vulnerability to gain control over the server. This is because the default ruleset for Commerce Server outlaws certain types of data, without which it wouldn't be possible to modify the Commerce Server process to take meaningful action. On the other hand, even with URLScan installed, an attacker could still cause the Commerce Server process to fail. As a result, even customers who are using URLScan should install the patch.
How was this vulnerability discovered?
Microsoft discovered the vulnerability internally, as part of a security code review.
I heard that some sites already have the patch installed. Is this correct?
Yes. Microsoft contacted a small number of customers whose sites were at particular risk from this vulnerability and provided them with the patch, in order to give them an opportunity to secure their systems before the bulletin was released.
I'm running Site Server 3.0 Commerce Edition. Could I be affected by the vulnerability?
No. Site Server 3.0 and Site Server 3.0 Commerce Edition, the predecessor product to Commerce Server 2000, are not affected by the vulnerability.
What does the patch do?
The patch eliminates the vulnerability by instituting proper buffer handling within the AuthFilter ISAPI filter.
