Subject: [NT] Patch Available for the "Frame Domain Verification", "Unauthorized Cookie Access", and "Malformed Component Attribute" Vulnerabilities Date: Sat, 27 May 2000 09:42:36 +0200 From: support@securiteam.com Patch Available for the "Frame Domain Verification", "Unauthorized Cookie Access", and "Malformed Component Attribute" Vulnerabilities -------------------------------------------------------------------------------- SUMMARY Microsoft has released a comprehensive patch that eliminates three security vulnerabilities in Internet Explorer 4 and 5: - The "Frame Domain Verification" vulnerability, which allows a malicious web site operator to read local files on the computer of a visiting user. - The "Unauthorized Cookie Access" vulnerability, which allows a malicious web site operator to access cookies belonging to a visiting user. - The "Malformed Component Attribute" vulnerability, which allows a malicious web site operator to run arbitrary code on the computer of a visiting user. DETAILS Vulnerable systems: - Microsoft Internet Explorer 4.0 - Microsoft Internet Explorer 4.01 - Microsoft Internet Explorer 5.0 - Microsoft Internet Explorer 5.01 The three security vulnerabilities eliminated by this patch are unrelated to each other except by the fact that they all occur in the same .dll. Microsoft has packaged them together for customer convenience. The vulnerabilities are: - "Frame Domain Verification" vulnerability. When a web server opens a frame within a window, the IE security model should only allow the parent window to access the data in the frame if they are in the same domain. However, two functions available in IE do not properly perform domain checking, with the result that the parent window could open a frame that contains a file on the local computer, then read it. This could allow a malicious web site operator to view files on the computer of a visiting user. The web site operator would need to know (or guess) the name and location of the file, and could only view file types that can be opened in a browser window. - "Unauthorized Cookie Access" vulnerability. By design, the IE security model restricts cookies so that they can be read only by sites within the originator's domain. However, by using a specially-malformed URL, it is possible for a malicious web site operator to gain access to another site's cookie and read, add or change them. A malicious web site operator would need to entice a visiting user into clicking a link in order to access each cookie, and could not obtain a listing of the cookies available on the visitor's system. - "Malformed Component Attribute" vulnerability. The code used to invoke ActiveX components in IE has an unchecked buffer and could be exploited by a malicious web site operator to run code on the computer of a visiting user. The unchecked buffer is only exposed when certain attributes are specified in conjunction with each other. The patch also eliminates a new variant of the previously-addressed WPAD Spoofing vulnerability. Patch Availability: - http://www.microsoft.com/windows/ie/download/critical/patch6.htm Note: The patches require IE 4.01 Service Pack 2 or IE 5.01 to install. Customers using versions prior to these may receive a message reading: "This update does not need to be installed on this system". This message is incorrect. More information is available in KB article Q262509. "Malformed Component Attribute" Vulnerability: Frequently Asked Questions: What's the scope of the vulnerability? This is a buffer overrun vulnerability. By providing specially-malformed information when invoking an ActiveX component, a malicious web site operator could cause code of her 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 component. 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. How could a malicious user exploit this vulnerability? A malicious web site operator could code a web page on her site to specify a bogus ActiveX component, simply for the purpose of overrunning the buffer. If she did this, and a person who visited her site had ActiveX enabled, the malicious web site operator could potentially make code of her 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 Microsoft recommends 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. What does the patch do? The patch eliminates the unchecked buffer. "Unauthorized Cookie Access" Vulnerability: Frequently Asked Questions: 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, she would need to blindly try various web sites' addresses until she found one whose cookie happened to be on the system - and she would need to entice the user into clicking a link for each cookie she 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: 1) In Internet Explorer, choose the Tools menu entry, then Internet Options. 2) Select the Security tab, then click the zone you'd like to change, followed by the Custom button. 3) Scroll down to the header titled Cookies, and click the radio button that describes how you'd like to handle cookies. You can choose to accept cookies from all sites in the zone, refuse to accept any, or be prompted whenever a site wants to send you a cookie. 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. She would need to entice you into clicking on a link that contained the specific malformed URL. She would need to do this for each cookie she wanted to read. For example, if she wanted to read the cookie that you had accepted from Web site A, she would need to get persuade you to click on a link; if she also wanted to read the cookie that you had accepted from Web site B, she 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? She 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 she would like to try to recover. She would then need to entice a visiting user into clicking links that match the cookies on his machine. However, she would have no way to know which links these are, so she 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. 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. "Frame Domain Verification" Vulnerability: Frequently Asked Questions: 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? 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? 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. 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. ADDITIONAL INFORMATION The information has been provided by: Microsoft Product Security. ======================================== 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.