The following is a Security Bulletin from the Microsoft Product Security
Notification Service.
Please do not reply to this message, as it was sent from an unattended
mailbox.
********************************
-----BEGIN PGP SIGNED MESSAGE-----
- ----------------------------------------------------------------------
Title: Outlook, Outlook Express Vcard Handler Contains
Unchecked Buffer
Date: 22 February 2001
Software: Outlook, Outlook Express
Impact: Run code of attacker's choice
Bulletin: MS01-012
Microsoft encourages customers to review the Security Bulletin at: http://www.microsoft.com/technet/security/bulletin/MS01-012.asp.
- ----------------------------------------------------------------------
Issue:
======
Outlook Express provides several components that are used both by it
and Outlook, if Outlook is installed on the machine. One such
component, used to process vCards, contains an unchecked buffer.
By creating a vCard and editing it to contain specially chosen data,
then sending it to another user, an attacker could cause either of
two effects to occur if the recipient opened it. In the less serious
case, the attacker could cause the mail client to fail. If this
happened, the recipient could resume normal operation by restarting
the mail client and deleting the offending mail. In the more serious
case, the attacker could cause the mail client to run code of her
choice on the user's machine. Such code could take any desired
action, limited only by the permissions of the recipient on the
machine.
Because the component that contains the flaw ships as part of OE,
which itself ships as part of IE, the patch is specified in terms of
the version of IE rather than OE or Outlook.
Mitigating Factors:
====================
- There is no means by which a Vcard could be made to open
automatically.
Patch Availability:
===================
- A patch is available to fix this vulnerability. Please read the
Security Bulletin
http://www.microsoft.com/technet/security/bulletin/ms01-012.asp
for information on obtaining this patch.
The following is a Security Bulletin from the Microsoft Product Security
Notification Service.
Please do not reply to this message, as it was sent from an unattended
mailbox.
********************************
-----BEGIN PGP SIGNED MESSAGE-----
- ----------------------------------------------------------------------
Title: Windows 2000 Event Viewer Contains Unchecked Buffer
Date: February 26, 2001
Software: Windows 2000
Impact: Run code of attacker's choice
Bulletin: MS01-013
Microsoft encourages customers to review the Security Bulletin at: http://www.microsoft.com/technet/security/bulletin/MS01-013.asp.
- ----------------------------------------------------------------------
Issue:
======
The Windows 2000 event viewer snap-in has an unchecked buffer in a
section of the code that displays the detailed view of event records.
If the event viewer attempted to display an event record that
contained specially malformed data in one of the fields, either of
two outcomes would result. In the less serious case, the event viewer
would fail. In the more serious case, code of the attacker's choice
could be made to run via a buffer overrun.
By design, unprivileged processes can log events in the System and
Application logs, and interactively logged-on, unprivileged users can
view them. However, only privileged processes can log events in the
Security log, and only interactively logged-on administrators can
view them. If the vulnerability were exploited to run code of the
attacker's choice, the code would run in the security context of the
user who viewed the affected record.
Mitigating Factors:
====================
- Simply perusing the listing of events in a log would not allow
the vulnerability to be exploited. It could only be exploited
if the user opened an affected record to view the event details.
- Although the Event Viewer is generally thought of as an
administrative tool, there is no guarantee that the user who opens
a particular event record would be privileged. Unprivileged users
can read the System and Application logs. Although the Security
log can only be read by privileged users, only privileged
processes can write to it.
- To the best of our knowledge, it is not possible to manipulate
the normal auditing functions of any Windows 2000 service in order
to create an event record that would exploit this vulnerability.
Instead, a custom piece of code would need to be created and run
to create such a record.
- If firewalling and other appropriate precautions have been taken,
only authenticated users will have access to network machines and
be able to write event log records.
Patch Availability:
===================
- A patch is available to fix this vulnerability. Please read the
Security Bulletin
http://www.microsoft.com/technet/security/bulletin/ms01-013.asp
for information on obtaining this patch.
Acknowledgment:
===============
- Blake Watts of Guardent ( http://www.guardent.com )
socalgal
03-01-2001, 08:48 PM
The following is a Security Bulletin from the Microsoft Product Security
Notification Service.
Please do not reply to this message, as it was sent from an unattended
mailbox.
********************************
-----BEGIN PGP SIGNED MESSAGE-----
- ----------------------------------------------------------------------
Title: Malformed URL can cause Service Failure in IIS 5.0 and
Exchange 2000
Date: 01 March 2001
Software: IIS 5.0 and Exchange 2000
Impact: Denial of Service
Bulletin: MS01-014
Microsoft encourages customers to review the Security Bulletin at: http://www.microsoft.com/technet/security/bulletin/MS01-014.asp.
- ----------------------------------------------------------------------
Issue:
======
IIS 5.0 contains a flaw affecting the way that an URL is handled if
it has a specific construction and its length is within a very narrow
range of values. If such an URL were repeatedly sent to an affected
system, a confluence of events could cause a memory allocation error
that would result in the failure of the IIS service.
Exchange 2000 is affected by the same vulnerability. To support
web-based mail clients, it introduces the ability to address items on
the store via URLs. This is done in part by using IIS 5.0, and in
part via code that is specific to Exchange 2000. Both pieces of code
contain the flaw, but the effect of exploiting the vulnerability via
either would be the same -- it could be used to cause the IIS service
to fail, but could not be used to attack the Exchange service itself.
That is, successfully attacking an Exchange server via this
vulnerability would disrupt web-based mail clients' use of the
server, but not that of MAPI-based mail clients like Outlook.
Because the flaw occurs in two different code modules, one of which
installs as part of IIS 5.0 and both of which install as part of
Exchange 2000, it is important for Exchange 2000 administrators to
install both the IIS and Exchange patches.
Mitigating Factors:
====================
- The vulnerability would not enable the attacker to gain any
administrative control over the server, or to alter any data
on it.
- The affected services automatically restart in the event of
a failure, so an affected system would resume service almost
immediately.
- A successful attack against an Exchange server would only
disrupt web-based mail clients' use of the server. The server
would continue to be available for MAPI-based clients like
Outlook.
- The ISAPI involved in this vulnerability authenticates the
user prior to servicing the request, so a properly configured
Exchange server would be at less risk than an IIS server.
Patch Availability:
===================
- A patch is available to fix this vulnerability. Please read the
Security Bulletin
http://www.microsoft.com/technet/security/bulletin/ms01-014.asp
for information on obtaining this patch.
Acknowledgment:
===============
- Kevin Kotas of eSecurityOnline.com ( http://eSecurityOnline.com )
socalgal
03-06-2001, 10:14 PM
The following is a Security Bulletin from the Microsoft Product Security
Notification Service.
Please do not reply to this message, as it was sent from an unattended
mailbox.
********************************
-----BEGIN PGP SIGNED MESSAGE-----
- ----------------------------------------------------------------------
Title: IE can Divulge Location of Cached Content
Date: 06 March 2001
Software: IE and Windows Scripting Host
Impact: Run code of attacker's choice. Three other
vulnerabilities, of lesser severity and exploitable in
more restricted circumstances, also are eliminated by
the patches.
Bulletin: MS01-015
Microsoft encourages customers to review the Security Bulletin at: http://www.microsoft.com/technet/security/bulletin/MS01-015.asp.
- ----------------------------------------------------------------------
Issue:
======
The IE security architecture provides a caching mechanism that is
used to store content that needs to be downloaded and processed on
the user's local machine. The purpose of the cache is to obfuscate
the physical location of the cached content, in order to ensure that
the web page or HTML e-mail will work through the IE security
architecture to access the information. This ensures that the uses
of the information can be properly restricted.
A vulnerability exists because it is possible for a web page or HTML
e-mail to learn the physical location of cached content. Armed with
this information, an attacker could cause the cached content to be
opened in the Local Computer Zone. This would enable him to launch
compiled HTML help (.CHM) files that contain shortcuts to
executables, thereby enabling him to run the executables.
In addition to eliminating this vulnerability, the patches provided
below eliminate three other vulnerabilities that either pose
significantly less risk or could only be exploited in very
restricted situations:
- A variant of the "Frame Domain Verification" vulnerability
discussed in Microsoft Security Bulletins MS00-033, MS00-055,
and MS00-093. The vulnerability could enable a malicious web
site operator to open two browser windows, one in the web
site's domain and the other on the user's local file system,
and to pass information from the latter to the former. This
could enable the web site operator to read, but not change,
any file on the user's local computer that could be opened
in a browser window.
- A vulnerability that is identical in effect to the "Frame
Domain Verification" vulnerability, but which actually results
from a flaw in Windows Scripting Host rather than IE. Because
it could only be exploited via IE, we have provided the patch
here.
- A vulnerability that affects how Telnet sessions are invoked
via IE. By design, telnet sessions can be launched via IE.
However, a vulnerability exists because when doing so, IE will
start Telnet using any command-line options the web site
specifies. This only becomes a concern when using the version
of the Telnet client that installs as part of Services for
Unix (SFU) 2.0 on Windows NT(r) 4.0 or Windows(r) 2000
machines. The version of the Telnet client in SFU 2.0 provides
an option for creating a verbatim transcript of a Telnet
session. An attacker could start a session using the logging
option, then stream an executable file onto the user's system
in a location that would cause it to be executed automatically
the next time the user booted the machine. The flaw does not
lie in the Telnet client, but in IE, which should not allow
Telnet to be started remotely with command-line arguments.
Mitigating Factors:
====================
- None of the vulnerabilities could be exploited without some
user action - either browsing to the attacker's site or opening
a mail from him. Customers who exercise safe browsing habits
would be less likely visit untrustworthy sites, and customers
who have used the Security Zones feature to restrict what HTML
mail can do would be less likely to be affected by this
vulnerability.
- The variants of the "frame domain verification" vulnerability
discussed above could only be used to view files, and only file
types that can be opened in a browser window.
- The vulnerability affecting Telnet invocation is only a concern
for customers who are using the Telnet client that ships as
part of Services for Unix 2.0. Other versions of Telnet do not
include the command-line feature to create log files.
Patch Availability:
===================
- A patch is available to fix this vulnerability. Please read the
Security Bulletin
http://www.microsoft.com/technet/security/bulletin/ms01-015.asp
for information on obtaining this patch.
socalgal
03-08-2001, 08:59 PM
The following is a Security Bulletin from the Microsoft Product Security
Notification Service.
Please do not reply to this message, as it was sent from an unattended
mailbox.
********************************
-----BEGIN PGP SIGNED MESSAGE-----
- ----------------------------------------------------------------------
Title: Malformed WebDAV Request Can Cause IIS
to Exhaust CPU Resources
Date: 08 March 2001
Software: IIS 5.0
Impact: Denial of Service
Bulletin: MS01-016
Microsoft encourages customers to review the Security Bulletin at: http://www.microsoft.com/technet/security/bulletin/MS01-016.asp.
- ----------------------------------------------------------------------
Issue:
======
WebDAV is an extension to the HTTP protocol that allows remote
authoring and management of web content. In the Windows 2000
implementation of the protocol, IIS 5.0 performs initial processing
of all WebDAV requests, then forwards the appropriate commands to the
WebDAV process. However, a flaw exists in the way WebDAV handles a
particular type of malformed request. If a stream of such requests
were directed at an affected server, it would consume all CPU
availability on the server.
Because the discoverer of this vulnerability has chosen to publish
code to exploit this vulnerability before a patch could be developed,
Microsoft has developed a workaround that can be used to defend
against attack. Knowledge Base article Q241520 provides step-by-step
instructions for changing the permissions on the .DLL that provides
WebDAV services in order to effectively disable it on the machine.
When a patch is available, we will re-release this bulletin and
provide updated information.
Microsoft recommends that customers consider applying the workaround
to any servers running IIS 5.0. Although this obviously includes web
servers, other services, notably Exchange 2000, may also require that
IIS 5.0 be enabled.
Mitigating Factors:
====================
- The effect of an attack via this vulnerability would be temporary.
The
server would automatically resume normal service as soon as the
malformed
requests stopped arriving.
- The vulnerability does not provide an attacker with any capability
to
carry out WebDAV requests.
- The vulnerability does not provide any capability to compromise
data on
the server or gain administrative control over it.
Patch Availability:
===================
- A patch is currently under development and will be released
shortly. In
the meantime, Knowledge Base article Q241520
(http://www.microsoft.com/technet/support/kb.asp?ID=241520)
provides a workaround that can be used to protect against this
vulnerability.
Please read the Security Bulletin http://www.microsoft.com/technet/security/bulletin/ms01-016.asp
for more information on this vulnerability.
socalgal
03-22-2001, 07:10 PM
Microsoft Security Bulletin (MS01-017) (http://www.microsoft.com/technet/security/bulletin/MS01-017.asp)
Erroneous VeriSign-Issued Digital Certificates Pose Spoofing Hazard
Originally posted: March 22, 2001
Summary
Who should read this bulletin: All customers using Microsoft® products.
Impact of vulnerability: Attacker could digitally sign code using the name “Microsoft Corporation”.
Recommendation: All customers should follow the administrative procedures detailed in the FAQ. A software update will be issued shortly to provide permanent remediation.
Affected Software:
Microsoft Windows® 95
Microsoft Windows 98
Microsoft Windows Me
Microsoft Windows NT® 4.0
Microsoft Windows 2000
Technical details
Technical description:
VeriSign, Inc., recently advised Microsoft that on January 29 and 30, 2001, it issued two VeriSign Class 3 code-signing digital certificates to an individual who fraudulently claimed to be a Microsoft employee. The common name assigned to both certificates is “Microsoft Corporation”. The ability to sign executable content using keys that purport to belong to Microsoft would clearly be advantageous to an attacker who wished to convince users to allow the content to run.
The certificates could be used to sign programs, ActiveX controls, Office macros, and other executable content. Of these, signed ActiveX controls and Office macros would pose the greatest risk, because the attack scenarios involving them would be the most straightforward. Both ActiveX controls and Word documents can be delivered via either web pages or HTML mails. ActiveX controls can be automatically invoked via script, and Word documents can be automatically opened via script unless the user has applied the Office Document Open Confirmation Tool.
However, even though the certificates say they are owned by Microsoft, they are not bona fide Microsoft certificates, and content signed by them would not be trusted by default. Trust is defined on a certificate-by-certificate basis, rather than on the basis of the common name. As a result, a warning dialogue would be displayed before any of the signed content could be executed, even if the user had previously agreed to trust other certificates with the common name “Microsoft Corporation”. The danger, of course, is that even a security-conscious user might agree to let the content execute, and might agree to always trust the bogus certificates.
VeriSign has revoked the certificates, and they are listed in VeriSign’s current Certificate Revocation List (CRL). However, because VeriSign’s code-signing certificates do not specify a CRL Distribution Point (CDP), it is not possible for any browser’s CRL-checking mechanism to download the VeriSign CRL and use it. Microsoft is developing an update that rectifies this problem. The update package includes a CRL containing the two certificates, and an installable revocation handler that consults the CRL on the local machine, rather than attempting to use the CDP mechanism.
Versions of the update are being prepared for all Microsoft platforms released since 1995. However, because of the large number of platforms that must be tested, the patches are not available at this writing. Until the update is available, we urge customers to take some or all of the following steps to protect themselves should they encounter hostile code signed by one of the certificates.
Visually inspect the certificates cited in all warning dialogues. The two certificates at issue here were issued on 29 and 30 January 2001, respectively. No bona fide Microsoft certificates were issued on these dates. The FAQ and Knowledge Base article Q293817 provide complete details regarding both certificates.
Install the Outlook Email Security Update to prevent mail-borne programs from being launched, even via signed components, and install the Office Document Open Confirmation Tool to force web pages to request permission before opening Office documents.
Consider temporarily removing the VeriSign Commercial Software Publishers CA certificate from the Trusted Root Store. Knowledge Base article Q293819 provides details on how to do this.
Mitigating factors:
The certificates are not trusted by default. As a result, neither code nor ActiveX controls could be made to run without displaying a warning dialogue. By viewing the certificate in such dialogues, users can easily recognize the certificates.
The certificates are not the bona fide Microsoft code-signing certificates. Content signed by those keys can be distinguished from bona fide Microsoft content.
Vulnerability identifier: None. This issue is not the result of a flaw in a Microsoft product; it results because of an error made by a third party.
Tested Versions:
Microsoft tested the following products to assess whether they are affected by this vulnerability. We will waive normal support guidelines to provide remediation for all operating systems that are still in widespread use, regardless of whether they are normally supported or not.
Microsoft Windows 95
Microsoft Windows 98
Microsoft Windows Me
Microsoft Windows NT 4.0
Microsoft Windows 2000
Frequently asked questions
Is this a security vulnerability?
This issue does not meet the strict definition of a security vulnerability, because there is no flaw in any of the affected Microsoft products. The problem results solely because of an error made by a third party. However, it clearly poses a grave risk to customers, and we have issued this bulletin to provide information about the issue and the actions customers should immediately take.
What’s the scope of the problem?
VeriSign, Inc., a major certificate authority, reports that in January 2001 it erroneously issued two digital certificates identified as Microsoft certificates to an individual who fraudulently claimed to be a Microsoft employee. These certificates could be used to digitally sign programs (including ActiveX controls and Word macros) using the name “Microsoft Corporation”.
Programs signed using these certificates would not be able to run automatically or bypass any normal security restrictions. However, the warning dialogue that appears before such programs could run would claim that they had been digitally signed by Microsoft. Clearly, this would be a significant aid in persuading a user to run the program.
What is a digital certificate?
To answer that question, we first need to discuss cryptography, particularly public key cryptography. Cryptography is the science of securing information by converting it between its normal, readable state (called plaintext) and one in which the data is obscured (known as ciphertext).
In all forms of cryptography, a value known as a key is used in conjunction with a procedure called a cryptoalgorithm to transform plaintext data into ciphertext. In the most familiar type of cryptography, secret-key cryptography, the ciphertext is transformed back into plaintext using the same key. However, in a second type of cryptography, public key cryptography, a different key is used to transform the ciphertext back into plaintext.
In public key cryptography, one of the keys, known as the private key, must be kept secret. The other key, known as the public key, is intended to be shared with the world. However, there must be a way for the owner of the key to tell the world who the key belongs to. Digital certificates provide a way to do this. A digital certificate is a tamperproof piece of data that packages a public key together with information about it – who owns it, what it can be used for, when it expires, and so forth.
What can a digital certificate be used for?
A digital certificate (or more properly, a key pair, of which the public key is packaged in a digital certificate) can be used in either of two ways. If people use the public key (the one encapsulated in a digital certificate) to encrypt data, only the person who holds the corresponding private key will be able to read it; this enables the data to be kept confidential.
On the other hand, if the owner of the private key uses it to encrypt data, anyone will be able to decrypt it using the corresponding public key. This process doesn’t provide confidentiality (since anyone can access the public key and decrypt the message), but it does provide two other capabilities:
Proof of origin. If the data could be decrypted using the public key, it must have been encrypted using the corresponding private key – and the digital certificate says who owns the private key.
Authenticity. If someone modified the encrypted data while it was in transit, the recipient wouldn’t be able to decrypt it, even using the public key. The fact that the data can be successfully decrypted shows that it wasn’t tampered with.
Using public-key cryptography in this manner to prove the origin and authenticity of data is known as digital signing.
But what ensures that the private key really belongs to the person listed in the digital certificate?
Digital certificates are generated and themselves digitally signed by organizations known as certificate authorities. It’s the job of a certificate authority to verify the identity of the person requesting a digital certificate before issuing one to them.
What’s wrong with the certificates in this case?
A certificate authority, VeriSign, erroneously issued two digital certificates to a person who claimed to be a Microsoft employee. The certificates say that the owner of the certificate is Microsoft, when in fact this is not the case.
So, these aren’t bona fide Microsoft certificates?
That’s correct. None of Microsoft’s certificates have been compromised. These are new certificates that VeriSign erroneously issued, and which incorrectly say that Microsoft owns them.
If Microsoft doesn’t own these certificates, who does?
The identity of the person who purchased the certificates isn’t known at present. However, both VeriSign and Microsoft are working closely with law enforcement authorities to find the person, as it appears that several laws may have been broken during the purchase of these certificates.
What could these two certificates be used to do?
These certificates are of a type that can be used to digitally sign programs, including ActiveX controls and Office macros. Many software developers, including Microsoft, digitally sign the programs they create in order to assure customers that the programs are legitimate and have not been modified.
Could the certificates be used for any other purpose?
No. All digital certificates carry a marking that restricts what they can be used for. These particular certificates can only be used to digitally sign programs. They cannot be used to encrypt data, sign e-mails, log onto Windows 2000 systems, or do anything else besides signing programs.
How might an attacker use these certificates?
The attacker’s overall goal would very probably be to convince other users to run an unsafe program, by using the digital signature to convince them that it is actually bona fide Microsoft software and therefore safe to run. There are a variety of scenarios the attacker might use to accomplish this, but if the attacker’s goal was distribute malicious code widely, a few scenarios would likely be especially attractive.
The attacker probably would choose to use an attack scenario designed to deliver the program to a large number of users, such as hosting the signed program on a web site or sending an HTML e-mail that would retrieve it from a web site. It’s also likely that he would choose to package the program as either an ActiveX control or an Office document containing a signed macro, because doing so would allow him to initiate running the program automatically, as soon as a user either visited the web page or opened the HTML mail.
Did you say that the attacker could make the signed program run automatically?
No. There’s a fine distinction between initiating the running of a program and actually running it, and it’s worth spending a few moments discussing the difference.
From the attacker’s perspective, the problem with simply sending a signed program as an attachment to a mail, or hosting it as a file on a web site, is that he would need to persuade the user to select the program and deliberately choose to run it. This isn’t impossible to accomplish – witness the success of the I Love You virus, for instance, which did exactly this – but the attacker would want a method that minimizes the number of steps the user must take to run the program.
Web pages and HTML e-mails can automatically initiate ActiveX controls, and can automatically open Word documents (unless the user has previously installed the Office Document Open Confirmation Tool). However, in either case a warning dialogue similar to the one below would be displayed before the program actually began running. The dialogue would ask the user whether it’s OK for the program to run. The danger, of course, is that the dialogue would say that the program was digitally signed by Microsoft, and even a security-conscious user might agree to let it run.
If your browser does not support inline frames, click here to view on a separate page.
Suppose I had previously said to always trust content signed by Microsoft. Would I still see a warning dialogue?
Even if you have previously said to always trust Microsoft-signed programs, you would still see a warning dialogue at least one time. This is because trust is assigned on a per-certificate basis, not on a per-name basis. That is, you can specify that you trust a particular certificate because the name on it is Microsoft, but there isn’t any way to say that you want to trust all certificates that say Microsoft on them.
The upshot is this: even though the two bogus certificates say they are Microsoft certificates, they are not trusted by default. You are guaranteed to see the warning dialogue the first time you encounter a program signed using either of these certificates, and will continue to see it unless you select “Always trust content from Microsoft Corporation” in response to the warning dialogue.
If I see a warning dialogue regarding content signed by Microsoft, can I tell what certificate was used to sign it?
Yes. Every warning dialogue has an option to view the certificate that was used to sign the program. (In the dialogue shown above, you can do this by clicking on the signer's name -- "Microsoft Corporation" in this case). You can inspect the certificate and identify whether it’s one of the two bogus ones. A screen shot of the two bogus certificates is provided later in the FAQ.
What is Microsoft doing to help with this problem?
Although this issue doesn’t result from a flaw in any Microsoft product, we are nevertheless developing an update that will help customers ensure that content signed by the two certificates is recognized as being invalid.
Why is an update needed?
The update is needed because of a characteristic of VeriSign code-signing certificates. Every certificate issuer periodically generates a Certificate Revocation List (CRL), which lists all the certificates that should be considered invalid. A field in every certificate should indicate the CRL Distribution Point (CDP) – the location from which the CRL can be obtained. The problem is that VeriSign code-signing certificates leave the CDP information blank. As a result, even though VeriSign has added these two certificates to its current CRL, it’s not possible for systems to automatically download and check it.
Our update compensates for this omission in the VeriSign certificates and makes it possible to check the CRL by doing the following:
Installing on the local machine a CRL that contains the two certificates
Adding new functionality via a piece of software called an installable revocation handler that causes the system to check the CRL that’s on the machine, rather than trying to download it from the CDP.
Turning on CRL checking in IE.
What products will the update be made available for?
Because this issue has the potential to affect a large number of customers, Microsoft has taken the step of producing a version of the update for all operating systems produced in the past six years.
Specifically, we will release versions of the update for Windows 95, Windows 98, Windows 98 Second Edition, Windows Me, Windows NT 4.0, and Windows 2000, when used in conjunction with Internet Explorer 4.01, 5.01, and 5.5.
Why did you make this issue public before the update was available?
We chose to make the issue public immediately for two reasons:
There are steps that customers can take immediately, even without the update, to protect their systems today.
Because of the number of operating systems and browser versions for which we are producing versions of the update, testing cannot be completed immediately.
How will I know when the update is available?
We’ll re-release this bulletin as soon as the update becomes available, and provide complete details on how to get it and use it.
Is there anything I can do in the meantime?
Yes. You can do three things today to help protect your systems. All of these steps are discussed in more detail later in the FAQ.
If you see a dialogue asking whether to trust content signed by Microsoft, visually inspect the certificate and verify that it isn’t one of the bogus ones.
Ensure that you have installed the Outlook E-mail Security Update and the Office Document Open Confirmation Tool.
Consider taking steps to temporarily prevent any certificates issued by VeriSign from being trusted.
How can I visually inspect the certificates?
Remember that you will always see a warning dialogue anytime a web site or e-mail tries to run a program that’s been signed by a certificate that isn’t known to the system – even if the certificate says it’s owned by Microsoft. (Of course, if you say to trust the certificate, you won’t see the warning again). This dialogue offers an option to view the certificate by clicking on the signer's name. By inspecting the information in the certificate, you can easily tell whether it’s one of the two bogus ones.
Clearly, if the program has been signed by one of these certificates, you should not run it. Here are screen shots of the two bogus certificates:
If your browser does not support inline frames, click here to view on a separate page.
If your browser does not support inline frames, click here to view on a separate page.
The screen shot lists protecting e-mail messages as one of the intended purposes, but you said they could only be used to sign programs.
Which is correct?
The “issued by” information is the authoritative piece of data, rather than the “intended purposes” information. Because the certificate was issued by the VeriSign Commercial Software Publishers CA, it can only be used to sign programs, regardless of what other sections of the certificate may say.
Is there a way to tell whether I’ve previously chosen to trust either of the two certificates, and to undo this decision?
Yes. Information on how to do this is provided in Knowledge Base article Q293816.
How would installing the Outlook E-mail Security Update help protect my system?
The Outlook E-mail Security Update prevents HTML mails from launching ActiveX controls, even if they have been digitally signed. By installing the update, you can ensure that you’re protected against the mail-borne version of this attack. If you haven’t already installed the update, do it today.
How would installing the Office Document Open Confirmation Tool help protect my system?
The Office Document Open Confirmation Tool prevents web sites and HTML e-mails from being able to open Office documents such as Word files without your consent. This would make it more difficult to cause a digitally signed Word macro to run.
Is there anything else I can do?
It is possible to temporarily take steps to prevent any code-signing certificate issued by VeriSign from being trusted, by removing the VeriSign Commercial Software Publishers CA certificate. Knowledge Base article Q293819 has details on how to do this, and how to reverse the process again.
It’s worth noting that this is a fairly drastic step and shouldn’t be entered into lightly. Doing this would mean that you would see a warning dialogue anytime code is downloaded that was signed using a certificate issued by VeriSign, and there are a great many of those.
I received an e-mail that claimed to be from Microsoft and contained a program as an attachment. Could it be bona fide?
No. Microsoft has a strict policy against ever sending programs, security patches or any other type of executable content via e-mail. We distribute our software via our web site or on physical media like CD ROMs. If you receive such a mail, do not run the attachment.
Patch availability:
Download locations for this patch.
A software update is under development and will be released shortly. When it is available, we will update this bulletin to provide information on how to obtain and use it.
Additional information about this patch
Installation platforms:
The administrative procedures discussed above can be performed on any of the Microsoft operating systems listed in Affected Products.
Inclusion in future service packs:
When a software update is available, we will update the bulletin to provide service pack information.
Verifying patch installation:
When the software update is available, we will update the bulletin to provide information on how verify the installation
Caveats:
Customers who choose to remove the VeriSign Commercial Software Publishers CA should be aware that this will cause all VeriSign-issued code-signing certificates to be untrusted, and could cause a significantly higher number of warning dialogues.
Localization:
The administrative procedures can be taken on any language version of the affected operating systems.
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
All patches available via WindowsUpdate also are available in a redistributable form from the WindowsUpdate Corporate site.
Other information:
Support:
Microsoft Knowledge Base article Q293818 discusses this issue and will be available approximately 24 hours after the release of this bulletin. 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.
Proceed to Microsoft Security Bulletin (MS01-017) (http://www.microsoft.com/technet/security/bulletin/MS01-017.asp) page for screenshots and active links. -Socalgal
socalgal
03-30-2001, 09:36 PM
Microsoft Security Bulletin (MS01-018) (http://www.microsoft.com/technet/security/bulletin/MS01-018.asp)
Visual Studio VB T-SQL Object Contains Unchecked Buffer
Originally posted: March 27, 2001
Summary
Who should read this bulletin: Customers running either Visual Studio 6.0 Enterprise or Visual Basic 6.0 Enterprise Edition
Impact of vulnerability: Run code of attacker’s choice.
Recommendation: Customers running either Visual Studio 6.0 Enterprise or Visual Basic 6.0 Enterprise Edition should install this patch.
Affected Software:
Microsoft Visual Studio 6.0 Enterprise Edition
Microsoft Visual Basic 6.0 Enterprise Edition
Technical details
Technical description:
The VB T-SQL debugger object that ships with Visual Studio 6.0 or Visual Basic 6.0 Enterprise Edition has an unchecked buffer in the code that processes parameters for one of the object’s methods. The object can, by design, be programmatically accessed remotely. If the object were to be referenced by a program that contained specially malformed data within the parameter, either of two outcomes would result. In the less serious case, the attacker could cause the object to fail on the hosting machine. In the more serious case, the attacker could exploit the buffer overrun to run code of the attacker's choice on the hosting machine.
The debugger object (vbsdicli.exe) is installed by default with Visual Studio 6.0 or Visual Basic 6.0 Enterprise Edition and runs in the context of the interactively logged-on user. The attacker could only execute a successful attack if he knew that a user had the component installed and that the user was logged in at the time of the attack.
Mitigating factors:
If best practices have been followed and ports 137-139 and 445 have been blocked at an organization’s router or firewall, this attack could not be executed from the Internet.
There is no way to determine remotely if a machine has the affected component installed. An attacker would need to successively target machines until he found one that was susceptible.
The vulnerability could only be exploited if an interactive user were logged on to the target machine at the time of the malicious user’s attack.
Only the Enterprise Edition of Visual Studio 6.0 or Visual Basic 6.0 are affected. Visual Studio 6.0 or Visual Basic 6.0 Professional Edition is not affected.
Vulnerability identifier: CAN-2001-0153
Tested Version:
Microsoft tested Visual Studio 6.0 and Visual Basic 6.0 Enterprise Edition. Previous versions are no longer supported, and may or may not be affected by these vulnerabilities.
Frequently asked questions
What’s the scope of the vulnerability?
This is a buffer overrun vulnerability in an object that ships with Visual Studio 6.0 or Visual Basic 6.0 Enterprise Edition. If an attacker exploited this vulnerability in an attack against an affected computer, he could potentially run arbitrary code on that machine in the context of the interactively logged on user. There are potentially two effects of an attack via this vulnerability. The malicious user could cause the affected object to fail or he could potentially run arbitrary code on the target computer in the context of the interactively logged on user.
What causes the vulnerability?
A DCOM object (VB T-SQL Debugger - vbsdicli.exe) that ships with Visual Studio 6.0 Enterprise has an unchecked buffer in a section of code that processes the parameters for one of the object’s methods.
What is DCOM?
A technology for component-based development of software that is network-aware. Using Distributed Component Object Model (DCOM), developers can create network-aware applications using Component Object Model (COM) components. DCOM works under various network transports, including TCP/IP.
DCOM is a client/server protocol that provides distributed network services to COM, allowing DCOM-enabled software components to communicate over a network in a similar fashion to the method by which COM components communicate among themselves on a single machine. DCOM client objects make requests for services from DCOM server objects on different machines on the network using a standard set of interfaces.
For more information on DCOM please see the following link: http://www.microsoft.com/com/tech/dcom.asp
What is COM?
The Component Object Model (COM) is an object-based software architecture that allows applications to be built from binary software components. COM is the foundation for various Microsoft technologies including OLE, ActiveX, Distributed COM (DCOM), COM+, and Microsoft Transaction Server (MTS).
COM is not a programming language, rather it is a specification. The goal of COM is to allow applications to be built using components. These COM components can be created by different vendors, at different times, and using different programming languages. Also, the COM components can run on different machines or different operating systems.
For more information please see the following link: http://www.microsoft.com/com/tech/com.asp.
What’s the VB T-SQL object?
The T-SQL debugger is a DCOM object (which can be remotely initiated) integrated with the Data Environment designer. It allows you to interactively debug remote stored procedures written in Microsoft SQL Server's Transact SQL dialect, from within the Visual Basic development environment.
The vulnerability described in this bulletin is independent of any access to SQL server and only requires access to a machine with the debugger object installed.
For more information please see the following link: http://msdn.microsoft.com/library/devprods/vs6/vbasic/vbcon98/vbconthetsqldebugger.htm
What’s wrong with the VB T-SQL object?
The object contains an unchecked buffer in the code that processes the parameters for one of the object’s methods. A remote program could invoke this method so as to cause a buffer overrun.
As is often the case with buffer overrun vulnerabilities, either of two outcomes could occur. In the less serious case – in which the buffer was overrun by random data – the object would just produce an error or fail on the target computer. In the more serious case – in which the attacker filled the affected parameter in the object with specially selected data – the functionality of the object could be modified while it was running, in order to make it take something other than its intended action.
What would the first case enable an attacker to do?
If the parameter at issue here were filled with random data, the debugger object would fail. However, the user on the target machine could bypass the error and continue working normally.
What would the second case enable an attacker to do?
If an attacker were able to insert an invalid parameter containing specially chosen data, he could cause his program to take any action he wanted on the target computer when it referenced the debugger object. The only limitation on the actions the program could take would be those associated with the user who was running Visual Studio 6 at the time – if the user had few privileges on the machine, the malicious code might be able to do very little. On the other hand, if the user was an administrator on the machine, the code could do virtually anything.
Who could exploit the vulnerability?
There are a few prerequisites for exploiting this vulnerability:
The malicious user would need to know the name of the target computer and would need to be on the same intranet as the target computer. If best practices were followed, and ports 137-139, and 445 were blocked at the router or firewall, the vulnerability could not be exploited from the Internet.
The malicious user would also need to know that a specific user had Visual Studio 6.0 Enterprise installed on a specific machine.
Finally, a specific user would need to be interactively logged in at the time of the attack.
What security context would the malicious program run under on the target machine?
Since the attack requires a user to be logged in the malicious code would run in the context of that logged in user. If the user on the affected computer was a local user the program would have that user’s local privileges on the machine. If the logged on user was a member of a domain then the malicious program would have domain privileges.
What if a user is not logged on at the time of the attack?
If the target computer did not have an interactive logged on user, the attacker would receive an error message if he tried to reference the object on the target machine. An interactive logged on user must be present at the time of attack.
I don't have Visual Studio 6.0 Enterprise or Visual Basic 6.0 Enterprise Edition on my machine. Could I be affected?
No. This problem only affects either Visual Studio 6.0 Enterprise or Visual Basic 6.0 Enterprise Edition.
I run Visual Studio 6.0 or Visual Basic 6.0 Professional Edition. Could I be affected?
No. The debugger only ships with Visual Studio 6.0 or Visual Basic Enterprise Edition.
What does the patch do?
The patch corrects the object to ensure that proper bounds checking takes place on the parameter in question.
Patch availability
Download locations for this patch
Microsoft Visual Studio 6.0 Enterprise or Visual Basic 6.0 Enterprise Edition: http://msdn.microsoft.com/vstudio/downloads/debugging/default.asp
Additional information about this patch
Installation platforms:
This patch can be installed on systems running either Visual Studio 6.0 Enterprise Edition Service Pack 5 or Visual Basic 6.0 Enterprise Edition.
Inclusion in future service packs:
The fix for this issue will be included in Service Pack 6 of Visual Studio 6.0 Enterprise Edition.
Verifying patch installation: To verify that the patch has been installed, verify that the files listed in the patch manifest in Knowledge Base article Q281297 have been installed on the machine.
Caveats:
None
Localization:
Localized versions of this patch are under development. When completed, they will be available at the locations discussed in "Obtaining other security patches".
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
All patches available via WindowsUpdate also are available in a redistributable form from the WindowsUpdate Corporate site.
Other information:
Acknowledgments
Microsoft thanks BindView's Razor Team (http://razor.bindview.com) for reporting these issues to us and helping us protect our customers.
Support:
Microsoft Knowledge Base article Q281297 discusses this issue and will be available approximately 24 hours after the release of this bulletin. 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 (March 27, 2001): Bulletin Created.
socalgal
03-30-2001, 09:38 PM
Microsoft Security Bulletin (MS01-019) (http://www.microsoft.com/technet/security/bulletin/MS01-019.asp)
Passwords for Compressed Folders are Recoverable
Originally posted: March 28, 2001
Summary
Who should read this bulletin: Customers using the Compressed Folders feature in Microsoft® Plus! 98 and Windows® Me.
Impact of vulnerability: Data compression passwords can be recovered.
Recommendation: Customers who password-protect their compressed folders should apply the patch and delete c:\windows\dynazip.log.
Affected Software:
Microsoft Plus! 98
Microsoft Windows Me
Technical details
Technical description:
Plus! 98, an optional package that extends Windows 98 and Windows 98 Second Edition, introduced a data compression feature called Compressed Folders that was also included in Windows Me. For interoperability with leading third-party compression tools, it provides a password protection option for folders that have been compressed. However, due to a flaw in the package’s implementation, the passwords used to protect the folders are recorded in a file on the user’s system. If an attacker gained access to an affected machine on which password-protected folders were stored, she could learn the passwords and access the files.
It is important to understand that, although this flaw does constitute a security vulnerability, the password protection feature is not intended to provide strong security. It was included in the products to enable interoperability with password-protection features in other third-party data compression products, and is only intended to provide protection against casual inspection. Customers who need strong protection for files should use Windows® 2000.
The patch will prevent passwords from being written to the user’s system in the future. However, as discussed in the FAQ, after applying the patch, it is important to also delete c:\windows\dynazip.log, in order to ensure that all previously-recorded passwords are deleted.
Mitigating factors:
The password at issue here is not related in any way to the user's network logon password. It is used solely for password-protecting compressed folders.
An attacker would require physical access to an affected system in order to recover the password, or the owner of the machine would need to have deliberately shared out the c:\windows folder.
Vulnerability identifier: CAN-2001-0152
Tested Versions:
Microsoft tested Windows Me and Plus! 98 to assess whether they are affected by these vulnerabilities. The data compression feature did not exist prior to these products.
Frequently asked questions
What’s the scope of the vulnerability?
Windows Me and Plus! 98 (an add-on package for Windows 98 and Windows 98 Second Edition) provide an optional feature that can be used to password-protect folders after they have been compressed. This vulnerability could divulge the passwords used to protect these folders. If an attacker had access to the password-protected folders on an affected machine, she could use the vulnerability to read or change them.
Although the passwords should clearly not be available on the system, it is important to keep this issue in perspective. The passwords at issue here are involved solely with password-protecting compressed files - they are are not related in any way to the user's logon password. Also, the password protection protection feature is not intended to act as an access control mechanism – it is provided for solely for compatibility with third-party products’ password mechanisms. Even after applying this patch, the password protection feature here only provides protection against casual scrutiny. Customers who need strong security, including strong access controls, should consider using Windows 2000.
What causes the vulnerability?
Windows Me and Plus! 98 provide a data compression feature that allows a compressed folder to be password-protected. However, under certain conditions, the password can be recorded in a file on the user’s system.
What’s Plus! 98?
Plus! 98 is an optional package that provides additional functionality to Windows 98 and Windows 98 Second Edition. In addition to including the data compression feature at issue here, it also provide a virus scanner, a disk cleaning feature, several games, and other features.
What’s the data compression feature, and how is password protection related to it?
Both Plus! 98 and Windows Millenium provide a feature called Compressed Folders, that can be used to compress folders and the files within them as a way of saving disk space. The Compressed Folders feature uses the same algorithm as several popular third-party utilities. However, it is more convenient than third-party tools – the user can select whether or not a folder should be compressed via the Properties page.
The feature also allows the user to password-protect compressed folders, and this is where the vulnerability lies. By design, the passwords should never be recorded. However, in actuality, the passwords are logged in a file on the user’s system.
How could an attacker exploit this vulnerability?
If an attacker had physical access to a machine, she could read the passwords and access any password-protected compressed folders on the system.
Would this password enable the attacker to log onto my network?
The password at issue here is used solely by the Compressed Folders feature. It is completely separate from any other password, including the network logon password. It is possible for a user to choose any desired value for this password, but it's extremely bad practice to use the same password in multiple places.
How serious is this vulnerability?
Although storing the passwords on the system clearly is a security vulnerability, it’s important to understand that the password protection feature is not intended to provide strong security. It’s only intended to protect the contents of the file against casual inspection. By design, Windows 98 and Me do not provide an access control mechanism, and this feature not intended to function as one. Customers who need strong access control should consider Windows NT® or Windows 2000.
If the option isn't intended to provide strong security, why is it provided?
One of our primary design goals for the Compressed Folders feature was interoperability with leading third-party compression tools. To accomplish this, we chose to implement the same feature set as they do, using compatible compression and password algorithms.
I haven’t installed Plus! 98, but I use Windows 98. Could I be affected by this vulnerability?
No. The data compression feature isn’t included in Windows 98 or Windows 98 Second Edition. Customers using these products could only be affected if they’ve installed the Plus! 98 package on their systems.
I use Windows 95. Could I be affected by the vulnerability?
No. The Compressed Folders feature was not included in Windows 95.
Is Plus! 95 affected by the vulnerability?
No. The data compression feature doesn’t ship as part of Windows 95, nor as part of Plus! 95.
Would it be possible for a Windows 95 user to install Plus! 98?
No. Plus! 98 will only install on a system running Windows 98 or Windows 98SE.
Who should use the patch?
Microsoft recommends that customers who use Windows Me or Plus! 98 and who use the password protection feature on compressed folders consider applying the patch.
What does the patch do?
The patch eliminates the vulnerability by preventing the passwords from being written to the disk.
After applying the patch, is there anything else I need to do?
Yes. Applying the patch will prevent future passwords from being stored on the system, but you’ll still need to remove any that have previously been stored. To do this, use Windows Explorer to delete the file c:\windows\dynazip.log.
Patch availability
Download locations for this patch
Microsoft Plus! 98 http://download.microsoft.com/download/win98/update/14715/w98/en-us/252694usa8.exe
Microsoft Windows Me http://download.microsoft.com/download/winme/update/14715/winme/en-us/252694usam.exe
Additional information about this patch
Installation platforms:
This patch can be installed on Windows 98 and Windows 98SE systems on which Plus! 98 has been installed. It also can be installed on Windows Me Gold systems.
Inclusion in future service packs:
Service pack plans for Windows Me have not yet been finalized. However, if a service pack for Windows Me is produced, the fix for this issue will be included in it.
Verifying patch installation:
Plus! 98:
Verify that the version information for zipfldr.dll is 5.0.526.20 on Japanese/NEC systems, and 5.0.518.20 for all other languages.
Windows Me:
Verify that the version information for zipfldr.dll is 5.50.4213.1600.
Caveats:
None
Localization:
Localized versions of this patch are available. Microsoft Knoweldge Base article Q252694 provides links to the localized versions.
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
All patches available via WindowsUpdate also are available in a redistributable form from the WindowsUpdate Corporate site.
Other information:
Support:
Microsoft Knowledge Base article Q252694 discusses this issue and will be available approximately 24 hours after the release of this bulletin. 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 (March 28, 2001): Bulletin Created.
socalgal
03-30-2001, 09:40 PM
Microsoft Security Bulletin (MS01-020) (http://www.microsoft.com/technet/security/bulletin/MS01-020.asp)
Incorrect MIME Header Can Cause IE to Execute E-mail Attachment
Originally posted: March 29, 2001
Summary
Who should read this bulletin: Customers using Microsoft® Internet Explorer.
Impact of vulnerability: Run code of attacker’s choice.
Recommendation: Customers using IE should install the patch immediately.
Affected Software:
Microsoft Internet Explorer 5.01
Microsoft Internet Explorer 5.5
Note: Internet Explorer 5.01 Service Pack 2 is not affected by this vulnerability.
Technical details
Technical description:
Because HTML e-mails are simply web pages, IE can render them and open binary attachments in a way that is appropriate to their MIME types. However, a flaw exists in the type of processing that is specified for certain unusual MIME types. If an attacker created an HTML e-mail containing an executable attachment, then modified the MIME header information to specify that the attachment was one of the unusual MIME types that IE handles incorrectly, IE would launch the attachment automatically when it rendered the e-mail.
An attacker could use this vulnerability in either of two scenarios. She could host an affected HTML e-mail on a web site and try to persuade another user to visit it, at which point script on a web page could open the mail and initiate the executable. Alternatively, she could send the HTML mail directly to the user. In either case, the executable attachment, if it ran, would be limited only by user’s permissions on the system.
Mitigating factors:
The vulnerability could not be exploited if File Downloads have been disabled in the Security Zone in which the e-mail is rendered. This is not a default setting in any zone, however.
Vulnerability identifier: CAN-2001-0154
Tested Versions:
Microsoft tested IE 5.01 and IE 5.5 to assess whether they are affected by this vulnerability. Previous versions are no longer supported and may or may not be affected by this vulnerability.
Frequently asked questions
What’s the scope of the vulnerability?
This vulnerability could enable an attacker to potentially run a program of her choice on the machine of another user. Such a program would be capable of taking any action that the user himself could take on his machine, including adding, changing or deleting data, communicating with web sites, or reformatting the hard drive.
In order for the attacker to successfully attack the user via this vulnerability, she would need to be able to persuade the user to either browse to a web site she controlled or open an HTML e-mail that she had sent.
What causes the vulnerability?
If an HTML mail contains an executable attachment whose MIME type is incorrectly given as one of several unusual types, a flaw in IE will cause the attachment to be executed without displaying a warning dialogue.
Why is IE used to process HTML mails? I thought mail programs like Outlook and Outlook Express were in charge of displaying mails.
In general, they are. Mail clients handle creating, sending, receiving and displaying e-mail. There is one exception, however – they rely on IE to perform a process called “rendering” if the mail is an HTML mail. Rendering is the process of processing and displaying a web page. HTML mails are rendered by IE because they are essentially web pages sent as mails. The flaw in this case involves how IE renders HTML mails.
What’s the problem with how IE renders HTML mails?
If a mail contains an attachment, IE should provide the ability to open the attachment when it renders the message. The precise meaning of “open” depends on the type of file. If the attachment is a text file, IE should provide the ability to read it; if it’s a video clip, IE should provide the ability to view it; if it’s a graphics file, IE should provide the ability to display it; and so on.
Some types of attachments, such as executable files, are inherently dangerous. In these cases, IE should only open the attachment if the user expressly asks to do so, and confirms that he wants to open it. The flaw, however, enables this safeguard to be circumvented by specifying an incorrect MIME type in the e-mail.
What’s a MIME type?
Let’s start with what MIME is. MIME is an acronym for Multipurpose Internet Mail Extensions. It’s a widely used Internet standard for encoding binary files as e-mail attachments. When an e-mail contains a binary attachment, it must specify what type of file the attachment is, so the mail program can interpret it correctly.
In the case of this vulnerability, IE doesn’t correctly handle certain types of fairly unusual MIME types. If an attacker created an e-mail message containing an executable attachment, and specified that it was one of these MIME types, IE would execute the attachment rather than prompting the user.
Would IE always execute the attachment?
No. IE would only execute the attachment if File Downloads were enabled in the Security Zone that the e-mail was opened in. However, File Downloads are enabled in all zones by default.
What would this vulnerability enable an attacker to do?
If an attacker created an e-mail that exploits this vulnerability, she could use it in an attempt to run the executable attachment on another user’s computer. She could try to do this through either of two scenarios. First, she could host the HTML mail on her web site, and try to persuade the user to visit it. Second, she could send the email directly to the user.
What kind of actions could the attachment take if it ran?
The attachment would be able to take any action that the user himself could take on his system. If he were an unprivileged user, it might be able to do very little. However, if the user were an administrator on his system, the attachment would be able to do virtually anything, including reformatting the hard drive.
Could an e-mail accidentally be created that would exploit this vulnerability?
No. To create such an e-mail, an attacker would need to create an e-mail containing an executable attachment, then deliberately edit the MIME headers in the mail to be one of the affected types.
What does the patch do?
The patch eliminates the vulnerability by correcting the table of MIME types and their associated actions in IE. This has the effect of preventing emails from being able to automatically launch executable attachments.
I've already installed IE 5.01 Service Pack 2. Do I need to install the patch?
No. The fix for this issue is included in IE 5.01 Service Pack 2. If you've already installed it, you do not need to install the patch.
I heard that even after applying this patch, an e-mail could start a file download automatically. Is this true?
Yes. However, this is not related to this vulnerability, and doesn’t pose a security risk. It’s always possible for an e-mail to start a file download, and of course the author of the mail can give the file a name that sounds innocuous. However, the file download cannot actually begin unless and until the user selects a location to which it should be downloaded, and clicks the OK button.
As a general rule, it is probably worth questioning the trustworthiness of any e-mail that automatically starts a file download. The best action is to simply click the Cancel button in the dialogue.
Patch availability
Download locations for this patch http://www.microsoft.com/windows/ie/download/critical/Q290108/default.asp
Additional information about this patch
Installation platforms:
This patch can be installed on systems running Internet Explorer 5.01 Service Pack 1 or Internet Explorer 5.5 Service Pack 1.
Inclusion in future service packs:
The fix for this issue is included in Internet Explorer 5.01 Service Pack 2 and will be included in Internet Explorer 5.5 Service Pack 2.
Verifying patch installation:
To verify that the patch has been installed on the machine, open IE, select Help, then select About Internet Explorer and confirm that Q290108 is listed in the Update Versions field.
To verify the individual files, use the patch manifest provided in Knowledge Base article Q290108
Caveats:
If the patch is installed on a system running a version of IE other than the one it is designed for, an error message will be displayed saying that the patch is not needed. This message is incorrect, and customers who see this message should upgrade to a supported version of IE and re-install the patches.
Localization:
Localized versions of this patch are under development. When completed, they will be available at the locations discussed in "Obtaining other security patches".
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
All patches available via WindowsUpdate also are available in a redistributable form from the WindowsUpdate Corporate site.
Other information:
Acknowledgments
Microsoft thanks Juan Carlos Cuartango (http://www.kriptopolis.com) for reporting this issue to us and working with us to protect customers.
Support:
Microsoft Knowledge Base article Q290108 discusses this issue and will be available approximately 24 hours after the release of this bulletin. 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 (March 29, 2001): Bulletin Created.
socalgal
04-16-2001, 08:04 AM
The following is a Security Bulletin from the Microsoft Product Security
Notification Service.
Please do not reply to this message, as it was sent from an unattended
mailbox.
********************************
-----BEGIN PGP SIGNED MESSAGE-----
- ----------------------------------------------------------------------
Title: Invalid Web Request Can Cause Access Violation in ISA
Server Web Proxy Service
Date: 16 April 2001
Software: ISA Server 2000
Impact: Denial of service
Bulletin: MS01-021
Microsoft encourages customers to review the Security Bulletin
at: http://www.microsoft.com/technet/security/bulletin/MS01-021.asp
- ----------------------------------------------------------------------
Issue:
======
The ISA Server Web Proxy service does not correctly handle web
requests that contain a particular type of malformed argument.
Processing such a request would result in an access violation,
which would cause the Web Proxy service to fail. This would disrupt
all ingoing and outgoing web proxy requests until the service was
restarted.
Mitigating Factors:
====================
- The vulnerability could be exploited from the Internet only
if the Web Publishing feature were enabled. By default,
this feature is disabled.
- The vulnerability would not enable an attacker to breach the
security of the firewall - that is, it would not enable the
attacker to access protected resources or bypass the firewall.
It would only enable the attacker to deny legitimate service
to other users.
- The vulnerability would only allow the Web Proxy service to
be disrupted. Other ISA services would continue functioning
normally.
Patch Availability:
===================
- A patch is available to fix this vulnerability. Please read
Security Bulletin
http://www.microsoft.com/technet/security/bulletin/ms01-021.asp
for information on obtaining this patch.
Acknowledgment:
===============
- Dr. Richard Reiner, Graham Wiseman, Matthew Siemens, and
Kent Nicolson of FSC Internet Corp. / SecureXpert Labs
http://www.fscinternet.com / http://www.securexpert.com
[This message has been edited by socalgal (edited 04-16-2001).]
socalgal
04-22-2001, 05:44 PM
Apologies for lateness in posting; I was out of town. -Socalgal
``````````````````````````````````````````
==========================================
The following is a Security Bulletin from the Microsoft Product Security
Notification Service.
Please do not reply to this message, as it was sent from an unattended
mailbox.
********************************
-----BEGIN PGP SIGNED MESSAGE-----
- ----------------------------------------------------------------------
Title: WebDAV Service Provider Can Allow Scripts to Levy
Requests as User
Date: 18 April 2001
Software: Microsoft Data Access Component Internet Publishing
Provider
Impact: Web-based script could levy WebDAV requests on the user's
behalf.
Bulletin: MS01-022
Microsoft encourages customers to review the Security Bulletin at: http://www.microsoft.com/technet/security/bulletin/MS01-022.asp
- ----------------------------------------------------------------------
Issue:
======
The Microsoft Data Access Component Internet Publishing Provider
provides access to WebDAV resources over the Internet. By design, it
should differentiate between requests made by a user and those made
by
a script running in the user's browser. However, because of an
implementation flaw, it handles all requests in the security context
of
the user. As a result, if a user browsed to a web page or opened an
HTML e-mail that contained script, that script could access web-based
resources as the user.
The specific actions an attacker could take via this vulnerability
would depend on the Web-based resources available to the user, and
the
user's privileges on them. However, it is likely that at a minimum,
the
attacker could browse the user's intranet, and potentially access
web-based e-mail as well.
Mitigating Factors:
====================
- The attacker would need to possess significant inside information
in
order to carry out a successful attack, such as server names,
folder
structures, and other user- and network-specific information. This
vulnerability would therefore be most likely used as part of an
insider attack.
- The vulnerability could not be exploited against stand-alone
machines.
- The vulnerability could not be exploited if Active Scripting was
disabled in the Security Zone the script opened in.
Patch Availability:
===================
- A patch is available to fix this vulnerability. Please read the
Security Bulletin
http://www.microsoft.com/technet/security/bulletin/ms01-022.asp
for information on obtaining this patch.
[This message has been edited by socalgal (edited 04-22-2001).]
socalgal
04-22-2001, 05:46 PM
The following is a Security Bulletin from the Microsoft Product Security
Notification Service.
Please do not reply to this message, as it was sent from an unattended
mailbox.
********************************
-----BEGIN PGP SIGNED MESSAGE-----
- ----------------------------------------------------------------------
Title: IE can Divulge Location of Cached Content
Released: 06 March 2001
Revised: 20 April 2001 (version 2.0)
Software: Microsoft Windows Script Host 5.1 and 5.5
Impact: Run code of attacker's choice
Bulletin: MS01-015
Microsoft encourages customers to review the Security Bulletin at: http://www.microsoft.com/technet/security/bulletin/MS01-015.asp
- ----------------------------------------------------------------------
Reason for Revision:
====================
A regression was found in the previously released Windows Script Host
patch referenced in the first version of this security bulletin. We
have updated and re-released the Windows Script Host patch and have
updated the bulletin
accordingly. The re-release only applies to changes with the Windows
Script Host patches available in the bulletin. No changes have been
made to the originally released Internet Explorer patches.
Customers who applied the Windows Script Host patch when this
bulletin was first released should download and apply the updated
Windows Script Host patch referenced in the bulletin. Customers who
did not apply the Windows Script Host when this bulletin was first
released are encouraged to apply the Windows Script Host patch listed
in the bulletin.
Issue:
======
The IE security architecture provides a caching mechanism that is
used
to store content that needs to be downloaded and processed on the
user's local machine. The purpose of the cache is to obfuscate the
physical location of the cached content, in order to ensure that the
web page or HTML e-mail will work through the IE security
architecture
to access the information. This ensures that the uses of the
information can be properly restricted.
A vulnerability exists because it is possible for a web page or HTML
e- mail to learn the physical location of cached content. Armed with
this
information, an attacker could cause the cached content to be opened
in
the Local Computer Zone. This would enable him to launch compiled
HTML
help (.CHM) files that contain shortcuts to executables, thereby
enabling him to run the executables.
In addition to eliminating this vulnerability, the patches provided
below eliminate three other vulnerabilities that either pose
significantly less risk or could only be exploited in very restricted
situations:
A variant of the Frame Domain Verification vulnerability discussed in
Microsoft Security Bulletins MS00-033, MS00-055, and MS00-093. The
vulnerability could enable a malicious web site operator to open two
browser windows, one in the web site's domain and the other on the
user's local file system, and to pass information from the latter to
the former. This could enable the web site operator to read, but not
change, any file on the user's local computer that could be opened in
a
browser window.
A vulnerability that is identical in effect to the Frame Domain
Verification vulnerability, but which actually results from a flaw in
Windows Script Host rather than IE. Because it could only be
exploited
via IE, we have provided the fix here. The fix that was released on
March 06, 2001, was subsequently discovered to have a regression
error,
and a corrected version was released on April 19, 2001.
A vulnerability that affects how Telnet sessions are invoked via IE.
By
design, telnet sessions can be launched via IE. However, a
vulnerability exists because when doing so, IE will start Telnet
using
any command-line options the web site specifies. This only becomes a
concern when using the version of the Telnet client that installs as
part of Services for Unix (SFU) 2.0 on Windows NT 4.0 or Windows 2000
machines. The version of the Telnet client in SFU 2.0 provides an
option for creating a verbatim transcript of a Telnet session. An
attacker could start a session using the logging option, then stream
an
executable file onto the user's system in a location that would cause
it to be executed automatically the next time the user booted the
machine. The flaw does not lie in the Telnet client, but in IE, which
should not allow Telnet to be started remotely with command-line
arguments.
Mitigating Factors:
====================
None of the vulnerabilities could be exploited without some user
action - either browsing to the attacker's site or opening a mail
from him.
- Customers who exercise safe browsing habits would be less likely
visit untrustworthy sites, and customers who have used the
Security
Zones feature to restrict what HTML mail can do would be less
likely to
be affected by this vulnerability.
- The variants of the "frame domain verification" vulnerability
discussed
above could only be used to view files, and only file types that
can be
opened in a browser window.
- The vulnerability affecting Telnet invocation is only a concern
for
customers who are using the Telnet client that ships as part of
Services for Unix 2.0. Other versions of Telnet do not include the
command-line feature to create log files.
Patch Availability:
===================
- A patch is available to fix this vulnerability. Please read the
Security Bulletin
http://www.microsoft.com/technet/security/bulletin/ms01-015.asp
for information on obtaining this patch.
Acknowledgment:
===============
- Oliver Friedrichs of securityfocus.com (for reporting the Telnet
invocation issue)
socalgal
05-01-2001, 02:22 PM
The following is a Security Bulletin from the Microsoft Product Security
Notification Service.
Please do not reply to this message, as it was sent from an unattended
mailbox.
********************************
-----BEGIN PGP SIGNED MESSAGE-----
- ----------------------------------------------------------------------
Title: Unchecked Buffer in ISAPI Extension Could Enable
Compromise of IIS 5.0 Server
Date: 01 May 2001
Software: Windows 2000 Server
Windows 2000 Advanced Server
Windows 2000 Datacenter Server
Impact: Run code of attacker's choice, in Local System context
Bulletin: MS01-023
Microsoft encourages customers to review the Security Bulletin at: http://www.microsoft.com/technet/security/bulletin/MS01-023.asp
- ----------------------------------------------------------------------
Issue:
======
Windows 2000 introduced native support for the Internet Printing
Protocol (IPP), an industry-standard protocol for submitting and
controlling print jobs over HTTP. The protocol is implemented in
Windows 2000 via an ISAPI extension that is installed by default on
all
Windows 2000 servers but which can only be accessed via IIS 5.0.
A security vulnerability results because the ISAPI extension contains
an unchecked buffer in a section of code that handles input
parameters.
This could enable a remote attacker to conduct a buffer overrun
attack
and cause code of her choice to run on the server. Such code would
run
in the Local System security context. This would give the attacker
complete control of the server, and would enable her to take
virtually
any action she chose.
The attacker could exploit the vulnerability against any server with
which she could conduct a web session. No other services would need
to
be available, and only port 80 (HTTP) or 443 (HTTPS) would need to be
open. Clearly, this is a very serious vulnerability, and Microsoft
strongly recommends that all IIS 5.0 administrators install the patch
immediately. Alternatively, customers who cannot install the patch
can
protect their systems by removing the mapping for Internet Printing
ISAPI extension.
Mitigating Factors:
====================
- Servers on which the mapping for the Internet Printing
ISAPI extension has been removed are not at risk from
this vulnerability. The process for removing the mapping
is discussed in the IIS 5.0 Security Checklist
( http://www.microsoft.com/technet/security/iis5chk.asp ).
The High Security template provided in the checklist
( http://www.microsoft.com/technet/security/tools.asp )
removes the mapping, as does the Windows 2000 Internet
Security Tool unless the user explicitly chose to retain
Internet Printing.
- The attacker's ability to extend her control from a
compromised web server to other machines would be heavily
dependent on the specific configuration of the network.
Best practices recommend that the network architecture reflect
the position of special risk occupied by network-edge machines
like web servers and use measures like DMZs and limited domain
memberships to isolate such machines from the rest of the
network. Taking such measures would impede an attacker's ability
to broaden the scope of the compromise.
Patch Availability:
===================
- A patch is available to fix this vulnerability. Please read the
Security Bulletin
http://www.microsoft.com/technet/security/bulletin/ms01-023.asp
for information on obtaining this patch.
Acknowledgment:
===============
- eEye Digital Security ( http://www.eeye.com )
socalgal
05-09-2001, 10:13 AM
The following is a Security Bulletin from the Microsoft Product Security
Notification Service.
Please do not reply to this message, as it was sent from an unattended
mailbox.
********************************
-----BEGIN PGP SIGNED MESSAGE-----
- ---------------------------------------------------------------------
Title: Malformed Request to Domain Controller can
Cause Memory Exhaustion
Date: 08 May 2001
Software: Windows 2000 Server
Windows 2000 Advanced Server
Windows 2000 Datacenter Server
Impact: Denial of Service
Bulletin: MS01-024
Microsoft encourages customers to review the Security Bulletin at: http://www.microsoft.com/technet/security/bulletin/MS01-024.asp
- ----------------------------------------------------------------------
Issue:
======
A core service running on all Windows 2000 domain controllers (but
not
on any other machines) contains a memory leak, which can be triggered
when it attempts to process a certain type of invalid service
request.
By repeatedly sending such a request, an attacker could deplete the
available memory on the server. If memory were sufficiently depleted,
the
domain controller could become unresponsive, which would prevent it
from
processing logon requests or issuing new Kerberos tickets. An
affected
machine could be put back into service by rebooting.
Mitigating Factors:
====================
- Users who were already logged on and using previously issued
Kerberos
tickets would not be affected by domain controller unavailability.
- If there were multiple domain controllers on the domain, the
unaffected
machines could pick up the other machine's load.
- If normal security practices have been followed, Internet users
would
be prevented by firewalls and other measures from levying requests
directly to domain controllers.
Patch Availability:
===================
- A patch is available to fix this vulnerability. Please read the
Security Bulletin
http://www.microsoft.com/technet/security/bulletin/ms01-024.asp
for information on obtaining this patch.
Acknowledgment:
===============
- Peter Grundl of Defcom ( www.defcom.com (http://www.defcom.com) )
socalgal
05-10-2001, 08:52 PM
The following is a Security Bulletin from the Microsoft Product Security
Notification Service.
Please do not reply to this message, as it was sent from an unattended
mailbox.
********************************
-----BEGIN PGP SIGNED MESSAGE-----
- ----------------------------------------------------------------------
Title: Patch Available for "SQL Server 7.0 Service Pack
Password" Vulnerability
Released: 15 June 2000
Revised: 10 May 2001 (version 2.0)
Software: SQL Server 7.0
Impact: Information disclosure
Bulletin: MS00-035
Microsoft encourages customers to review the Security Bulletin at: http://www.microsoft.com/technet/security/bulletin/MS00-035.asp
Reason for Revision:
====================
Bulletin was revised to reflect a patch available for SQL Server 7.0
Service Pack 3 and a password removal tool available via KB
article Q263968.
Issue:
======
When SQL Server 7.0 Service Packs 1, 2, or 3 are installed on a
machine
that is configured to perform authentication using Mixed Mode, the
password for the SQL Server standard security System Administrator
(sa)
account is recorded in plaintext in the files %TEMP%\sqlsp.log and
%WINNT%\setup.iss. The default permissions on the files would allow
any
user to read them who could log onto the server interactively.
The password is only recorded if Mixed Mode is used, and even then,
only if the adminstrator chose to use SQL Server Authentication when
installing the service pack. Microsoft has long recommended that SQL
servers be configured to use the more secure Windows NT
Authentication
Mode, and customers who have followed this recommendation would not
be
affected. Even on affected machines, the password could not be
compromised if, per normal security recommendations, normal users are
prevented from logging onto the machine interactively.
Mitigating Factors:
====================
- It does not occur when the recommended authentication method,
Windows NT Authentication, is used.
- Even when Mixed Mode is used, it only occurs if a particular type
of
authentication, SQL Server Authentication, is used.
- By default, the files containing the password could only be read
by
a user who could interactively log onto the server. Standard
security
recommendations strongly militate against allowing normal users to
interactively log onto security critical servers such as database
servers.
Patch Availability:
===================
- A patch is available to fix this vulnerability. Please read the
Security Bulletin
http://www.microsoft.com/technet/security/bulletin/ms00-035.asp
for information on obtaining this patch.
socalgal
05-10-2001, 08:54 PM
The following is a Security Bulletin from the Microsoft Product Security
Notification Service.
Please do not reply to this message, as it was sent from an unattended
mailbox.
********************************
-----BEGIN PGP SIGNED MESSAGE-----
- ----------------------------------------------------------------------
Title: Index Server Search Function Contains Unchecked Buffer
Date: 10 May 2001
Software: Index Server 2.0, Indexing Service for Windows 2000
Impact: Run code of attacker's choice; file disclosure
Bulletin: MS01-025
Microsoft encourages customers to review the Security Bulletin at: http://www.microsoft.com/technet/security/bulletin/MS01-025.asp
Issue:
======
The patches provided in the bulletin address two security
vulnerabilities that are unrelated to each other except in the sense
that both affect Index Server 2.0. The first vulnerability is a
buffer overrun vulnerability. Index Server 2.0 has an unchecked
buffer in a function that processes search requests. If an overly
long value were provided for a particular search parameter, it would
overrun the buffer. If the buffer were overrun with random data, it
would cause Index Server to fail. If it were overrun with carefully
selected data, code of the attacker's choice could be made to run on
the server, in the Local System security context.
The second vulnerability affects both Index Server 2.0 and Indexing
Service in Windows 2000, and is a new variant of the "Malformed
Hit-Highlighting" vulnerability discussed in Microsoft Security
Bulletin MS00-006 ( http://www.microsoft.com/technet/security/bulletin/MS00-006.asp ).
The new variant has almost the same scope as the original
vulnerability, but potentially exposes a new file type If an attacker
provided an invalid search request, she could read "include" files
residing on the web server. The new patch eliminates all known
variants of the vulnerability.
Mitigating Factors:
====================
Index Server 2.0 buffer overrun:
- The vulnerability only affects Index Server 2.0. Indexing
Services in Windows 2000 is not affected by it.
- In order to exploit the vulnerability, the attacker would
need the ability to authenticate to the server and to
create a named pipe connection to it (which requires access
to NetBIOS, which should be blocked at the firewall). As a
result, it is likely that this vulnerability could, in a
properly configured network, only be exploited by an intranet
user.
- Index Server 2.0 is not provided as part of Windows NT 4.0;
instead, it is part of the Windows NT 4.0 Option Pack. It
installs by default as part of that package, but does not run
by default.
New Variant of "Malformed Hit-Highlighting" vulnerability:
- The vulnerability would only allow files to be read. They
could not be added, changed or deleted via this vulnerability.
- Server-side "include" files should not contain sensitive data.
If this recommendation has been followed, there would be no
sensitive data to compromise via this vulnerability.
- The vulnerability would only allow files residing on the web
server - and in the same logical drive as the server's root
directory - to be read. It would not allow files elsewhere
on the server, or files residing on a remote server, to be read.
Patch Availability:
===================
- A patch is available to fix this vulnerability. Please read the
Security Bulletin
http://www.microsoft.com/technet/security/bulletin/ms01-025.asp
for information on obtaining this patch.
Acknowledgment:
===============
- David Litchfield of @Stake ( http://www.atstake.com ) for reporting
the Index Server 2.0 buffer overrun.
- Mike Mulling ( http://www.gap.com ) for reporting the new variant
of the "Malformed Hit-Highlighting" vulnerability.
socalgal
05-14-2001, 05:27 PM
The following is a Security Bulletin from the Microsoft Product Security
Notification Service.
Please do not reply to this message, as it was sent from an unattended
mailbox.
********************************
-----BEGIN PGP SIGNED MESSAGE-----
- ----------------------------------------------------------------------
Title: Superfluous Decoding Operation Could Allow Command
Execution via IIS
Date: May 14, 2001
Software: IIS 4.0 and 5.0
Impact: Three vulnerabilities: Code execution; denial of
service, information disclosure.
Bulletin: MS01-026
Microsoft encourages customers to review the Security Bulletin at: http://www.microsoft.com/technet/security/bulletin/MS01-026.asp
- ----------------------------------------------------------------------
Issue:
======
This patch is a cumulative patch that includes the functionality of
all
security patches released to date for IIS 5.0, and all patches
released
for IIS 4.0 since Windows NT(r) 4.0 Service Pack 5. A complete
listing of
the patches superseded by this patch is provided in the web-hosted
security bulletin, in the section titled "Additional information
about
this patch". Before applying the patch, system administrators should
take note of the caveats discussed in the same section.
The patch also eliminates three newly discovered vulnerabilities:
- A vulnerability that could enable an attacker to run
operating system commands on an affected server. When
IIS receives a user request to run a script or other
server-side program, it performs a decoding pass to
render the request in a canonical form, then performs
security checks on the decoded request. A vulnerability
results because a second, superfluous decoding pass is
performed after the security checks are completed. If an
attacker submitted a specially constructed request, it could
be possible for the request to pass the security checks, but
then be mapped via the second decoding pass into one that
should have been blocked -- specifically, it could enable
the request to execute operating system commands or programs
outside the virtual folder structure. These would be executed
in the security context of the IUSR_machinename account which,
by virtue of its membership in the Everyone group, would grant
the attacker capabilities similar to those of a non-administrative
user interactively logged on at the console.
- A vulnerability that could enable denial of service attacks
against the FTP service. A function that processes wildcard
sequences in FTP commands doesn't always allocate sufficient
memory when performing pattern matching. Under unusual
circumstances, it could be possible for an attacker to levy an
FTP command containing a wildcard sequence that, when expanded,
would overrun the allocated memory and cause an access violation.
This would cause the IIS service (which provides both the web and
FTP functionality) to fail. As a result, all web or FTP sessions
in progress at the time would be severed, and no new sessions
could be established until the IIS service was restarted. In IIS
5.0, the service would restart automatically. In IIS 4.0, operator
intervention would be required to restart the service.
- A vulnerability that could make it easier for an attacker to find
Guest accounts that had been inadvertently exposed via FTP. By
design, if a user wishes to log onto an FTP server using a domain
user account, rather than a local one, he should be required to
precede it with the name of the domain. However, if an attacker
preceded an account name with a particular set of characters, the
FTP service would search the domain, and all trusted domains, for
the user account. The account would need to be enabled, and the
attacker would still need to know the correct password in order
to log into the account. For all practical purposes, this would
limit the attacker to attacking the Guest account, as it is the
only account with both a well-known account name and a well-known
default password.
The patch also corrects errors in three previous patches:
- The patch originally provided in Microsoft Security Bulletin
MS00-060 successfully eliminated the vulnerability at issue there,
but created an opportunity to cause the server to expend an
inordinate amount of time processing a particular type of invalid
request.
- The patches originally provided in Microsoft Security Bulletins
MS01-014 and MS01-016 (which superseded MS01-014) successfully
eliminated the vulnerabilities at issue there, but created a
potential denial of service condition via a memory leak.
Mitigating Factors:
====================
IIS vulnerability:
- The vulnerability does not provide a way for the attacker to
learn the folder structure on the server. As a result, if the
operating system were installed on a separate drive from the
web root or in non-standard folders, it could prevent an
attacker from locating programs of interest.
- The vulnerability does not provide administrative access to
the server. If the recommendations in the IIS 4.0 and IIS 5.0
security checklists have been followed, sensitive programs
will have been moved to folders that can only be accessed by
the Administrator, and non-administrative access to server
resources will be have been severely restricted.
FTP denial of service vulnerability:
- The attacker would require the ability to start an FTP
session in order to exploit the vulnerability.
FTP user account vulnerability:
- The vulnerability could only be exploited if the FTP server
was a domain member. However, this is usually not appropriate
for Internet-connected FTP servers.
- The vulnerability could only be exploited if the Guest account
on the local machine was disabled, but the Guest account on a
trusted domain was enabled. By default, the Guest account is
disabled in both Windows NT 4.0 and Windows 2000.
Patch Availability:
===================
- A patch is available to fix this vulnerability. Please read the
Security Bulletin
http://www.microsoft.com/technet/security/bulletin/ms01-026.asp
for information on obtaining this patch.
Acknowledgment:
===============
- NSfocus ( http://www.nsfocus.com ) for reporting the vulnerability
affecting IIS.
- Lukasz Luzar of Developers.of.PL and Aiden ORawe for reporting
the FTP denial of service.
- Kevin Kotas of eSecurityOnline ( http://www.esecurityonline.com )
for reporting the problem in the fixes that were provided in
MS00-060, MS01-014 and MS01-016.
socalgal
05-16-2001, 08:37 PM
The following is a Security Bulletin from the Microsoft Product Security
Notification Service.
Please do not reply to this message, as it was sent from an unattended
mailbox.
********************************
-----BEGIN PGP SIGNED MESSAGE-----
- ----------------------------------------------------------------------
Title: Flaws in Web Server Certificate Validation Could
Enable Spoofing
Date: 16 May 2001
Software: Internet Explorer
Impact: Spoofing of trusted web site
Bulletin: MS01-027
Microsoft encourages customers to review the Security Bulletin at: http://www.microsoft.com/technet/security/bulletin/MS01-027.asp
- ----------------------------------------------------------------------
Issue:
======
A patch is available to eliminate two newly discovered
vulnerabilities
affecting Internet Explorer, both of which could enable an attacker
to
spoof trusted web sites. The first vulnerability involves how digital
certificates from web servers are validated. When CRL checking for
such
certificates is enabled, it could be possible for any or all of the
following checks to no longer be performed:
- Verification that the certificate has not expired
- Verification that the server name matches the name on the
certificate
- Verification that the issuer of the certificate is trusted
The second vulnerability could enable a web page to display the URL
from a different web site in the IE address bar. This spoofing could
occur within a valid SSL session with the impersonated site. Both
vulnerabilities could be used to convince a user that the attacker's
web site was actually a different one - one that the user presumably
trusts and would provide sensitive information to. However, as
discussed in the Mitigating Factors section below, there would be
significant hurdles to exploiting either vulnerability.
In addition to eliminating the two new vulnerabilities, the patch
also
eliminates two new variants of a previously discussed vulnerability,
the "Frame Domain Verification" vulnerability, which originally was
discussed in Microsoft Security Bulletin MS00-033. Like the original
version, these new variants vulnerability could enable a malicious
web
site operator to open two browser windows, one in the web site's
domain
and the other on the user's local file system, and to pass
information
from the latter to the former. This could enable the web site
operator
to read any file on the user's local computer that could be opened in
a
browser window.
The patch also incorporates the functionality of the patch provided
in
Microsoft Security Bulletin MS01-020
( http://www.microsoft.com/technet/security/bulletin/MS01-020.asp ).
Mitigating Factors:
====================
Server certificate validation vulnerability:
- The vulnerability only affects how certificates from web
servers are validated. It does not affect how code-signing
certificates or any other type of certificate are validated.
- The specific checks that might be bypassed vary with both
the user and the actions she may have taken during the
current browsing session. An attacker could not predict with
any degree of certainty which checks might be bypassed in a
particular case.
- The vulnerability does not provide any way to force users
to the attacker's web site. It is likely that this
vulnerability could only be exploited in conjunction with a
successful DNS poisoning or similar attack.
Web page spoofing vulnerability:
- Like the vulnerability above, this vulnerability would not
provide any way to force users to the attacker's web site,
and DNS poisoning or other measures would likely be required
to exploit it.
- Any hyperlinks within the page would correctly show the target.
As a result, the attacker would need to point these to bona
fide locations on the spoofed web site, with the result that
the attacker would likely only be able to spoof a single web
page, rather than an entire site.
New variants of "Frame Domain Verification" vulnerability:
- The vulnerability could only be used to read - not add, delete
or change - files.
- The attacker would need to know the exact name and location of
every file he wished to read.
- The vulnerability could only be used to read file types that
can be opened within a browser window - for example, .htm,
.txt or .doc files, but not .exe or .xls files.
Patch Availability:
===================
- A patch is available to fix this vulnerability. Please read the
Security Bulletin
http://www.microsoft.com/technet/security/bulletin/ms01-027.asp
for information on obtaining this patch.
socalgal
05-21-2001, 09:40 PM
The following is a Security Bulletin from the Microsoft Product Security
Notification Service.
Please do not reply to this message, as it was sent from an unattended
mailbox.
********************************
-----BEGIN PGP SIGNED MESSAGE-----
- ----------------------------------------------------------------------
Title: RTF document linked to template can run macros without warning
Date: 21 May 2001
Software: Microsoft Word for Windows and Word for the Mac
Impact: Run Macros without warning
Bulletin: MS01-028
Microsoft encourages customers to review the Security Bulletin at: http://www.microsoft.com/technet/security/bulletin/MS01-028.asp
- ----------------------------------------------------------------------
Issue:
======
Word, like other members of the Office product family, provides a
security mechanism that requires user's approval to run macros. By
design, anytime a document is opened the user would be notified if the
document contains macros. In addition, this mechanism checks secondary documents that the original document links to, such as templates, and warn if any of those contain macros. This feature works by scanning
the document or template for the presence of macros, alerting the user of their presence, and then asking the user if he wants to allow the macros to run.
By embedding a macro in a template, and providing another user with an RTF document that links to it, an attacker could cause a macro to run automatically when the RTF document was opened. The macro would be
able to take any action that the user herself could take. This could include
disabling the user's Word security settings so that subsequently-opened Word documents would no longer be checked for macros.
Mitigating Factors:
====================
- The vulnerability only affects Word. Other Office products are not affected.
- The vulnerability does not occur when opening Word documents, only when opening RTF documents, and even then only when the RTF document is linked to a template.
Patch Availability:
===================
- A patch is available to fix this vulnerability. Please read the Security Bulletin
http://www.microsoft.com/technet/security/bulletin/ms01-028.asp
for information on obtaining this patch.
socalgal
05-23-2001, 10:33 PM
The following is a Security Bulletin from the Microsoft Product Security
Notification Service.
Please do not reply to this message, as it was sent from an unattended
mailbox.
********************************
-----BEGIN PGP SIGNED MESSAGE-----
- ----------------------------------------------------------------------
Title: Windows Media Player .ASX Processor Contains Unchecked
Buffer
Date: 23 May 2001
Software: Windows Media Player 6.4 and 7
Impact: Potentially run code of attacker's choice.
Bulletin: MS01-029
Microsoft encourages customers to review the Security Bulletin at: http://www.microsoft.com/technet/security/bulletin/MS01-029.asp
- ----------------------------------------------------------------------
Issue:
======
This bulletin discusses two security vulnerabilities that are related
to each other only by the fact that they affect Windows Media Player.
We packaged them in a single patch for customers using Windows Media
Player 6.4 to make it more convenient for customers to apply. For
customers using Windows Media Player 7, both security vulnerabilities
are addressed by upgrading to Windows Media Player 7.1.
The two vulnerabilities are:
- A buffer overrun in the functionality used to process Active
Stream
Redirector (.ASX) files. This vulnerability is a variant of the
buffer
overrun vulnerability identified in Microsoft Security Bulletin
(MS00-090). Windows Media Player supports the use of .ASX files to
enable users to play streaming media that resides on intranet or
Internet sites and allows the use of playlists. However, the code
that parses .ASX files has an unchecked buffer, and this could
potentially enable a malicious user to run code of her choice on the
machine of another user. The attacker could either send an affected
file to another user and entice him to run or preview it, or she
could
host such a file on a web site and cause it to launch automatically
whenever a user visited the site. The code could take any action on
the machine that the legitimate user himself could take.
- A vulnerability affecting how Windows Media Player handles
Internet
shortcuts. Windows Media Player has a flaw that causes it to save
Internet shortcuts to the user's Temporary Files folder with a fixed
known filename. This results in a security vulnerability because it's
possible for HTML code to be stored in such a shortcut and launched
via
a web page or HTML e-mail, in which case the code would run in the
Local Computer Zone rather than the Internet Zone. An attacker could
exploit this vulnerability to read - but not add, delete or modify -
files on another user's computer.
- In addition, this patch provides a solution to a potential privacy
vulnerability that was recently identified. This issue could be
exploited by a malicious set of web sites to distinguish a user.
While
this issue would not by itself enable a web site to identify the
user,
it could enable the correlation of user information to potentially
build a composite description of the user. .Users can protect
themselves by installing the above patch or upgrading to Windows
Media
Player 7.1, then changing the appropriate settings in their player as
outlined below to prevent sets of websites from potentially profiling
using Windows Media Player.
- In Windows Media Player 6.4, the privacy setting is selected via a
new option, which can be reached by going to the menu item View /
Options then selecting the player tab and de-selecting "Allow
Internet
sites to uniquely identify your player".
- In Windows Media Player 7.1, the privacy setting is toggled via
the
existing option under the tools menu, on the player tab and deselect
the option "Allow Internet sites to uniquely identify your player".
Although we typically do not discuss privacy issues in security
bulletins, the privacy issue in this case is eliminated by applying
the
patch and then selecting the new user settings as described above. We
have provided this information because the best way to make the
privacy
update available to customers was by including it in this patch, and
because we wanted to provide users who installed the patch with
information about how to use the new privacy settings.
- The attacker would need the ability to entice the user into either
visiting a web site she controlled, or opening an HTML e-mail she had
prepared.
- The attacker would need to know the specific operating system that
the user was running in order to tailor the attack code properly; if
the attacker made an incorrect guess about the user's operating
system
platform, the attack would crash the user's application, but not run
code of the attacker's choice.
Internet shortcut vulnerability:
- On Windows NT 4.0 and Windows 2000 systems, the location of the
Temporary Files folder varies from user to user. In order to exploit
the vulnerability on these systems, the attacker would need to know
the
exact location of the Temporary Files folder on the specific system
she
wished to attack.
- The attacker would need to know the exact name of each file she
wished to read.
- The attacker could only view file types that can be opened in a
browser window. These include.txt, .jpg, .gif, or .htm , but not file
types such as .exe, .doc, and .xls.
- There is no capability to add, delete or changes files via this
vulnerability.
Patch Availability:
===================
- A patch is available to fix this vulnerability. Please read the
Security Bulletin
http://www.microsoft.com/technet/security/bulletin/ms01-029.asp
for information on obtaining this patch.
socalgal
05-26-2001, 12:36 AM
The following is a Security Bulletin from the Microsoft Product Security
Notification Service.
Please do not reply to this message, as it was sent from an unattended
mailbox.
********************************
-----BEGIN PGP SIGNED MESSAGE-----
- ----------------------------------------------------------------------
- -
Title: HyperTerminal Buffer Overflow Vulnerability
Released: 18 October 2000
Revised: 24 May 2001 (version 2.0)
Software: HyperTerminal on Windows 98, 98SE, Windows ME,
Windows NT 4.0, Windows 2000
Impact: Privilege Elevation
Bulletin: MS00-079
Microsoft encourages customers to review the Security Bulletin at: http://www.microsoft.com/technet/security/bulletin/MS00-079.asp
- ----------------------------------------------------------------------
- -
Reason for Revision:
====================
Microsoft has re-released this bulletin to inform customers of the
availability of an updated set of patches to address both the
original and a second vulnerability identified in HyperTerminal.
Information about the second issue is discussed in the Issue section
below and in the security bulletin referenced above.
Issue:
======
The HyperTerminal application is a communications utility that
installs by default on all versions of Windows 98, 98SE, Windows ME,
Windows NT 4.0, and Windows 2000. The product contains two unchecked
buffers through which an attacker could potentially cause code of her
choice to run on another user's machine:
- One resides in a section of the code that processes Telnet URLs.
If a user opened an HTML mail that contained a particular type of
malformed Telnet URL, and HyperTerminal were configured as the
default Telnet client, it would trigger the buffer overrun.
HyperTerminal is the default Telnet client on Windows 98, 98SE and
ME. It is not the default Telnet client on Windows 2000.
- The other resides in a section of the code that processes session
files - files that enable HyperTerminal users to specify session
parameters such as the connection method and the destination host. If
a user opened a session file that contained a particular type of
malformed information, it would trigger the buffer overrun.
Although HyperTerminal ships as part of several Microsoft products,
it was developed by a third party. Additional information on the
vulnerability and a patch for their full version product,
HyperTerminal Private Edition, is available from their web site at www.hilgraeve.com (http://www.hilgraeve.com)
Mitigating Factors:
====================
The malicious user must entice another user into clicking on a
specially-formed telnet URL or opening a malformed HyperTerminal
session file.
Patch Availability:
===================
- A patch is available to fix this vulnerability. Please read the
Security Bulletin
http://www.microsoft.com/technet/security/bulletin/ms00-079.asp
for information on obtaining this patch.
[This message has been edited by socalgal (edited 05-25-2001).]
socalgal
06-06-2001, 09:17 PM
The following is a Security Bulletin from the Microsoft Product Security
Notification Service.
Please do not reply to this message, as it was sent from an unattended
mailbox.
********************************
-----BEGIN PGP SIGNED MESSAGE-----
- ----------------------------------------------------------------------
Title: Incorrect Attachment Handling in Exchange 2000 OWA
Can Execute Script
Date: 06 June 2001
Software: Microsoft Exchange 2000 Server Outlook Web Access
Impact: Run code of attacker's choice
Bulletin: MS01-030
Microsoft encourages customers to review the Security Bulletin at: http://www.microsoft.com/technet/security/bulletin/MS01-030.asp
- ----------------------------------------------------------------------
Issue:
======
OWA is a service of Exchange 2000 Server that allows users to use a
web
browser to access their Exchange mailbox. However, a flaw exists in
the
interaction between OWA and IE for message attachments. If an
attachment contains HTML code including script, the script will be
executed when the attachment is opened, regardless of the attachment
type. Because OWA requires that scripting be enabled in the zone
where
the OWA server is located, this script could take action against the
user's Exchange mailbox.
An attacker could use this flaw to construct an attachment containing
malicious script code. The attacker could then send the attachment in
a
message to the user. If the user opened the attachment in OWA, the
script would execute and could take action against the user's mailbox
as if it were the user, including, under certain circumstances,
manipulation of messages or folders.
Mitigating Factors:
====================
- The vulnerability could only be exploited if the user were
using OWA in conjunction with IE.
- The vulnerability is only exploitable by attachments that
are received via OWA. In general, an attacker would have
no way to determine whether a user would open an
attachment using OWA rather than an Outlook client.
- An attacker's ability to exploit this vulnerability would
require that she entice the user to open an attachment
from an untrusted source. Best practices recommend against
opening any attachment from an unknown or untrusted source.
Patch Availability:
===================
- A patch is available to fix this vulnerability. Please read the
Security Bulletin
http://www.microsoft.com/technet/security/bulletin/ms01-030.asp
for information on obtaining this patch.
The following is a Security Bulletin from the Microsoft Product Security
Notification Service.
Please do not reply to this message, as it was sent from an unattended
mailbox.
********************************
-----BEGIN PGP SIGNED MESSAGE-----
- ---------------------------------------------------------------------
Title: Predictable Name Pipes Could Enable Privilege Elevation
via Telnet
Date: 07 June 2001
Software: Windows 2000
Impact: Privilege elevation, denial of service,
information disclosure
Bulletin: MS01-031
Microsoft encourages customers to review the Security Bulletin at: http://www.microsoft.com/technet/security/bulletin/MS01-031.asp
- ---------------------------------------------------------------------
Issue:
======
This bulletin discusses a total of seven vulnerabilities affecting
the Windows 2000 Telnet service. The vulnerabilities fall into three
broad categories: privilege elevation, denial of service and
information disclosure.
Two of the vulnerabilities could allow privilege elevation, and have
their roots in flaws related to the way Telnet sessions are created.
When a new Telnet session is established, the service creates a named
pipe, and runs any code associated with it as part of the
initialization process. However, the pipe's name is predictable, and
if Telnet finds an existing pipe with that name, it simply uses it.
An attacker who had the ability to load and run code on the server
could create the pipe and associate a program with it, and the Telnet
service would run the code in Local System context when it stablished
the next Telnet session.
Four of the vulnerabilities could allow denial of service attacks.
None of these vulnerabilities have anything in common with each
other.
- One occurs because it is possible to prevent Telnet from
terminating idle sessions; by creating a sufficient number of such
sessions, an attacker could deny sessions to any other user.
- One occurs because of a handle leak when a Telnet session is
terminated in a certain way. By repeatedly starting sessions and then
terminating them, an attacker could deplete the supply of handles on
the server to point where it could no longer perform useful work.
- One occurs because a logon command containing a particular
malformation causes an access violation in the Telnet service.
- One occurs because a system call can be made using only normal
user privileges, which has the effect of terminating a Telnet
session.
The final vulnerability is an information disclosure vulnerability
that could make it easier for an attacker to find Guest accounts
exposed via the Telnet server. It has exactly the same cause, scope
and effect as a vulnerability affecting FTP and discussed in
Microsoft Security Bulletin MS01-026.
- Because the attacker would need the ability to load and run code
on the Telnet server, it is likely that these vulnerabilities could
only be exploited by an attacker who had the ability to run code
locally on the Telnet Server.
- Administrative privileges are needed to start the Telnet service,
so the attacker could only exploit the vulnerability if Telnet were
already started on the machine.
Denial of service vulnerabilities:
- It would not be necessary to reboot the server to recover from any
of these vulnerabilities. At worst, the Telnet service would need to
be restarted.
- None of these vulnerabilities could be used to gain additional
privileges on the machine; they are denial of service vulnerabilities
only.
Information disclosure vulnerability:
- The vulnerability could only be exploited if the Guest account on
the local machine was disabled, but the Guest account on a trusted
domain was enabled. By default, the Guest account is disabled.
Patch Availability:
===================
- A patch is available to fix this vulnerability. Please read the
Security Bulletin
http://www.microsoft.com/technet/security/bulletin/ms01-031.asp
for information on obtaining this patch.
Acknowledgment:
===============
- Guardent (www.guardent.com) for reporting the two privilege
elevation vulnerabilities and one of the denial of service
vulnerabilities.
- Richard Reiner of Securexpert (www.securexpert.com) for reporting
one of the denial of service vulnerabilities.
- Bindview's Razor Team (razor.bindview.com) for reporting one of
the denial of service vulnerabilities.
- Peter Grundl for reporting one of the denial of service
vulnerabilities.
socalgal
06-09-2001, 06:43 AM
The following is a Security Bulletin from the Microsoft Product Security
Notification Service.
Please do not reply to this message, as it was sent from an unattended
mailbox.
********************************
-----BEGIN PGP SIGNED MESSAGE-----
- ----------------------------------------------------------------------
Title: Incorrect Attachment Handling in Exchange OWA Can
Execute Script
Released: 06 June 2001
Revised: 08 June 2001 (version 2.0)
Software: Exchange 5.5, Exchange 2000
Impact: Run code of attacker's choice on mail client
Bulletin: MS01-030
Microsoft encourages customers to review the Security Bulletin at: http://www.microsoft.com/technet/security/bulletin/MS01-030.asp
- ----------------------------------------------------------------------
Reason for Revision:
====================
- Exchange 5.5 has been determined to be affected by the
vulnerability. We have developed an Exchange 5.5 patch.
- The originally released Exchange 2000 patch has been determined
to contain a regression error that can cause performance
problems on the servers it is installed on. We have eliminated
the regression error and updated the patch; we recommend that
customers who installed the original patch install the updated
one.
Issue:
======
OWA is a service of Exchange Server that allows users to use a web
browser to access their Exchange mailbox. However, a flaw exists in
the
interaction between OWA and IE for message attachments. If an
attachment contains HTML code including script, the script will be
executed when the attachment is opened, regardless of the attachment
type. Because OWA requires that scripting be enabled in the zone
where
the OWA server is located, this script could take action against the
user's Exchange mailbox.
An attacker could use this flaw to construct an attachment containing
malicious script code. The attacker could then send the attachment in
a
message to the user. If the user opened the attachment in OWA, the
script would execute and could take action against the user's mailbox
as if it were the user, including, under certain circumstances,
manipulation of messages or folders.
Mitigating Factors:
====================
- The vulnerability could only be exploited if the user were
using OWA in conjunction with IE.
- The vulnerability is only exploitable by attachments that
are received via OWA. In general, an attacker would have no
way to determine whether a user would open an attachment
using OWA rather than an Outlook client.
- An attacker's ability to exploit this vulnerability would
require that she entice the user to open an attachment from
an untrusted source. Best practices recommend against opening
any attachment from an unknown or untrusted source.
Patch Availability:
===================
- A patch is available to fix this vulnerability. Please read the
Security Bulletin
http://www.microsoft.com/technet/security/bulletin/ms01-030.asp
for information on obtaining this patch.
The following is a Security Bulletin from the Microsoft Product Security
Notification Service.
Please do not reply to this message, as it was sent from an unattended
mailbox.
********************************
-----BEGIN PGP SIGNED MESSAGE-----
- ----------------------------------------------------------------------
Title: SQL Query Method Enables Cached Administrator Connection
to be Reused
Date: 12 June 2001
Software: Microsoft SQL Server 2000 and SQL Server 7.0
Impact: Privilege elevation
Bulletin: MS01-032
Microsoft encourages customers to review the Security Bulletin at: http://www.microsoft.com/technet/security/bulletin/MS01-032.asp
- ----------------------------------------------------------------------
Issue:
======
When a client connection to a SQL Server is terminated, it remains
cached for a short period of time for performance reasons. One SQL
query method contains a flaw that has the effect of making it
possible for one user's query to reuse a cached connection that
belonged to the sa account.
Exploiting this vulnerability would enable an attacker to execute the
query using the administrator's security context. This would give
her the ability to take any desired action on the database;
moreover, it would give her the ability to run extended stored
procedures, thereby giving her the opportunity to run code of her
choice and assume
de facto control of the server itself.
Mitigating Factors:
====================
- The vulnerability only affects servers configured to use Mixed
Mode.
Microsoft strongly recommends against using Mixed Mode, and
recommends using Windows Authentication mode instead. Customers
who
have configured their servers to use Windows Authentication mode
are not affected by this vulnerability.
- Terminated connections are only cached for a short period. The
attacker would need to time her attack in order to occur during
the
period when an administrator's connection was in the cache.
- The query method at issue here can only be executed by an
authenticated user. Not only would this limit the number of users
who could exploit the vulnerability, it also would allow the
action
to be audited.
Patch Availability:
===================
- A patch is available to fix this vulnerability. Please read the
Security Bulletin
http://www.microsoft.com/technet/security/bulletin/ms01-032.asp
for information on obtaining this patch.
socalgal
06-13-2001, 03:40 PM
The following is a Security Bulletin from the Microsoft Product Security
Notification Service.
Please do not reply to this message, as it was sent from an unattended
mailbox.
********************************
-----BEGIN PGP SIGNED MESSAGE-----
- ----------------------------------------------------------------------
Title: Incorrect Attachment Handling in Exchange OWA Can
Execute Script
Date: 06 June 2001
Revised: 13 June 2001 (version 3.0)
Software: Exchange 5.5, Exchange 2000
Impact: Run code of attacker's choice on mail client
Bulletin: MS01-030
Microsoft encourages customers to review the Security Bulletin at: http://www.microsoft.com/technet/security/bulletin/MS01-030.asp
- ----------------------------------------------------------------------
Reason for Revision:
====================
On June 12, 2001 Microsoft discovered that the updated Exchange 2000
patch contained outdated files. We have corrected the error and
provided an updated version of this patch for Exchange 2000. We
recommend that all customers who have downloaded the Exchange 2000
patch prior to June 12, 2001 install the updated version.
Issue:
======
OWA is a service of Exchange Server that allows users to use a web
browser to access their Exchange mailbox. However, a flaw exists in
the
interaction between OWA and IE for message attachments. If an
attachment contains HTML code including script, the script will be
executed when the attachment is opened, regardless of the attachment
type. Because OWA requires that scripting be enabled in the zone
where
the OWA server is located, this script could take action against the
user's Exchange mailbox.
An attacker could use this flaw to construct an attachment containing
malicious script code. The attacker could then send the attachment in
a
message to the user. If the user opened the attachment in OWA, the
script would execute and could take action against the user's mailbox
as if it were the user, including, under certain circumstances,
manipulation of messages or folders.
Mitigating Factors:
====================
- - The vulnerability could only be exploited if the user were
using OWA in conjunction with IE.
- The vulnerability is only exploitable by attachments that
are received via OWA. In general, an attacker would have no
way to determine whether a user would open an attachment
using OWA rather than an Outlook client.
- An attacker's ability to exploit this vulnerability would
require that she entice the user to open an attachment from
an untrusted source. Best practices recommend against opening
any attachment from an unknown or untrusted source.
Patch Availability:
===================
- - A patch is available to fix this vulnerability. Please read the
Security Bulletin
http://www.microsoft.com/technet/security/bulletin/ms01-030.asp
for information on obtaining this patch.
That is one long thread!! Let me be the first to thank you for the heads up http://www.sysopt.com/forum/wink.gif
socalgal
06-22-2001, 09:34 AM
Thanks, Mike http://www.sysopt.com/forum/smile.gif
+++++++++++++++++++++++++++++++++++++
The following is a Security Bulletin from the Microsoft Product Security
Notification Service.
Please do not reply to this message, as it was sent from an unattended
mailbox.
********************************
-----BEGIN PGP SIGNED MESSAGE-----
- ----------------------------------------------------------------------
Title: Malformed Word Document Could Enable Macro to
Run Automatically
Date: 21 June 2001
Software: Word
Impact: Run macro without warning
Bulletin: MS01-034
Microsoft encourages customers to review the Security Bulletin at: http://www.microsoft.com/technet/security/bulletin/MS01-034.asp
- ----------------------------------------------------------------------
Issue:
======
Word, like other members of the Office product family, provides a security mechanism that requires the user's approval to run macros.
By design, any time a document is opened Word scans it for macros. If any are found, they are handled in accordance with user's selected security settings. By default in Word 2000 and 2002, only macros that are
signed by a trusted party are enabled; all others are disabled. In Word 97,
if the document contains macros, the user is prompted regarding whether to enable them or disable them.
A vulnerability results because it is possible to modify a Word document in such a way as to prevent the security scanner from
recognizing an embedded macro while still allowing it to execute.
Exploiting the vulnerability would enable an attacker to cause a macro to run automatically when such a document was opened. Such a macro would be able to take any action that the user herself could take.
This could include disabling the user's Word security settings so that subsequently-opened Word documents would no longer be checked for macros.
Mitigating Factors:
====================
- The vulnerability only affects Word. Other Office products
are not affected.
- Customers using the Outlook E-mail Security Update
(which is included as part of Word 2002) will be protected
from any worm viruses contained in Word documents.
Patch Availability:
===================
- A patch is available to fix this vulnerability. Please read the
Security Bulletin
http://www.microsoft.com/technet/security/bulletin/ms01-034.asp
for information on obtaining this patch.
Acknowledgment:
===============
- Steven McLeod (stevenmcleod@hotmail.com)
socalgal
06-22-2001, 11:07 AM
The following is a Security Bulletin from the Microsoft Product Security
Notification Service.
Please do not reply to this message, as it was sent from an unattended
mailbox.
********************************
-----BEGIN PGP SIGNED MESSAGE-----
- ----------------------------------------------------------------------
Title: FrontPage Server Extension Sub-Component Contains
Unchecked Buffer
Date: 21 June 2001
Software: Microsoft Visual Studio RAD Support in FrontPage
Server Extensions
Impact: Run code of attacker's choice
ulletin: MS01-035
Microsoft encourages customers to review the Security Bulletin at: http://www.microsoft.com/technet/security/bulletin/MS01-035.asp
- ----------------------------------------------------------------------
Issue:
======
FrontPage Server Extensions ship as part of IIS 4.0 and 5.0, and
facilitate the development of
Web sites and Web-based applications. FrontPage Server Extensions
includes an additional,
optional sub-component called Visual Studio RAD (Remote Application
Deployment) Support.
This sub-component allows Visual InterDev 6.0 users to register and
unregister COM objects on
an IIS 4.0 or 5.0 Server. This sub-component contains an unchecked
buffer in a section that
processes input information.
An attacker could exploit this vulnerability against any server with
this sub-component installed by
establishing a web session on with the server and passing a specially
malformed packet to the
server component. The attacker could use that packet to thereby load
code of his choice for
execution on the server. An attack that exploits this vulnerability
would execute in the
IUSR_machinename context (see Q142868). However, it is possible under
certain circumstances
to execute code in the SYSTEM context.
It is important to note that this feature is not installed by default
with FPSE. It is also not installed
by default on either of IIS 4.0 or 5.0. Also, when the feature is
selected during installation, a
warning message is raised alerting the administrator that this
feature should not be installed on
production machines, especially if the production machine has
Internet access. This is because
this feature is only intended for facilitating internal development.
The administrator must
acknowledge the warning to successfully install the feature.
Mitigating Factors:
====================
- While FrontPage Server Extensions installs by default with IIS,
Visual Studio RAD Deployment Support coordination is not
provided with FPSE by default on an initial installation of
IIS. Installation must be selected and approved by the user
in charge of the server using the IIS setup process. If a user
selects this sub-component during an initial installation, a
warning is raised stating that this should not be installed
on a production system. Users must actively acknowledge this
warning to complete the installation.
Patch Availability:
===================
- A patch is available to fix this vulnerability. Please read the
Security Bulletin
http://www.microsoft.com/technet/security/bulletin/ms01-035.asp
for information on obtaining this patch.
The following is a Security Bulletin from the Microsoft Product Security
Notification Service.
Please do not reply to this message, as it was sent from an unattended
mailbox.
********************************
-----BEGIN PGP SIGNED MESSAGE-----
- ----------------------------------------------------------------------
Title: Patch Available for "NetMeeting Desktop Sharing"
Vulnerability
Released: 13 October 2000
Revised: 21 June 2001 (version 2.0)
Software: Netmeeting
Impact: Denial of service
Bulletin: MS00-077
Microsoft encourages customers to review the Security Bulletin at: http://www.microsoft.com/technet/security/bulletin/MS00-077.asp
- ----------------------------------------------------------------------
Reason for Revision:
====================
A new variant of the originally reported vulnerability has been
found.
The patch has been updated to address both the original and new
variants.
Issue:
======
A remote denial of service vulnerability has been discovered in a
component of Microsoft(r) NetMeeting. The denial of service can occur
when a malicious client sends a particular malformed string to a port
which the NetMeeting service is listening on and with Remote Desktop
Sharing enabled.
Although the NetMeeting application is provided as part of Windows(r)
2000 products, the application and affected component is not enabled
by
default, and customers who have not enabled it would not be at risk
from this vulnerability.
Mitigating Factors:
====================
- NetMeeting is not enabled by default on either Windows 2000 or
Windows NT(r) 4.0.
- The vulnerability could not be used for any broader attack - that
is, it could not be used to compromise data within a Netmeeting
session
or usurp administrative control of a remote desktop session.
Patch Availability:
===================
- A patch is available to fix this vulnerability. Please read the
Security Bulletin
http://www.microsoft.com/technet/security/bulletin/ms00-077.asp
for information on obtaining this patch.
Acknowledgment:
===============
- Peter Grundl
socalgal
06-26-2001, 09:12 AM
The following is a Security Bulletin from the Microsoft Product Security
Notification Service.
Please do not reply to this message, as it was sent from an unattended
mailbox.
********************************
-----BEGIN PGP SIGNED MESSAGE-----
- ----------------------------------------------------------------------
Title: Function Exposed via LDAP over SSL Could Enable
Passwords to be Changed
Date: 25 June 2001
Software: Windows 2000
Impact: Privilege Elevation
Bulletin: MS01-036
Microsoft encourages customers to review the Security Bulletin at: http://www.microsoft.com/technet/security/bulletin/MS01-036.asp
- ----------------------------------------------------------------------
Issue:
======
This vulnerability involves an LDAP function that is only available
if
the LDAP server has been configured to support LDAP over SSL
sessions,
and whose purpose is to allow users to change the data attributes of
directory principals. By design, the function should check the
authorizations of the user before completing the request; however, it
contains an error that manifests itself only when the directory
principal is a domain user and the data attribute is the domain
password -- when this is the case, the function fails to check the
permissions of the requester, with the result that it could be
possible
for a user to change any other user's domain login password.
An attacker could change another user's password for either of two
purposes: to cause a denial of service by preventing the other user
from logging on, or in order to log into the user's account and gain
any privileges the user had. Clearly, the most serious case would be
one in which the attacker changed a domain administrator's password
and
logged into the administrator's account.
By design, the function affected can be called by any user who can
connect to the LDAP server, including users who connect via anonymous
sessions. As a result, any user who could establish a connection with
an affected server could exploit the vulnerability.
Mitigating Factors:
====================
- LDAP over SSL sessions cannot be conducted unless the
administrator has installed a digital certificate on the LDAP
server. As a result, default installations of Windows 2000
are not affected by this vulnerability.
- If the firewall is configured to block tcp port 636, the
vulnerability could not be exploited by outside users.
- This vulnerability could not be used to change the password
of local user accounts on individual machines.
Patch Availability:
===================
- A patch is available to fix this vulnerability. Please read the
Security Bulletin
http://www.microsoft.com/technet/security/bulletin/ms01-036.asp
for information on obtaining this patch.
Acknowledgment:
===============
- Jon McDonald ( http://www.entrigue.net )
- Russ Cooper ( http://www.ntbugtraq.com )
socalgal
07-05-2001, 10:06 PM
The following is a Security Bulletin from the Microsoft Product Security
Notification Service.
Please do not reply to this message, as it was sent from an unattended
mailbox.
********************************
-----BEGIN PGP SIGNED MESSAGE-----
- -
- ----------------------------------------------------------------------
Title: Authentication Error in SMTP Service Could Allow Mail
Relaying
Date: 05 July, 2001
Software: Windows 2000
Impact: Mail Relaying
Bulletin: MS01-037
Microsoft encourages customers to review the Security Bulletin at: http://www.microsoft.com/technet/security/bulletin/MS01-037.asp
- -
- ----------------------------------------------------------------------
Issue:
======
An SMTP service installs by default as part of Windows 2000 server
products, and can be selected for installation on Windows 2000
Professional. A vulnerability results because of a flaw in the
authentication process used by the service. The vulnerability could
allow an unauthorized user to successfully authenticate to the
service using incorrect credentials. An attacker who exploited
the vulnerability could gain user-level privileges on the SMTP
service, thereby enabling the attacker to use the service but
not to administer it. The most likely purpose in exploiting the
vulnerability would be to perform mail relaying via the server.
Mitigating Factors:
====================
- Exchange servers -- even when run on Windows 2000 --
are not affected by this vulnerability.
- Best practices recommend disabling unneeded services.
If the SMTP service has been disabled, the
vulnerability could not be exploited.
- The vulnerability only affects stand-alone machines,
not domain members.
- Proper firewalling could prevent Internet-based attacks
by blocking port 25 on servers that do not specifically
need to accept SMTP traffic.
Patch Availability:
===================
- A patch is available to fix this vulnerability. Please read
the Security Bulletin
http://www.microsoft.com/technet/security/bulletin/ms01-037.asp
for information on obtaining this patch.
The following is a Security Bulletin from the Microsoft Product Security
Notification Service.
Please do not reply to this message, as it was sent from an unattended
mailbox.
********************************
-----BEGIN PGP SIGNED MESSAGE-----
- ----------------------------------------------------------------------
Title: Outlook View Control Exposes Unsafe Functionality
Date: 12 July 2001
Software: Outlook 98, 2000, and 2002
Impact: Run code of attacker's choice via either web page or HTML
e-mail.
Bulletin: MS01-038
Microsoft encourages customers to review the Security Bulletin at: http://www.microsoft.com/technet/security/bulletin/MS01-038.asp
- ----------------------------------------------------------------------
Issue:
======
The Microsoft Outlook View Control is an ActiveX control that allows
Outlook mail folders to be viewed via web pages. The control should
only allow passive operations such as viewing mail or calendar data.
In reality, though, it exposes a function that could allow the web
page to manipulate Outlook data. This could enable an attacker to
delete mail, change calendar information, or take virtually any other
action through Outlook including running arbitrary code on the user's
machine.
Hostile web sites would pose the greatest threat with respect to this
vulnerability. If a user could be enticed into visiting a web page
controlled by an attacker, script or HTML on the page could invoke
the control when the page was opened. The script or HTML could then
use the control to take whatever action the attacker desired on the
user's Outlook data.
It also would be possible for the attacker to send an HTML e-mail to
a user, with the intent of invoking the control when the recipient
opened the mail. However, the Outlook E-mail Security Update, that
automatically installs as part of Outlook 2002 would thwart such an
attack. The Update causes HTML e-mails to be opened in the Restricted
Sites Zone, where ActiveX controls are disabled by default.
Microsoft is preparing a patch that will eliminate the vulnerability.
However, while this patch is under development, we recommend that
customers disable ActiveX controls in the Internet Zone to protect
against the web-based scenario discussed above. (The FAQ provides
information on how administrators can use Group Policy to make this
configuration change network-wide). To protect against the mail-borne
scenario, we strongly recommend that Outlook 98 and 2000 users
install the Outlook E-mail Security Update if they haven't already
done so. When the patch is complete, Microsoft will re-release this
bulletin and provide details on where to obtain the patch and how to
use it.
Mitigating Factors:
====================
- The previously-released Outlook E-mail Security Update that is
integrated into Outlook 2002 would prevent this vulnerability from
being exploited via e-mail in all affected Outlook versions.
- The vulnerability provides no capability for the attacker to force
a
user to visit a web page that exploits it.
Patch Availability:
===================
- A patch is available to fix this vulnerability. Please read the
Security Bulletin
http://www.microsoft.com/technet/security/bulletin/ms01-038.asp
for information on obtaining this patch.
socalgal
07-24-2001, 03:05 PM
The following is a Security Bulletin from the Microsoft Product Security
Notification Service.
Please do not reply to this message, as it was sent from an unattended
mailbox.
********************************
-----BEGIN PGP SIGNED MESSAGE-----
- ----------------------------------------------------------------------
Title: Services for Unix 2.0 Telnet and NFS Services Contain
Memory Leaks
Date: 23 July 2001
Software: Services for Unix 2.0
Impact: Denial of service
Bulletin: MS01-039
Microsoft encourages customers to review the Security Bulletin at: http://www.microsoft.com/technet/security/bulletin/MS01-039.asp.
- ----------------------------------------------------------------------
Issue:
======
Among the components provided by Services for Unix (SFU) 2.0 are
services that implement the NFS (Network File System) and Telnet
protocols. Both services contain memory leaks that could be triggered
by a user request. An attacker who repeatedly sent such a request
could
deplete the kernel memory on the server to the point where
performance
slowed and the system could potentially fail.
Mitigating Factors:
====================
- Only the implementations provided in SFU 2.0 are affected.
In particular, the Telnet services provided in Windows NT(r) 4.0
and Windows(r) 2000 are not affected by the vulnerability.
- There is no capability via the vulnerability to usurp any
administrative control over the server or compromise any
data on it.
Patch Availability:
===================
- A patch is available to fix this vulnerability. Please read the
Security Bulletin
http://www.microsoft.com/technet/security/bulletin/ms01-039.asp
for information on obtaining this patch.
Acknowledgment:
===============
- Peter Grundl
socalgal
07-25-2001, 10:27 PM
The following is a Security Bulletin from the Microsoft Product Security
Notification Service.
Please do not reply to this message, as it was sent from an unattended
mailbox.
********************************
-----BEGIN PGP SIGNED MESSAGE-----
- ----------------------------------------------------------------------
Title: Invalid RDP Data Can Cause Memory Leak in Terminal
Services
Date: 25 July 2001
Software: Windows 2000 Server and Windows NT 4.0, Terminal Server
Edition
Impact: Denial of Service
Bulletin: MS01-040
Microsoft encourages customers to review the Security Bulletin at: http://www.microsoft.com/technet/security/bulletin/MS01-040.asp
- ----------------------------------------------------------------------
Issue:
======
The Windows 2000 Terminal Service and Windows NT 4.0 Terminal Server
Edition contains a memory leak in one of the functions that processes
incoming Remote Data Protocol data via port 3389. Each time an RDP
packet containing a specific type of malformation is processed, the
memory leak depletes overall server memory by a small amount.
If an attacker sent a sufficiently large quantity of such data to an
affected machine, he could deplete the machine's memory to the point
where response time would be slowed or the machine's ability to respond would be stopped altogether. All system services would be affected, including but not limited to terminal services. Normal operation could
be restored by rebooting the machine.
Mitigating Factors:
====================
- Normal firewalling could be used to prevent an attacker from exploiting this vulnerability from the Internet. Specifically, blocking port 3389 would prevent an attacker from delivering data to the affected service, thereby preventing him from exploiting the vulnerability.
- There is no capability to compromise data or usurp privileges via the vulnerability.
Patch Availability:
===================
- A patch is available to fix this vulnerability. Please read the
Security Bulletin
http://www.microsoft.com/technet/security/bulletin/ms01-040.asp
for information on obtaining this patch.
Acknowledgment:
===============
- Peter Grundl
socalgal
07-26-2001, 07:20 PM
Continued at MS Security Bulletins - Vol. 12 (http://www.sysopt.com/forum/Forum1/HTML/015083.html)
[This message has been edited by socalgal (edited 07-26-2001).]
SysOpt.com
Copyright Internet.com Inc. All Rights Reserved.