It also applies to Internet Explorer! Read the alert again! http://www.microsoft.com/security/security_bulletins/ms02-065.asp -----Original Message----- From: Mason Dively [mailto:mdively@xxxxxxxxxx] Sent: Friday, 22 November 2002 3:25 AM To: 'thin@xxxxxxxxxxxxx' Subject: [THIN] Re: SECURITY ALERT: MDAC PATCH! Unfortunately, they don't really say how you can verify whether or not is enabled--you just have to take their word for it. :) They do tell you how to disable it--just not how to check it. Thanks, Mason B. Dively MCP,CCA Amdocs CMI Production Windows Support -----Original Message----- From: Matt Fowler [mailto:mfowler@xxxxxxxxxxxxxxx] Sent: Thursday, November 21, 2002 11:14 AM To: thin@xxxxxxxxxxxxx Subject: [THIN] Re: SECURITY ALERT: MDAC PATCH! I agree. However, how do you find out if you have RDS enabled or not? >I read a little bit more about this vulnerability and it appears that >it >is only an issue on IIS servers where RDS is enabled. Microsoft says that >on a clean Win2K installation RDS is disabled by default--i.e. this will >only affect IIS servers that have been upgraded to Win2K. That makes me >feel a little bit better about rushing to install this puppy. > >Thanks, > >Mason B. Dively MCP,CCA >Amdocs CMI Production Windows Support > > >-----Original Message----- >From: Greg Reese [mailto:GReese@xxxxxxxxxxxxxxxx] >Sent: Thursday, November 21, 2002 11:02 AM >To: thin@xxxxxxxxxxxxx >Subject: [THIN] Re: SECURITY ALERT: MDAC PATCH! > > >I installed it on all my servers last night and have had no issues yet. >= I am running nFuse 1.6 on W2k SP2 all around and MF XPa SP2/FR2. > >Greg > >-----Original Message----- >From: Mason Dively [mailto:mdively@xxxxxxxxxx] >Sent: Thursday, November 21, 2002 11:50 AM >To: 'thin@xxxxxxxxxxxxx'; windows2000@xxxxxxxxxxxxx >Subject: [THIN] Re: SECURITY ALERT: MDAC PATCH! > > >Here's the next question: has anyone installed this patch on their = >Nfuse web server and has it broken anything? Trying to err on the side >= of caution.... > >Thanks, >=20 >Mason B. Dively MCP,CCA >Amdocs CMI Production Windows Support > > >-----Original Message----- >From: Jim Kenzig http://thethin.net [mailto:jimkenz@xxxxxxxxxxxxxx]=20 >Sent: Wednesday, November 20, 2002 7:29 PM >To: windows2000@xxxxxxxxxxxxx; thin@xxxxxxxxxxxxx >Subject: [THIN] SECURITY ALERT: MDAC PATCH! > > >Get it now gang! >http://download.microsoft.com/download/dasdk/Patch/Q329414/W98NT42KMe/E >N-= >US/ >q329414_mdacall_x86.exe > >(link may wrap) >Regards, >JK >http://thethin.net > >Microsoft Security Bulletin MS02-065 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(r) Windows(r), >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: > >Microsoft Data Access Components (MDAC) 2.1 >Microsoft Data Access Components (MDAC) 2.5 >Microsoft Data Access Components (MDAC) 2.6 >Microsoft Internet Explorer 5.01 >Microsoft Internet Explorer 5.5 >Microsoft Internet Explorer 6.0 >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: > > >It is included by default as part of Windows XP, Windows 2000, and = >Windows Millennium. >It is available for download as a stand-alone technology in its own = >right >It is either included in or installed by a number of other products and >technologies. For instance, MDAC is included in the Windows NT(r) 4.0 = >Option >Pack, and some MDAC components are present as part of Internet Explorer = >even >if MDAC itself is not installed. >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: > >Web servers are at risk if a vulnerable version of MDAC is installed >and running on the server. To exploit the vulnerability against such a >web server, an attacker would need to establish a connection with the >server = and then send a specially malformed HTTP request to it, that >would have the effect of overrunning the buffer with the attacker's >chosen data. The = code >would run in the security context of the IIS service (which, by default, >runs in the LocalSystem context) >Web clients are at risk in almost every case, as the RDS Data Stub is >included with all current versions of Internet Explorer and there is no >option to disable it. To exploit the vulnerability against a client, an >attacker would need to host a web page that, when opened, would send an = >HTTP >reply to the user's system and overrun the buffer with the attacker's = >chosen >data. The web page could be hosted on a web site or sent directly to = >users >as an HTML Mail. The code would run in the security context of the user. >Clearly, this vulnerability is very serious, and Microsoft recommends = >that >all customers whose systems could be affected by them take appropriate >action immediately. > > >Customers using Windows XP, or who have installed MDAC 2.7 on their = >systems are at no risk and do not need to take any action. >Web server administrators who are running an affected version of MDAC = >should >either install the patch, disable MDAC and/or RDS, or upgrade to MDAC = >2.7, >which is not affected by the vulnerability. >Web client users who are running an affected version of MDAC should = >install >the patch immediately on any system that is used for web browsing. It is >important to stress that the latter guidance applies to any system used = >for >web browsing, regardless of any other protective measures that have = >already >been taken. For instance, a web server on which RDS had been disabled = >would >still need the patch if it was occasionally used as a web client. >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 servers that are using MDAC version 2.7 (the version that shipped = >with Windows XP) or later are not at risk from the vulnerability. >Even if a vulnerable version of MDAC were installed, a web server would = >only >be at risk if RDS were enabled. RDS is disabled by default on clean >installations of Windows XP and Windows 2000, and can be disabled on = >other >systems by following the guidance in the IIS Security Checklist. In >addition, the IIS Lockdown Tool will automatically disable RDS when used = >in >its default configuration. >If the URLScan tool were deployed with its default ruleset (which allows >only ASCII data to be present in an HTTP request), it is likely that the >vulnerability could only be used for denial of service attacks. >IIS can be configured to run with fewer than administrative privileges. = >If >this has been done, it would likewise limit the privileges that an = >attacker >could gain through the vulnerability. >IP address restrictions, if applied to the RDS virtual directory, could >enable the administrator to restrict access to only trusted users. This = >is, >however, not practical for most web server scenarios. >Web clients > >Web clients that are using MDAC version 2.7 (the version that shipped = >with Windows XP) or later are not at risk from the vulnerability. >The HTML mail-based attack vector could not be exploited automatically = >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. >Exploiting the vulnerability would convey to the attacker only the = >user's >privileges on the system. Users whose accounts are configured to have = >few >privileges on the system would be at less risk than ones who operate = >with >administrative privileges. >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: > >In Internet Explorer, choose Tools, then Internet Options. Select the >Content tab. In the Certificates section of the page, click = on >Publishers. >In the Certificates dialog, click on the Trusted Publishers tab. >For each certificate in the list, click on the certificate and then = >select >Remove. Confirm that you want to remove the entry. >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: > >Web servers have a range of actions they can take to protect their = >systems, from installing the patch to disabling the affected function. >Even in = cases >where a server is vulnerable, tools such as URLScan would likely limit = >the >use of the vulnerability to denial of service attacks only. >Web clients - including Web servers that are sometimes used for Web >browsing - have fewer options. Web clients running anything but Windows = >XP >can only be made secure by applying the patch. > >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: > > >It installs as part of Windows XP, Windows Me, Windows 2000. (It's >worth noting, though, that the version installed by Windows XP does not >have = this >vulnerability) >It's available for download from the Microsoft web site. >It's installed by many other Microsoft applications. To name just a few >cases, it's installed as part of the Windows NT 4.0 Option Pack and by >= both Microsoft Access and SQL Server. >Some of the components in MDAC are included in other Microsoft = >technologies. >For instance, Internet Explorer includes some MDAC functions. As we'll >discuss later, this turns out to be an important factor in this case. > >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: > > >Web servers. Many web servers have vulnerable versions of RDS running >on them. If an attacker successfully exploited the vulnerability >against = such a server, he or she could either destabilize it or, in >the worst case, = gain >complete control over it. The attacker could then deface web pages, = >attack >users who subsequently visited the site, or simply reformat the hard = >drive. >Web clients. By a web client, we mean any system that's used to process = >web >pages; typical examples include home computers, laptops or workstations = >that >are used to browse the Web or handle email. The RDS Data Stub is present = >on >these systems as part of Internet Explorer. If an attacker successfully >exploited the vulnerability against such a system, he or she could = >either >cause Internet Explorer fail (which would have no lasting effects) or, = >in >the worst case, gain the user's privileges on it. The attacker could = >then >take any action on the system that the user could take. > >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. > > >Web server. Any user who could establish a web session with an affected >server could exploit the vulnerability, by sending it an appropriate = >HTTP request. > >Web client. A user could exploit the vulnerability against a web client >= if he or she were able to construct a web page that would send an = >appropriate >HTTP command, and then convince a user to open it. Typically, this would = >be >done by either hosting the page on a web site that the attacker = >controlled >or sending it directly to users as an HTML mail. > >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: > > >A vulnerable version of MDAC must be installed on the server. The most >recent version of MDAC, version 2.7 (which ships as part of Windows >XP), does not contain this vulnerability. However, most previous >versions are vulnerable. RDS must be running in Internet Information >Services (IIS). In IIS 5.0 = and >5.1, RDS is disabled by default (unless the system was upgraded from a >previous version of Windows). Even in cases where RDS does run by = >default, >it can be disabled as discussed in the IIS Security Checklist. The IIS >Lockdown Tool will also automatically disable RDS when used in its = >default >configuration. >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 >The following patch can be installed on all affected platforms: >http://www.microsoft.com/downloads/Release.asp?ReleaseID=3D44733 > > Additional information about this patch >Installation platforms: >The patch can be installed on the following systems: >Windows 98 Gold. >Windows 98SE Gold >Windows Me Gold >Windows NT4 Service Pack 6a >Windows 2000 Service Pack 2 or Service Pack 3 >Inclusion in future service packs: > > >The fix for this issue will be included in the next service pack for = >MDAC 2.5. There will be no more service packs for MDAC 2.1 and MDAC >2.6. The fix will also be included in Internet Explorer 5.01 Service >Pack 4 = and >Internet Explorer 6.0 Service Pack 2. >Reboot needed: > >Web servers: We recommend rebooting the server after installing the = >patch. Web client: It is not necessary to reboot after installing the >patch. Patch can be uninstalled: No. > >Superseded patches: None. > >Verifying patch installation: > >Microsoft Knowledge Base article Q329414 provides a file manifest that >= can be used to verify the patch installation. >Caveats: > > >As discussed in the FAQ, the patch does not set the Kill Bit on the = >affected ActiveX control. >If, after applying the patch, an MDAC service pack that predates the = >patch >is installed, the effect is to remove the patch. Moreover, because the = >patch >files would still be on the system, Windows Update would not be able to >detect that the patch files were not in use, and would not offer to >reinstall the patch. Instead, the user would need to reinstall the patch >manually after installing the service pack. >An example would be a users who have already patched their MDAC 2.5 >machines. Then if they apply MDAC 2.5 Service Pack 2 over the already >patched MDAC 2.5 machines, it's possible that there would be a = >regression, >making it necessary for the users to reinstall this patch. > >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: > >Security patches are available from the Microsoft Download Center, and >= can be most easily found by doing a keyword search for >"security_patch". Patches for consumer platforms are available from the >WindowsUpdate web = site >Other information: >Acknowledgments >Microsoft thanks Foundstone Research Labs for reporting this issue to = >us >and working with us to protect customers. > >Support: > >Microsoft Knowledge Base article Q329414 discusses this issue. >Knowledge Base articles can be found on the Microsoft Online Support >web site. Technical support is available from Microsoft Product Support >Services. There is no charge for support calls associated with security >patches. 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: > > >V1.0 (November 20, 2002): Bulletin Created. > >***********************************************=20 >This Weeks Sponsor: Wyse Technologies >Get a free whitepaper on how to secure >your corporate data from Wyse. Click Below.=20 >http://thethin.net/wyse.cfm=20 >***********************************************=20 >For Archives, to Unsubscribe, Subscribe or=20 >set Digest or Vacation mode use the below link. > >http://thethin.net/citrixlist.cfm > >-- No attachments (even text) are allowed -- >-- Type: text/plain > > >***********************************************=20 >This Weeks Sponsor: Wyse Technologies >Get a free whitepaper on how to secure >your corporate data from Wyse. Click Below.=20 >http://thethin.net/wyse.cfm=20 >***********************************************=20 >For Archives, to Unsubscribe, Subscribe or=20 >set Digest or Vacation mode use the below link. > >http://thethin.net/citrixlist.cfm >*********************************************** >This Weeks Sponsor: Wyse Technologies >Get a free whitepaper on how to secure >your corporate data from Wyse. Click Below. http://thethin.net/wyse.cfm >*********************************************** >For Archives, to Unsubscribe, Subscribe or >set Digest or Vacation mode use the below link. > >http://thethin.net/citrixlist.cfm > >-- No attachments (even text) are allowed -- >-- Type: text/plain > > >*********************************************** >This Weeks Sponsor: Wyse Technologies >Get a free whitepaper on how to secure >your corporate data from Wyse. Click Below. http://thethin.net/wyse.cfm >*********************************************** >For Archives, to Unsubscribe, Subscribe or >set Digest or Vacation mode use the below link. > >http://thethin.net/citrixlist.cfm Matt Fowler LAN Specialist (847)925-6113 mfowler@xxxxxxxxxxxxxxx *********************************************** This Weeks Sponsor: Wyse Technologies Get a free whitepaper on how to secure your corporate data from Wyse. Click Below. http://thethin.net/wyse.cfm *********************************************** For Archives, to Unsubscribe, Subscribe or set Digest or Vacation mode use the below link. http://thethin.net/citrixlist.cfm -- No attachments (even text) are allowed -- -- Type: text/plain *********************************************** This Weeks Sponsor: Wyse Technologies Get a free whitepaper on how to secure your corporate data from Wyse. Click Below. http://thethin.net/wyse.cfm *********************************************** For Archives, to Unsubscribe, Subscribe or set Digest or Vacation mode use the below link. http://thethin.net/citrixlist.cfm *********************************************** This Weeks Sponsor: Wyse Technologies Get a free whitepaper on how to secure your corporate data from Wyse. Click Below. http://thethin.net/wyse.cfm *********************************************** For Archives, to Unsubscribe, Subscribe or set Digest or Vacation mode use the below link. http://thethin.net/citrixlist.cfm