Microsoft Security Bulletin (MS00-033): Frequently Asked Questions

What's this bulletin about?
Microsoft Security Bulletin MS00-033 announces the availability of a patch that eliminates a vulnerability in Microsoft® Internet Explorer. The vulnerability could allow a malicious web site operator to view files on the computer of a visiting user, under certain circumstances. Microsoft is committed to protecting customers' information, 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 malicious web site operator to view files on the computer of visiting user. The malicious web site operator would need to know the name and location of the file on the user's computer, and could only view files that can be opened in a browser window.
The vulnerability requires Active Scripting in order to succeed. If the malicious site were in a Security Zone that does not allow Active Scripting, the vulnerability could not be exploited.

What causes the vulnerability?
The vulnerability exists because it is possible, under very specific conditions, to violate IE's cross-domain security model in such a way as to allow a web site to read data that it should be prevented from reading.

What is meant by "IE's cross-domain security model", and how does it pertain to this vulnerability?
A good description of the IE cross-domain security model is provided in the FAQ for MS00-009 but in a nutshell, the IE cross-domain security model is designed to ensure that a browser window opened by a web site can only access data that belongs to that site.

Does this vulnerability let a browser window read what's in another browser window?
Almost. In this case, the issue is the ability of a window to read a frame that's in a different domain. A browser window can contain frames - subdivisions of a window that operate independently of each other. An example of a window that uses frames would be a web page in which a navigation bar on one side of the screen stays fixed while the content in the center of the screen changes as you make your selection. The navigation bar is in one frame, and the content is in another. If the frames belong to different domains, the IE cross-domain model should protect them from each other. However, in this vulnerability, flaws in two functions allow this protection to be breached.

What happens in this vulnerability?
In this vulnerability, a malicious web site opens a browser window on the user's computer. Within that window, the site opens a frame, and displays a file from the user's local computer in it. This is legitimate usage, but the window and the frame are in different domains - the window is in the web site's domain, while the frame is in the local file system domain - so the cross-domain security model should prevent them from reading each other's data. However, implementation flaws in two functions allow the window to access the data that is displayed in the frame. This would allow script running in the window to send the contents of the frame to the malicious user's web site.

What's the flaw in the functions?
The functions do not check which domain the frame is in before giving the window access to it.

What kinds of files could be viewed via this vulnerability?
Only files that can be opened in a browser window. Examples are .txt, .htm or .js files. Examples of file types that cannot be opened in a browser window include .dat, .doc, .exe, .jpg and other file types.

How likely am I to be affected by this vulnerability?
It depends on your web browsing habits. The key thing to remember is that you have to visit a malicious web site in order to be affected by it. Most people visit a small number of familiar, professionally-operated web sites, and it's unlikely that such a site would pose any risk. Users who surf lots of unknown web sites would be at greater risk. However, Security Zones provide a great way to manage your risk, and we recommend that customers use them.

Could this vulnerability be exploited accidentally?
No. The steps that a web site would need to take in order to exploit this vulnerability are extremely unlikely to be useful for any purpose except exploiting this vulnerability

What does the patch do?
The patch changes the two affected functions so that they perform appropriate domain checking before granting access to any data.

Where can I get the patch?
The download location for the patch is provided in the "Patch Availability" section of the security bulletin 

How can I tell if I installed the patch correctly?
The KB article provides a manifest of the files in the patch package. The easiest way to verify that you've installed the patch correctly is to verify that these files are present on your computer, and have the same sizes and creation dates as shown in the KB article.

What is Microsoft doing about this issue?

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

How do I get technical support on this issue?
Microsoft Technical Support can provide assistance with this or any other product support issue.

Top of section

What's this bulletin about?
Microsoft Security Bulletin MS00-033 announces the availability of a patch that eliminates a vulnerability in Microsoft® Internet Explorer. Under some conditions, the vulnerability could allow a malicious web site operator to access cookies that have been placed on the computer of a visiting user by other web sites. Microsoft is committed to protecting customers' information, 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?
This is primarily a privacy compromise. If a malicious web site operator were able to entice a visiting user into clicking a link, he could read or change a cookie that another site has issued the user, or could add a new cookie that ostensibly was issued by another web site.
The degree of the privacy compromise would depend on the specific data present in the cookies on the user's machine. Many web sites, such as Microsoft's, follow practices designed to limit the amount of private data in cookies. Likewise, it is doubtful that a malicious user could modify a cookie in a way that would be meaningful to the site that issued it; at worst, the ability to change or add cookies would allow the malicious user to corrupt the user's cookies.
The vulnerability would not allow a malicious web site operator to determine what sites' cookies are on the visitor's system. Instead, he would need to blindly try various web sites' addresses until he found one whose cookie happened to be on the system - and he would need to entice the user into clicking a link for each cookie he tried to steal. Finally, the vulnerability requires Active Scripting in order to succeed. If the malicious site were in a Security Zone that does not allow Active Scripting, the vulnerability could not be exploited.

What causes the vulnerability?
Internet Explorer's security architecture is designed to only allow a cookie to be read by the web site that issued it. However, by using a deliberately-malformed URL, it would be possible for a malicious web site operator to bypass this restriction and recover cookies issued by other sites.

What is a cookie?
A cookie is a small data file that contains information about how you use a particular web site. Cookies enable web sites to customize each customer's web experience. For instance, if you visit a web site that sells a variety of merchandise, it might record in the cookie the fact that you typically buy sporting goods when you visit. The next time you visit the site, it might read the cookie and then customize its pages to show you newly-stocked bowling shoes rather than, say, the Spring formal gown collection.
Every web site you visit could potentially ask you to accept a cookie. However, by design, each site should only be able to access the cookies that it provided. The root problem in this vulnerability is that it is possible under certain circumstances for a web site to access a cookie that you accepted from another site, and read it or change it. Likewise, a web site could add a cookie that ostensibly belongs to another site.

Why should I care if other sites see my cookies?
It's possible that the cookie could contain personal information that you don't want other sites to see.

What kind of information do cookies contain?
It depends on the specific web sites you visit and what kind of practices they follow. Microsoft sites never store personal information such as email addresses, credit card numbers, personal addresses, etc, in the cookies they generate. However, every web site has its own practices, and it is possible that your cookies could contain personal information.

Can a web site put a cookie on my machine without my permission?
No. A web site may recommend that you accept its cookie in order to let it give you the best web experience, but it cannot force you to accept a cookie. Even with this vulnerability, a malicious site could only change a cookie or place a new one on your machine if had configured IE to accept cookies.

How can I configure whether I accept cookies or not?
In Internet Explorer, the handling of cookies is determined by the Security Zone that the site is in. To view or change the setting, follow these steps:

Do cookies identify me?
Cookie technology is designed to protect your anonymity, but much depends on the practices of the specific web sites you visit. Cookies identify the user via a Globally Unique Identifier, or GUID, so there is never a need to identify you by name. However, if a site stores other types of information, it may divulge your identity, either explicitly or implicitly.
In the example cited above, let's suppose that the web site is careful to never store personal data in cookies. In this case, a malicious web site operator who exploited this vulnerability might be able to learn that Visitor #123456 wears a size 9 bowling shoe, but little else. On the other hand, let's assume that the web site is not careful about the information it stores, and has recorded the mailing address that you gave when you last bought something there. In this case, personal information would clearly be at risk.
Between the two extremes is a gray area. Even if you visited web sites that are reasonably conscientious regarding the handling of personal information, it might be possible for the malicious web site operator to collect several cookies and correlate the small amount of personal information in each of them to build a more complete picture of who you are.

How does the vulnerability allow someone to read cookies?
Internet Explorer's security architecture is designed to only allow a cookie to be read by the web site that issued it. However, by using a deliberately-malformed URL, it would be possible for a malicious web site operator to bypass this restriction and recover a cookie issued by another site.

Could the malicious web site operator read my cookies if I just visited his site ?
No. He would need to entice you into clicking on a link that contained the specific malformed URL. He would need to do this for each cookie he wanted to read.
For example, if he wanted to read the cookie that you had accepted from Web site A, he would need to get persuade you to click on a link; if he also wanted to read the cookie that you had accepted from Web site B, he would need to persuade you to click on a different link. This would significantly restrict the malicious user's ability to exploit this vulnerability, because there is a limit to how many links the user could be persuaded to click.

How would the malicious web site operator know which sites I've accepted cookies from?
He wouldn't be able to tell. This vulnerability does not provide a way to inventory the cookies on a user's machine.
The combination of the inability to inventory the cookies on a user's machine and the inability to access more than one cookie per link would be a significant impediment to exploiting this vulnerability. It would mean that the malicious web site operator would need to host many links on the page, one for each web site whose cookie he would like to try to recover. He would then need to entice a visiting user into clicking links that match the cookies on his machine. However, he would have no way to know which links these are, so he would need to blindly entice the user into clicking as many links as possible, in the hope that the user would happen to click the right one.

Could the malicious web site operator change the data in my cookies?
Yes. However, keep in mind that every web site determines what information is in its cookies, and how it's stored. It could be difficult for the malicious user to change the data in a cookie in a meaningful way.
The most likely outcome would be that the malicious user would corrupt the cookie and make it unusable. This wouldn't prevent you from visiting the site associated with the cookie - but it might mean that the site wouldn't be able to customize its content for you.

Could the malicious web site operator add new cookies?
Yes. It would be possible for a malicious web site operator to add a cookie that ostensibly belongs to another site. However, as in the case of modifying a cookie, it could be difficult or impossible for him to know what data would be meaningful for the other web site. The vulnerability wouldn't provide any way for the malicious user to compel a user to visit another web site after he added a bogus cookie for it.

How likely am I to be affected by this vulnerability?
It depends on your web browsing habits. The key thing to remember is that you have to visit a malicious web site in order to be affected by it. Most people visit a small number of familiar, professionally-operated web sites, and it's unlikely that such a site would pose any risk. Users who surf lots of unknown web sites would be at greater risk.

Could this vulnerability be exploited accidentally?
No. The specific malformed URL at issue here is extremely unlikely to occur by accident.

What does the patch do?
The patch restores the expected operation to the IE security model, and prevents any web site from viewing another site's cookie.

Where can I get the patch?
The download location for the patch is provided in the "Patch Availability" section of the security bulletin 

How can I tell if I installed the patch correctly?
The KB article provides a manifest of the files in the patch package. The easiest way to verify that you've installed the patch correctly is to verify that these files are present on your computer, and have the same sizes and creation dates as shown in the KB article.

What is Microsoft doing about this issue?

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

How do I get technical support on this issue?
Microsoft Technical Support can provide assistance with this or any other product support issue.

Top of section

What's this bulletin about?
Microsoft Security Bulletin MS00-033 announces the availability of a patch that eliminates a vulnerability in Microsoft® Internet Explorer. The vulnerability could allow a malicious web site operator to run code of his choice on the computer of a visiting user. Microsoft is committed to protecting customers' information, 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?
This a buffer overrun vulnerability. By providing specially-malformed information when invoking an ActiveX component, a malicious web site operator could cause code of his choice to run on the computer of a visiting user. Such code could take any action the user himself could take, including adding, changing or deleting data; reformatting the hard drive; or communicating with a web site.
The vulnerability only occurs in very particular conditions when certain other attributes also are specified. Also, if a web site is in a Security Zone that does not allow ActiveX components to run, the vulnerability could not be exploited.

What causes the vulnerability?
There is an unchecked buffer in the code that is used to specify parameters for an ActiveX components. By providing a carefully-crafted data to one of the object attributes, code could be made to run on the user's machine via a buffer overrun.

What do you mean by "specifying parameters" for an ActiveX component?
Before an ActiveX component can be used, the web page that wants to use it must identify which component it wants to use and provide any needed parameters. For instance, it must provide the component's unique identifier (called a ClassID), where the component can be found if not already on the machine, and any needed operational parameters (for instance, if a component displays a dialogue, the operational parameters might include the size of the dialogue on the screen).
The vulnerability results because one of the attributes used to specify the component contains an unchecked buffer. However, the unchecked buffer is only exposed when the affected attribute is specified in conjunction with another, unrelated component.

Is this a flaw in the ActiveX technology?
No. This vulnerability has nothing to do with the ActiveX technology per se, and in particular it has nothing to do with the ActiveX security model. The vulnerability results because there is an unchecked buffer in a function that can be called by a web page. The fact that the function in question is related to ActiveX has little to do with the vulnerability itself.

How could a malicious user exploit this vulnerability?
A malicious web site operator could code a web page on his site to specify a bogus ActiveX component, simply for the purpose of overrunning the buffer. If he did this, and a person who visited his site had ActiveX enabled, the malicious web site operator could potentially make code of his choice run on the visitor's computer.
Similarly, a malicious user could create an HTML mail that specified a bogus ActiveX component and mail it to someone. When the recipient opened it, it could run code of the sender's choice on the recipient's computer, if he had ActiveX enabled in the Security Zone that his mail runs in.

What could code run via this vulnerability do?
The code would run on the user's machine, in the user's security context. It could therefore do anything that the user himself could do. If the user were using an account with very limited privileges, the code might be able to do very little. On the other hand, if the user were running in an administrator account, there would be virtually nothing the code could not do.
This is one reason why Microsoft recommends that customers always adhere to the "least privilege" guideline. Especially when using systems like Windows 2000 that provide the ability to tightly regulate users' privileges, there is always a payoff to limiting users to having only the minimal privileges they need.

Buffer overruns usually also carry a denial of service threat. Does this one?
Generally, an unchecked buffer can be overrun in either of two ways. If overrun with random data, it can be used to cause the affected program to crash in a denial of service attack. Alternatively, if overrun with carefully-selected data, it can be used to run code.
In this case, both types of attack are feasible. However, the first case doesn't really pose a security risk. If a web site overran the buffer with random data, it would cause IE to crash but would have no other effect. The user could simply restart IE and continue browsing.

How likely am I to be affected by this vulnerability?
It depends on your web browsing habits. The key thing to remember is that you have to visit a malicious web site in order to be affected by it. Most people visit a small number of familiar, professionally-operated web sites, and it's unlikely that such a site would pose any risk. Users who surf lots of unknown web sites would be at greater risk. However, Security Zones provide a great way to manage your risk, and we recommend that customers use them.

How would Security Zones help me protect against this vulnerability?
The Security Zones feature of IE allows you to categorize the web sites you visit and specify what the sites in a particular category should be allowed to do. Among the options you can choose is whether or not web sites should be able to use ActiveX components or not. A malicious web site operator could only exploit this vulnerability if ActiveX components are allowed to run on your browser.
Microsoft recommends that customers routinely use the Security Zones feature. We recommend putting the sites that you visit frequently and trust into the Trusted Zone. All sites that you haven't otherwise categorized will reside in the Internet Zone. You can then configure the zones to give the appropriate privileges to the web sites in these zones.

Could this vulnerability be exploited accidentally?
No. In order to exploit this vulnerability, a malicious user would need to carefully craft the malformed data and deliberately host it on his web site or send it via HTML mail to someone.

How common are buffer overrun vulnerabilities?
It's been estimated that anywhere from two-thirds to three-quarters of all computer security vulnerabilities involve a buffer overrun. They occur in all vendors' products, and are an industry problem. Microsoft is working hard to develop coding and testing methods that will reduce or eliminate buffer overrun vulnerabilities in its software.

What does the patch do?
The patch eliminates the unchecked buffer.

Where can I get the patch?
The download location for the patch is provided in the "Patch Availability" section of the security bulletin 

How can I tell if I installed the patch correctly?
The KB article provides a manifest of the files in the patch package. The easiest way to verify that you've installed the patch correctly is to verify that these files are present on your computer, and have the same sizes and creation dates as shown in the KB article.

What is Microsoft doing about this issue?

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

How do I get technical support on this issue?
Microsoft Technical Support can provide assistance with this or any other product support issue.

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 section