Microsoft Security Program: Frequently Asked Questions: Microsoft Security Bulletin (MS99-035)

What's this bulletin about?
Microsoft Security Bulletin MS99-035 announces the availability of a patch that eliminates a vulnerability in Microsoft® Site Server® 3.0 (SS), Site Server 3.0, Commerce Edition (SSCE), and Microsoft Commercial Internet System® (MCIS) versions 2.0 and 2.5. Under certain conditions, the vulnerability could allow web site customers to map to the wrong database entry and potentially access personal data. Microsoft takes security seriously, and is providing the bulletin to inform customers of the vulnerability and what they can do about it.

What's the scope of the vulnerability?
The vulnerability could allow a customer to see and potentially change or use personal data belonging to another customer, such as credit card numbers, if accessing an e-commerce site via a gateway that caches web pages. This vulnerability would not lend itself to exploitation in an organized fashion, but would instead happen more or less randomly. As discussed below, sites that follow security best practices are unlikely to be affected by this vulnerability.

What is the vulnerability?
The vulnerability lies in how SS, SSCE, and MCIS request that a web browser set a cookie. When a web site wants to set a cookie, it makes the request via a directive known as a Set Cookie Header, which it includes in a web page that it returns to the browser. The header provides the information that the site wants to put into the cookie. Among the information that may be included is a GUID. GUIDs are frequently used as index values within an e-commerce sites' database.
The problem arises if a user accesses a web site via a gateway that caches web pages. An example of such a gateway would be a web proxy provided by an ISP or corporate network to speed access to commonly-used web pages. The affected products do not mark web pages containing Set Cookie Headers correctly to prevent them from being cached. As a result, users accessing the same web site via the same gateway may be served cached copies of the same page, with the result that they could have identical cookies. If the site uses GUIDs to uniquely identify customers, each of the affected users could map to the same customer record.
For example, suppose John accesses the Internet via a gateway that caches web pages. Now suppose he visits an e-commerce site that issues cookies and uses GUIDs to uniquely identify customer records in its database. At some point in the session, the site would send a page to John and create a cookie containing his GUID. The gateway would cache the page because of the error. Now suppose that Jane visits the same e-commerce site via the same gateway. It would serve her a cached copy of the web page, which would then set a cookie on Jane's machine containing John's GUID. The e-commerce site might then allow Jane to view personal information John had provided to the site, such as his credit card number or mailing address.

What sites are most likely to be affected?
The most likely sites to be affected are those that deliver data simply upon being presented with a valid GUID; that is, those that either perform no authentication or authenticate based on a GUID. For instance, sites that have automatic cookie authentication enabled could be affected. On the other hand, sites that perform authentication, and which check GUIDs for validity, are unlikely to be affected by this vulnerability.

Why can't GUIDs be used for authentication?
GUIDs should be unique, but they are not secret. Even without this vulnerability, Jane could monitor John's web session and "sniff the wire" to capture his cookie and determine his GUID. If the web site doesn't require authentication, Jane could supply John's GUID and view his personal data. Even if it does require authentication, Jane might still be able to use John's stolen GUID. If she has a valid account, she could authenticate using her own credentials, then supply John's GUID in order to map to his database entry. Unless the web site actually verifies that the GUID belongs to the person who logged on, Jane could still steal John's data.

How can security best practices reduce a site's exposure to this vulnerability?
Security best practices recommend that web sites perform authentication of some kind if they store customers' personal data. The more valuable the data, the stronger the authentication should be. They also should either use the authentication information itself in some form as a database index or, if a GUID is used, verify that it belongs to the user who authenticated before using it. Sites that follow these practices would have little exposure to this vulnerability.

Could a malicious user deliberately target another user's personal information via this vulnerability?
Although it's theoretically possible, it would be very difficult because so many of the factors are out of the control of even a determined malicious user. For example, Jane would need to ensure that John visited the e-commerce site via a gateway that caches web pages. She would need to know the web page he visited, visit it via the same gateway, and use the same proxy server. The latter is especially difficult to control; a large gateway may have several proxy servers in use, and users generally are dynamically moved between proxy servers depending on the loading. Even if all of the above fell into place, Jane would need to act quickly, before the cached page containing John's cookie information were purged. However, this vulnerability should be taken seriously nevertheless. A user who inadvertently stumbled upon another user's personal data might decide to make use of it for malicious purposes.

Does it matter whether customers configure their browsers to accept cookies or not?
No. The vulnerability doesn't lie in the cookies themselves, it lies in the way that the affected products try to set cookies. Even if user's browser doesn't accept cookies, the site may still send the request, and it is the request that is cached.

Is Microsoft Internet Information Server (IIS) affected?
No. There is a close relationship between IIS, SS, SSCE and MCIS, but the vulnerability at hand does not affect IIS.

What does the patch do?
The patch corrects the operation of the affected products so that they mark any web page containing a Set Cookie Header and a GUID so as to prevent it from being cached.

Who needs to apply the patch?
System administrators for e-commerce sites using any of the affected products should consider applying the patch.

What should customers do?
Microsoft recommends that customers assess the risk that this vulnerability poses to their safe computing and determine whether or not to apply the patch. The download location for the patch is provided in the security bulletin.

How can I tell if I installed the patch correctly?
Consult the table below and verify that you have the listed version of the two files.

What is Microsoft doing about this issue?

Where can I learn more about best practices for security?
The Microsoft Security web site is the best to place to get information about Microsoft security.

How do I get technical support on this issue?
Information on contacting Microsoft Technical Support is available at http://support.microsoft.com/contactussupport/?ws=support.

THE INFORMATION PROVIDED IN THE MICROSOFT KNOWLEDGE BASE IS PROVIDED "AS IS" WITHOUT WARRANTY OF ANY KIND. MICROSOFT DISCLAIMS ALL WARRANTIES, EITHER EXPRESS OR IMPLIED, INCLUDING THE WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. IN NO EVENT SHALL MICROSOFT CORPORATION OR ITS SUPPLIERS BE LIABLE FOR ANY DAMAGES WHATSOEVER INCLUDING DIRECT, INDIRECT, INCIDENTAL, CONSEQUENTIAL, LOSS OF BUSINESS PROFITS OR SPECIAL DAMAGES, EVEN IF MICROSOFT CORPORATION OR ITS SUPPLIERS HAVE BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES. SOME STATES DO NOT ALLOW THE EXCLUSION OR LIMITATION OF LIABILITY FOR CONSEQUENTIAL OR INCIDENTAL DAMAGES SO THE FOREGOING LIMITATION MAY NOT APPLY.

Top of page