[THIN] Re: SECURITY ALERT: MDAC PATCH!
- From: Michael Earley <Michael.Earley@xxxxxxxxxxxxxx>
- To: "'thin@xxxxxxxxxxxxx'" <thin@xxxxxxxxxxxxx>
- Date: Fri, 22 Nov 2002 09:23:03 +1000
Unfortunately I am both. Hey let's have a quick survey - I'll send a new
email in a sec.
-----Original Message-----
From: Mason Dively [mailto:mdively@xxxxxxxxxx]
Sent: Friday, 22 November 2002 8:53 AM
To: 'thin@xxxxxxxxxxxxx'
Subject: [THIN] Re: SECURITY ALERT: MDAC PATCH!
Ya I noticed--however my concern is my web servers--I will leave it up to
our desktop guys to protect their stuff! :)
Thanks,
Mason B. Dively MCP,CCA
Amdocs CMI Production Windows Support
-----Original Message-----
From: Michael Earley [mailto:Michael.Earley@xxxxxxxxxxxxxx]
Sent: Thursday, November 21, 2002 4:49 PM
To: 'thin@xxxxxxxxxxxxx'
Subject: [THIN] Re: SECURITY ALERT: MDAC PATCH!
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
-- 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
Other related posts:
