Free Republic
Browse · Search
News/Activism
Topics · Post Article

Skip to comments.

Microsoft warns, "Don't Trust Us"! [SCARY WINDOWS ALERT]
Microsoft Web Site ^ | 11/21/02 | Microsoft Security Bulletin MS02-065

Posted on 11/21/2002 7:55:28 AM PST by toupsie

Microsoft Security Bulletin MS02-065

Print Print

Buffer Overrun in Microsoft Data Access Components Could Lead to Code Execution (Q329414)

Originally posted: November 20, 2002

Summary

Who should read this bulletin: Customers using Microsoft® Windows®, particularly those who operate web sites or browse the Internet.

Impact of vulnerability: Run code of attacker’s choice

Maximum Severity Rating: Critical

Recommendation: Users should apply the patch immediately.

Affected Software:

Note: The vulnerability does not affect Windows XP, despite the fact that it uses Internet Explorer 6.0. Windows XP customers do not need to take any action.

End User Bulletin: An end user version of this bulletin is available at: http://www.microsoft.com/security/security_bulletins/ms02-065.asp

Technical details

Technical description:

Microsoft Data Access Components (MDAC) is a collection of components used to provide database connectivity on Windows platforms. MDAC is a ubiquitous technology, and it is likely to be present on most Windows systems:

MDAC provides the underlying functionality for a number of database operations, such as connecting to remote databases and returning data to a client. One of the MDAC components, known as Remote Data Services (RDS), provides functionality that support three-tiered architectures – that is, architectures in which a client’s requests for service from a back-end database are intermediated through a web site that applies business logic to them. A security vulnerability is present in the RDS implementation, specifically, in a function called the RDS Data Stub, whose purpose it is to parse incoming HTTP requests and generate RDS commands.

A security vulnerability resulting from an unchecked buffer in the Data Stub affects versions of MDAC prior to version 2.7 (the version that shipped with Windows XP). By sending a specially malformed HTTP request to the Data Stub, an attacker could cause data of his or her choice to overrun onto the heap. Although heap overruns are typically more difficult to exploit than the more-common stack overrun, Microsoft has confirmed that in this case it would be possible to exploit the vulnerability to run code of the attacker’s choice on the user’s system.

Both web servers and web clients are at risk from the vulnerability:

Clearly, this vulnerability is very serious, and Microsoft recommends that all customers whose systems could be affected by them take appropriate action immediately.

Before deploying the patch, customers should familiarize themselves with the caveats discussed in the FAQ and in the Caveats section below.

Mitigating factors:

Web Servers

Web clients

Severity Rating:

MDAC 2.1 Critical

MDAC 2.5 Critical

MDAC 2.6 Critical

MDAC 2.7 Not affected

Internet Explorer 5.01 Critical

Internet Explorer 5.5 Critical

Internet Explorer 6.0 Critical

The above assessment is based on the types of systems affected by the vulnerability, their typical deployment patterns, and the effect that exploiting the vulnerability would have on them. This vulnerability is rated critical because an attacker could take over an IIS server or an Internet Explorer client and run code. Any IIS server with MDAC and all Internet Explorer clients should apply the patch immediately.

Vulnerability identifier: CAN-2002-1142

Tested Versions:
Microsoft tested MDAC 2.1, 2.5, 2.6 and 2.7 to assess whether they are affected by the server-side vulnerability. In addition, Microsoft also tested Internet Explorer 5.01, 5.5 and 6.0 to assess whether they are affected by the client-side vulnerability. Previous versions are no longer supported, and may or may not be affected by these vulnerabilities.

Frequently asked questions

What vulnerability is eliminated by the patch?

This patch eliminates a security vulnerability affecting many web servers and clients. However, before installing it, it’s worth reviewing an important caveat associated with the patch.






What caveats are associated with the patch?

Although the patch does address the vulnerability, there is a niche scenario through which a patched system could, under unusual conditions, be made vulnerable again. This scenario results because it is not possible to set the “Kill Bit” used by one of the vulnerable components.

What’s the "Kill Bit"?

The Kill Bit is a method by which an ActiveX control can be prevented from ever being invoked via Internet Explorer, even if it’s present on the system. (More information on the Kill Bit is available in Microsoft Knowledge Base article Q240797). Typically, when a security vulnerability involves an ActiveX control, the patch delivers a new control and sets the Kill Bit on the vulnerable control. However, it isn’t feasible to do so in this case.

Why isn’t it feasible to set the Kill Bit in this case?

The ActiveX control involved in these vulnerabilities is used in many applications and web pages to access data. Many applications, including third-party applications, contain hard-coded references to it; if the patch set the Kill Bit, the web pages would no longer function at all – even with the new, corrected version. As a result, the patch updates the control to remove the vulnerabilities, but does not provide a brand-new control and set the Kill Bit on the old one.

What the risk associated with taking this approach?

Because the ActiveX control at issue here has been digitally signed by Microsoft, and the signature is still valid, it could be possible under certain conditions for an attacker to re-introduce the old, vulnerable version of the control onto a system that had been patched, thereby making it vulnerable again. In order for this happen, though, the user would need to either visit a web site operated by a malicious person or open an HTML mail from one. (It’s worth noting that in the case of HTML mail, customers using either Outlook 6 or Outlook 2002 in the default configuration, or Outlook 98 or 2000 in conjunction with the Outlook Email Security Update, would be at no risk).

Why would an attacker be able to silently re-introduce the old version of the control? Shouldn’t there be a warning message?

A warning message is generated anytime there’s an error associated with a digital signature (e.g., a bad signature or expired certificate) or the signer isn’t trusted. But in this case, the digital signature on the old version of the control is still valid, and the signer is Microsoft – which is a trusted publisher in many cases. Because of this, most users would not see a warning message of any kind if the old control was re-introduced.

Why not revoke the certificate that was used to sign the control?

The certificate that was used to sign the control is still valid – the problem lies in the control, not the certificate. In addition, a number of controls have been signed using the same certificate, and revoking the certificate would cause all of them to become invalid.

What steps could I follow to prevent the control from being silently re-introduced onto my system?

The simplest way is to make sure you have no trusted publishers, including Microsoft. If you do that, any attempt by either a web page or an HTML mail to download an ActiveX control will generate a warning message. Here’s how to empty the Trusted Publishers list:

  1. In Internet Explorer, choose Tools, then Internet Options.
  2. Select the Content tab. In the Certificates section of the page, click on Publishers.
  3. In the Certificates dialog, click on the Trusted Publishers tab.
  4. For each certificate in the list, click on the certificate and then select Remove. Confirm that you want to remove the entry.
  5. When you’ve removed all entries from the list, select Close to close the Certificates dialog, then click on OK to close the Internet Options dialog.

After emptying the Trusted Publishers list, if I do see a warning saying that a web site or an HTML mail wants to download a control, how can I decide whether to let it proceed?

The best criterion to use is whether you trust the web site or the sender of the HTML mail. If you don’t trust the web site offering the control, cancel the download.

Will Microsoft eventually set the Kill Bit on this control?

Yes. Microsoft is developing a new technology that will enable it to set the Kill Bit on the vulnerable version of the control without forcing users to re-author web pages containing references to these controls. When the new technology is available, we will ensure that this fix uses it.






What’s the scope of the vulnerability?

This is a buffer overrun vulnerability. An attacker who successfully exploited it could gain complete control over an affected system, thereby gaining the ability to take any action that the legitimate user could take. This could include creating, modifying or deleting data on the system, reconfiguring it, reformatting the hard drive, or running programs of the attacker’s choice on it. The vulnerability poses a risk both to web servers and web clients, and Microsoft recommends that all users take action immediately to ensure that their systems are protected against it.

Windows XP systems, whether serving as Web servers or clients, are not affected by the vulnerability. Other systems have varying degrees of options available to them:

What causes the vulnerability

The vulnerability results because of an unchecked buffer in one of the Microsoft Data Access Components – specifically, the Remote Access Service Data Stub.

What are the Microsoft Data Access Components?

Microsoft Data Access Components (MDAC) is a collection of components that make it easy for programs to access databases and manipulate the data within them. Modern databases may take a variety of forms (e.g., SQL databases, Access databases, XML files, and so forth) and be housed in a variety of locations (e.g., on the local system or on a remote database server). MDAC provides a consolidated set of functions for working with all of them in a consistent manner.

Do I have MDAC on my system?

The answer is almost certainly yes. MDAC is a ubiquitous technology:

What are the Remote Data Services?

Remote Data Services (RDS) is a component of MDAC. RDS provides a function that’s frequently needed in Internet-based scenarios, namely, the ability to access data sources indirectly through a three-tiered system. If you’ve ever visited a web site that implements a search function, you’ve participated in a three-tiered database system. In such a system, the user (who occupies the so-called User Interface Tier) interrogates a database (which occupies the so-called Database Tier), but doesn’t do so directly. Instead, he or she provides requests to an intermediary tier, known as the Business Logic Tier. In most Internet scenarios, the Business Logic Tier resides on a web server.

The purpose of the Business Logic Tier is to determine what the user wants, translate that request into a series of database commands, check those commands to ensure that the user is really allowed to make them, and then send them to the Database Tier. When the response from the database arrives, the Business Logic Tier may need to translate the results into a form that’s more meaningful for the user. RDS provides many of the functions needed to implement the Business Logic Tier of such a system; specifically, it provides functions that, on a web server, allow it to interpret database requests from a client and, on a client, interpret responses to such requests when they're received from the web server.

What’s wrong with RDS?

One of the components of RDS that was delivered in MDAC 2.4, 2.5 and 2.6 contains an unchecked buffer. On the server side, this component is known as the RDS Data Stub and on the client side it is called the Data Space cotrol. These components implement some of the functionality of the Business Logic Tier. In particular, the Data Stub processes HTTP requests and transforms them into RDS requests that can then be passed to the RDS core functionality for processing.

What do you mean when you say that the RDS Data Stub has an unchecked buffer?

A buffer is a location in memory that’s allocated to hold data of some type. It’s the responsibility of the program that owns the buffer (in this case, the RDS Data Stub) to ensure that it never puts more data into the buffer than it can hold – otherwise, the data will spill into surrounding memory and overwrite the data there, resulting in a buffer overrun.

Buffer overruns are dangerous. In the least serious case, if a buffer were overrun with random data, it would have the effect of corrupting the memory that it overran; in most cases, this would lead to the program, or potentially the system itself, failing. But if the buffer were overrun with carefully selected data, the effect could be to, in essence, alter the program so that it now performed new functions. Clearly, any flaw that could enable an attacker to turn an already running program to his or her own purposes is serious.

What would this vulnerability enable an attacker to do?

This vulnerability would enable an attacker to send an HTTP request to an affected system that, when processed by the RDS Data Stub, would cause a buffer overrun. Potentially, any system that has MDAC, and in particular RDS, installed and running is at risk. But two types of systems are at special risk:

Who could exploit the vulnerability?

It would depend on whether the attacker wanted to exploit the vulnerability against a web server or a web client.

I run a web server. How can I tell whether my system is at risk?

In order for a web server to be at risk from the vulnerability, both of the following must be true:

It’s important to keep in mind, though, that if the web server is also used as a web client occasionally (that is, if you browse the web or read email from the server), it could still be at risk. The server-based and client-based vulnerabilities are completely independent of one another.

I’ve installed the URLScan tool on my web server. Will it help protect my system?

Yes. The URLScan tool restricts the type of HTTP requests that the server will process. Of particular interest in this case is the fact that URLScan’s default ruleset will only allow HTTP requests to be processed by the server if they consist of only ASCII data. It would be extremely difficult to create a request that would alter the operation of the IIS service using only valid ASCII data; however, even in this case, an attacker could still cause the service to fail.

My system is a web client. How can I tell if it’s at risk?

The first thing to do is check whether you’re running Windows XP. If you are, your system is at no risk – the version of MDAC that shipped with Windows XP does not contain the vulnerability.

All other versions of Windows are at risk. Several versions of Windows ship with a vulnerable version of MDAC, as did several versions of Internet Explorer. As a result, systems running anything other than Windows XP are almost certainly at risk and need the patch.

You said that Windows XP isn’t vulnerable, but that customers using Internet Explorer 6.0 are. Yet Internet Explorer 6.0 shipped as part of Windows XP. Why isn’t Windows XP vulnerable?

When Internet Explorer 6.0 is installed on a system, it checks to see whether there’s a version of MDAC already installed; if there isn’t one, it installs it. In the case of Windows XP, a version of MDAC is already installed – one that isn’t affected by the vulnerability – and so Internet Explorer 6.0 uses that version.

Does the web site-based or HTML mail-based attack vector pose the greater threat to web clients?

There would be advantages and disadvantages for the attacker regardless of the attack vector chosen. The primary advantage, from the attacker's perspective, of hosting the web page on a web site is that most computers would be vulnerable to such an attack unless the patch had been installed. The primary disadvantage is that the attacker wouldn't have any way to force users to visit the site. Instead, he or she would need to lure them there, typically by getting them to click a link that would take them to the attacker's site.

In contrast, sending the web page as an HTML mail would offer the attacker the advantage of being able to target specific users, and send it directly to them. The primary disadvantage is that the HTML mail-based attack would fail on many users' systems. Specifically, even without the patch, the vulnerability could not be exploited via HTML mail on systems where Outlook 98 or Outlook 2000 were used in conjunction with the Outlook Email Security Update, or Outlook Express 6 or Outlook 2002 were used in their default configurations.

My system is a web server, and I've confirmed that it's not vulnerable. However, I also sometimes browse the Web from that system. Do I need to install the patch?

Yes. Any system that acts as a web client needs the patch. This is true even if the system also happens to be a web server, and even if the web server has been configured in a way to protects it from the vulnerability.

Is there a separate patch for MDAC and Internet Explorer?

No. We have developed a single patch that will install the fixes for both MDAC and Internet Explorer at the same time. The patch will determine what version of MDAC, if any, your system is using and apply the fixes to all vulnerable components on it. If there are no vulnerable components on the system, the patch will do nothing.

I don’t know if MDAC is installed. Do I need to determine that first before I apply the patch?

No. The patch will determine what version of MDAC, if any, is installed on your system and apply the needed fixes.

Patch availability

Download locations for this patch

Additional information about this patch

Installation platforms:
The patch can be installed on the following systems:

Inclusion in future service packs:

Reboot needed:

Patch can be uninstalled: No.

Superseded patches: None.

Verifying patch installation:

Caveats:

Users can always upgrade to the latest version of MDAC since MDAC 2.7 is not affected by this vulnerability.

Localization:
Localized versions of this patch are available at the locations discussed in "Patch Availability".

Obtaining other security patches:
Patches for other security issues are available from the following locations:

Other information:

Acknowledgments

Microsoft thanks  Foundstone Research Labs for reporting this issue to us and working with us to protect customers.

Support:

Security Resources: The Microsoft TechNet Security Web Site provides additional information about security in Microsoft products.

Disclaimer:
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.

Revisions:



TOPICS: Culture/Society; Miscellaneous; News/Current Events; Technical
KEYWORDS: microsoft; microsoftwindows
Navigation: use the links below to view more comments.
first 1-2021-23 next last
Windows Users: Kiss your data goodbye. Now you can't even trust updates from Microsoft or any web page.
1 posted on 11/21/2002 7:55:28 AM PST by toupsie
[ Post Reply | Private Reply | View Replies]

To: toupsie
Uh...I guess we should all go out and buy a Mac now. ... Hahahahaha!
2 posted on 11/21/2002 7:58:34 AM PST by billybudd
[ Post Reply | Private Reply | To 1 | View Replies]

To: toupsie
Microsoft's Software Engineers are outnumbered 1000's to 1 in the number of people writing Windows code vs. the number of people trying to find flaws in the code. Bugs are guaranteed to occur in software as complex as Windows, but I have always been happy with how responsive Microsoft is about fixing those errors.
3 posted on 11/21/2002 8:02:56 AM PST by Badger1
[ Post Reply | Private Reply | To 1 | View Replies]

To: toupsie
That reminds me. I have Windows ME and it automatically searches for updates on the net. This is very annoying to me and possibly dangerous now. How do I stop the Windows Update program from automatically running ?
4 posted on 11/21/2002 8:19:58 AM PST by BSunday
[ Post Reply | Private Reply | To 1 | View Replies]

To: Badger1
I have always been happy with how responsive Microsoft is about fixing those errors.

I have always been unhappy that they cannot keep up with those that breaking their security. Doesn't matter how fast they are if they can't keep up. They need to scrap Windows and start over.

5 posted on 11/21/2002 8:43:48 AM PST by toupsie
[ Post Reply | Private Reply | To 3 | View Replies]

To: BSunday
That reminds me. I have Windows ME and it automatically searches for updates on the net. This is very annoying to me and possibly dangerous now. How do I stop the Windows Update program from automatically running ?

Install Linux or buy a Mac. Remember this is a security problem that we know about. The scary things are the ones we don't know about!

6 posted on 11/21/2002 8:45:13 AM PST by toupsie
[ Post Reply | Private Reply | To 4 | View Replies]

To: toupsie
They need to scrap Windows and start over.

Again, "Microsoft's Software Engineers are outnumbered 1000's to 1 in the number of people writing Windows code vs. the number of people trying to find flaws in the code".

Scrapping Windows and starting over would not change anything. Again, "Bugs are guaranteed to occur in software as complex as Windows." There has never been a piece of software written that does not have bugs. I bet there are just as many bugs in the MAC OS as there are in Windows. But since the MAC OS has such a small market share, not as many people are out there trying to find them.
7 posted on 11/21/2002 8:50:01 AM PST by Badger1
[ Post Reply | Private Reply | To 5 | View Replies]

To: toupsie
Yawn. Just update to MDAC 2.7 - everyone else did a year ago.
8 posted on 11/21/2002 8:52:04 AM PST by Mr. Jeeves
[ Post Reply | Private Reply | To 1 | View Replies]

To: toupsie
you are either a pure anti-MS type or just don't have much technical experience, do you? This is a garden variety bug you're freaking out over. If this kind of thing really scares you I suggest you shut down your computer immediately, put on your tin foil hat and remove proceed directly to your bank, remove all your money and stow it underneath your mattress, and then take cover there as well. seriously.
9 posted on 11/21/2002 8:56:30 AM PST by Steven W.
[ Post Reply | Private Reply | To 1 | View Replies]

To: Steven W.
Yep, just a garden variety type of bug that gives up control of your PC to someone else.
10 posted on 11/21/2002 9:02:29 AM PST by lelio
[ Post Reply | Private Reply | To 9 | View Replies]

To: BSunday
Well it doesn't "search" the net, it checks it at MS, but it is annoying. More than likely the update check is in System Agent (which should be showing up on your task bar) as a job remove that job and it will stop. I always just disabled System Agent outright, all those messages about not being able to do whatever because my computer wasn't on at 2 AM just irritated me. I forgot how I turned it off though (it's not real intuitive, they really liked it).
11 posted on 11/21/2002 9:09:34 AM PST by discostu
[ Post Reply | Private Reply | To 4 | View Replies]

To: toupsie
Ooh already fixed in the latest MDAC and OS, yeah that's a scary bug.
12 posted on 11/21/2002 9:11:19 AM PST by discostu
[ Post Reply | Private Reply | To 1 | View Replies]

To: BSunday
How do I stop the Windows Update program from automatically running ?

Go to Internet Explorer and select Tools>>Internet Options>>Advanced>>Browsing, Then uncheck the option "Automatically Check for Internet Explorer Updates". I believe that might do it.

13 posted on 11/21/2002 9:18:50 AM PST by Orbiting_Rosie's_Head
[ Post Reply | Private Reply | To 4 | View Replies]

To: Badger1
But since the MAC OS has such a small market share, not as many people are out there trying to find them.

Compare exploits against IIS vs Apache. Apache has a substantially larger market share, so by this reasoning it should have more vulnerabilities, but IIS has far more. No software is perfectly secure, but not all software is equally insecure. Microsoft's philosophy has traditionally put features ahead of security. They claim to be changing, but we'll have to see.

14 posted on 11/21/2002 9:35:59 AM PST by ThinkDifferent
[ Post Reply | Private Reply | To 7 | View Replies]

To: ThinkDifferent
Compare exploits against IIS vs Apache. Apache has a substantially larger market share, so by this reasoning it should have more vulnerabilities, but IIS has far more.

This is a straw man. I was not implying that a software’s market share correlated to the number of bugs in it, just to the number of people trying to find bugs in it. I’m sure there are operating systems with fewer bugs than Windows (and some with more), but there is no operating system with a larger market share than Windows.
15 posted on 11/21/2002 9:45:19 AM PST by Badger1
[ Post Reply | Private Reply | To 14 | View Replies]

To: Steven W.
If this kind of thing really scares you I suggest you shut down your computer immediately, put on your tin foil hat and remove proceed directly to your bank, remove all your money and stow it underneath your mattress, and then take cover there as well. seriously.

This "kind of thing" doesn't scare me, I use a Mac. I wouldn't call this a garden variety bug. When M$ tells you, you can't trust them and their updates, that's not a good thing. And no, I am not anti-M$, I am just not "Pro Windows". I use M$ software all the time on my Mac and runs well and fairly secure. Its sad M$ can do it on a Mac but can't on their own OS.

16 posted on 11/21/2002 9:48:18 AM PST by toupsie
[ Post Reply | Private Reply | To 9 | View Replies]

To: Badger1
This is a straw man. I was not implying that a software’s market share correlated to the number of bugs in it, just to the number of people trying to find bugs in it. I’m sure there are operating systems with fewer bugs than Windows (and some with more), but there is no operating system with a larger market share than Windows.

Then your statement has proved ThinkDifferent correct. Apache has a larger marketshare than IIS therefore, by your logic, more hackers should be going after Apache and finding more bugs in Apache than IIS. However, more "bugs" have been found in IIS.

Marketshare does not equate to insecurity, design does. Microsoft has admitted to as much in the past.

17 posted on 11/21/2002 9:50:59 AM PST by toupsie
[ Post Reply | Private Reply | To 15 | View Replies]

To: toupsie
What steps could I follow to prevent the control from being silently re-introduced onto my system?

The simplest way is to make sure you have no trusted publishers, including especially Microsoft.

100% pure Grade A irony, on so many levels...

18 posted on 11/21/2002 10:00:09 AM PST by InfraRed
[ Post Reply | Private Reply | To 1 | View Replies]

To: toupsie
Then your statement has proved ThinkDifferent correct. Apache has a larger marketshare than IIS therefore, by your logic, more hackers should be going after Apache and finding more bugs in Apache than IIS. However, more "bugs" have been found in IIS.

Having never used either Apache or IIS, I don't know what the market share of either of them is. Perhaps Apache is a better-written OS and has fewer bugs than IIS, regardless of how many people are trying to find them. My point is that a large number of bugs are found in Windows because it has the largest market share of any OS in the world. If Windows had a small a market share as either Apache or IIS, I'm sure fewer bugs would be found in it.
19 posted on 11/21/2002 10:09:45 AM PST by Badger1
[ Post Reply | Private Reply | To 17 | View Replies]

To: toupsie
I am not anti-M$

That's got to be the most hilarious thing I've heard today. Thank you.
20 posted on 11/21/2002 10:23:20 AM PST by billybudd
[ Post Reply | Private Reply | To 16 | View Replies]


Navigation: use the links below to view more comments.
first 1-2021-23 next last

Disclaimer: Opinions posted on Free Republic are those of the individual posters and do not necessarily represent the opinion of Free Republic or its management. All materials posted herein are protected by copyright law and the exemption for fair use of copyrighted works.

Free Republic
Browse · Search
News/Activism
Topics · Post Article

FreeRepublic, LLC, PO BOX 9771, FRESNO, CA 93794
FreeRepublic.com is powered by software copyright 2000-2008 John Robinson