*~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~*
{ Sila lawat Laman Hizbi-Net - http://www.hizbi.net }
{ Hantarkan mesej anda ke: [EMAIL PROTECTED] }
{ Iklan barangan? Hantarkan ke [EMAIL PROTECTED] }
*~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~*
PAS : KE ARAH PEMERINTAHAN ISLAM YANG ADIL
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Assalamualaikum,
Outlook, satu mimpi ngeri
untuk System Admin.
Pastikan update patches.
Wassalam.
: )
-------- Original Message --------
Subject: [NT] Outlook "Cache Bypass" vulnerability (Patch available)
Date: Tue, 25 Jul 2000 23:37:54 +0800
From: [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
The following security advisory is sent to the securiteam mailing list, and
can be found at the SecuriTeam web site: http://www.securiteam.com
Outlook "Cache Bypass" vulnerability (Patch available)
--------------------------------------------------------------------------------
SUMMARY
Microsoft has released a patch that eliminates a security vulnerability in
Microsoft Outlook and Outlook Express. The vulnerability allows a
malicious user to send an HTML mail that, when opened, could read files on
the recipient's computer. If coupled with other vulnerabilities, it could
potentially be used in more advanced attacks as well.
The patch eliminates this vulnerability as well as those discussed in
Microsoft Security Bulletins MS00-043 and MS00-045. Customers who already
have taken the corrective action discussed in either of these bulletins do
not need to take any additional action.
DETAILS
Affected Software Versions:
- Microsoft Outlook Express 4.0
- Microsoft Outlook Express 4.01
- Microsoft Outlook Express 5.0
- Microsoft Outlook Express 5.01
- Microsoft Outlook 97
- Microsoft Outlook 98
- Microsoft Outlook 2000
By design, an HTML mail that creates a file on the recipient's computer
should only be able to create it in the so-called cache. Files in the
cache, when opened, do so in the Internet Zone. However, this
vulnerability would allow an HTML mail to bypass the cache mechanism and
create a file in a known location on the recipient's disk. If an HTML mail
created an HTML file outside the cache, it would run in the Local Computer
Zone when opened. This could allow it to open a file on the user's
computer and send it a malicious user's web site. The vulnerability also
could be used as a way of placing an executable file on the user's
machine, which the malicious user would then seek to launch via some other
means.
The vulnerability would not enable the malicious user to add, change or
delete files on the user's computer. Only files that can be opened in a
browser window, such as .txt, .jpg or .htm files, could be read via this
vulnerability, and the malicious user would need to know or guess the full
path and file name of every file he wished to read.
The vulnerability resides in a component that is shared by Outlook and
Outlook Express, and as a result the vulnerability affects both products.
A version of the component that is not affected by the vulnerability ships
as part of Outlook Express 5.5, and customers who have installed it do not
need to take any additional action. Outlook Express 5.5 is available as
part of Internet Explorer 5.01 Service Pack 1, and, except when installed
on Windows 2000, Internet Explorer 5.5.
Patch Availability:
This vulnerability can be eliminated by taking any of the following
actions:
- Installing the patch available at
<http://www.microsoft.com/windows/ie/download/critical/patch9.htm>
http://www.microsoft.com/windows/ie/download/critical/patch9.htm
- Performing a default installation of Internet Explorer 5.01 Service
Pack 1,
<http://www.microsoft.com/Windows/ie/download/ie501sp1.htm>
http://www.microsoft.com/Windows/ie/download/ie501sp1.htm.
- Performing a default installation of Internet Explorer 5.5
( <http://www.microsoft.com/windows/ie/download/ie55.htm>
http://www.microsoft.com/windows/ie/download/ie55.htm)
on any system except Windows 2000.
Note: The patch requires IE 4.01 SP2
( <http://www.microsoft.com/windows/ie/download/ie401sp2.htm>
http://www.microsoft.com/windows/ie/download/ie401sp2.htm) or IE 5.01 (
<http://www.microsoft.com/windows/ie/download/ie501.htm>
http://www.microsoft.com/windows/ie/download/ie501.htm)
Note: In addition to eliminating the vulnerability at issue here, the
steps above also eliminate all vulnerabilities discussed in Microsoft
Security Bulletins MS00-043 (
<http://www.microsoft.com/technet/security/bulletin/MS00-043.asp>
http://www.microsoft.com/technet/security/bulletin/MS00-043.asp) and
MS00-045 (
<http://www.microsoft.com/technet/security/bulletin/MS00-045.asp>
http://www.microsoft.com/technet/security/bulletin/MS00-045.asp).
Customers who already have taken the corrective action discussed in either
of these bulletins do not need to take any additional action.
What's the scope of the vulnerability?
This vulnerability could allow a malicious user to send an email to
another user that, if opened, would allow the malicious user to read files
on the recipient's computer. The vulnerability would not allow the
malicious user to add, change or delete files, nor would it allow him to
usurp any administrative control over the machine. The malicious user
would need to know the name and location of every file on the user's
computer he wanted to read, and could only read file types that can be
opened in a browser window.
This vulnerability also could assist a malicious user in mounting other,
more serious attacks, because it would allow him to place a file in a
known location on the disk, which he might then seek to launch. However,
the mechanism by which the file could be launched is beyond the scope of
this vulnerability.
What causes the vulnerability?
The vulnerability exists because it's possible via several methods (all
eliminated by the patch) for an HTML mail to create a file that lies
outside the so-called cache.
What's the cache?
The cache is a special set of folders controlled by the Internet Explorer
security architecture. (The IE security architecture handles all HTML
processing, regardless of whether the HTML was received via the web or via
e-mail). When an HTML e-mail needs to create a file on the recipient's
disk, it should, by design, be required to store it in the cache. Because
only the security architecture knows how to retrieve a cached file, this
ensures that the HTML mail will have to work through the security
architecture to access the file, and the security architecture will
therefore always be in a position to control what the file can do.
When you say "create a file", are you referring to downloading attached
files?
No. Attached files don't involve the cache, and don't have anything to do
with this vulnerability. File attachments are always saved wherever the
user - not the HTML mail or the IE security architecture - decides. The
files at issue here are carried inline, within the HTML mail itself. Such
files typically are used to provide formatting information, background
images, animation, etc, for use in displaying the e-mail's text.
Inline data files don't cause a warning dialogue to be displayed when
they're saved to disk. An inline file is typically intended to be used
only by the specific HTML mail that carried it, and even then only
temporarily. Because such files are, by design, always stored in the cache
and constrained by the security architecture, it's considered a safe
operation to download them without a warning dialogue.
How does the cache work?
When an HTML mail needs to store a file, it generates a Globally Unique
Identifier (GUID), assigns it to the file, and then asks the security
architecture to put the file into the cache for it. The security
architecture generates a random name for the file - one that only it knows
- and records the correspondence between the GUID and the random name in
an internal table. When the HTML mail needs to use the file, it requests
it via the GUID, and the security architecture retrieves the file and
opens it after taking appropriate security measures.
What forces an HTML mail to work through the cache?
The HTML mail works through the cache because, by design at least, it
can't save files any other way. If it needs to use an inline file, it must
put it in the cache.
What kind of security measures does the security architecture take when
retrieving a file from the cache?
The most important security measure, at least for the purposes of this
vulnerability, is that the security architecture ensures that any cached
HTML files are opened in the Internet Zone, rather than the Local Computer
Zone. It does this even though the files did in fact come from the user's
local computer. This is appropriate, because the files aren't necessarily
trusted by the user (recall that a warning dialogue isn't displayed when
files are cached), and should be treated the same as any other file from
the Internet.
Can an HTML e-mail open a file that isn't in the cache?
Yes, but only if it knows the file's name and complete path. By design,
only the user can put files onto the disk but outside of the cache -
usually this is done as part of a software installation, but in any case
it's done deliberately. The files are therefore trusted and, when opened
in Internet Explorer, run in the Local Computer Zone.
What's the difference between the Internet Zone and the Local Computer
Zone?
The Local Computer Zone allows a web page to have considerably more
privileges than the Internet Zone. Most important for our purposes, the
Local Computer Zone allows a web page to access files on the user's
computer.
How could a malicious user exploit this vulnerability?
If a malicious user sent an HTML e-mail that exploited this vulnerability,
the e-mail could create an HTML file on the local computer, outside of the
cache. The HTML e-mail could then open the file using Internet Explorer.
The result of these operations would be that there would now be a page
open in Internet Explorer, running in the Local Computer Zone but under
the control of the malicious user's HTML e-mail.
Because the Local Computer Zone allows files on the user's hard drive to
be accessed, the page would be able to open a file, then send its contents
back to the malicious user's web site. It's important to note, however,
that even HTML files running in the Local Computer Zone cannot change, add
or delete files - they can only view them.
What kind of files could be read via this vulnerability?
Only files that could be opened in a browser window could be read. These
include .txt, .jpg, .gif, or .htm files. File types like .exe, .doc, .xls
and others could not be opened in a browser window and therefore could not
be read via this vulnerability.
Could this vulnerability be exploited by a web site rather than an HTML
e-mail?
No. The vulnerability - the ability to bypass the cache mechanism - is
specific to Outlook and Outlook Express, and couldn't be exploited through
Internet Explorer. However, once an HTML e-mail exploited this
vulnerability to write a file outside of the cache, the file could be
opened by a web site that knew of the location of the file.
Does this vulnerability pose any other risk?
Yes. The ability to place a file in a known location on the disk could be
an important step toward a more dangerous attack. If a malicious user
created an HTML mail that exploited this vulnerability to place an
executable file on the recipient's machine, and he had a means of invoking
the executable file, he would have the ability to run code of his choice
on another user's computer. It's worth keeping in mind, though, that this
vulnerability only enables the file to be saved, not launched. A malicious
user would have to combine an attack that exploited this vulnerability
with another attack to actually cause code to run on a recipient's
machine.
Why does this vulnerability affect both Outlook and Outlook Express?
Outlook and Outlook Express both rely on the same system component to
provide the caching mechanism. Applying the patch corrects the problem in
the system component, thereby eliminating the vulnerability in both
products.
How can I tell if I'm affected by the vulnerability?
You are not affected by the vulnerability if any of the following are
true:
* You have performed a default installation Internet Explorer 5.01
Service Pack 1 on your system.
* You have performed a default installation Internet Explorer 5.5 on your
system and your system is not Windows 2000.
* You have installed the patch discussed in either Microsoft Security
Bulletin
<http://www.microsoft.com/technet/security/bulletin/MS00-043.asp> MS00-043
or <http://www.microsoft.com/technet/security/bulletin/MS00-045.asp>
MS00-045.
If none of the above applies to you, you should install the patch.
What's the significance of performing a default installation of IE5.01 SP1
or IE 5.5?
A default installation of these products installs Outlook Express 5.5,
which includes a version of the component that is not affected by the
vulnerability.
Why doesn't IE 5.5 eliminate the problem on Windows 2000?
In the specific case where IE 5.5 is installed on Windows 2000, there
isn't a provision by which to install Outlook Express 5.5, so the
component at issue here isn't updated. Windows 2000 users can eliminate
the vulnerability by either installing IE 5.01 SP1 or applying the patch.
What does the patch do?
The patch closes the loopholes that allow an HTML e-mail to save files to
a known location on the local disk.
How do I use the patch?
Knowledge Base article Q247638 (available soon) contains detailed
instructions for applying the patch to your site
Where can I get the patch?
The download location for the patch is provided in the "Patch
Availability" section of the security bulletin.
How can I tell if I installed the patch correctly?
Knowledge Base article Q247638 (available soon) provides a manifest of the
files in the patch package. The easiest way to verify that you've
installed the patch correctly is to verify that these files are present on
your computer, and have the same sizes and creation dates as shown in the
KB article.
ADDITIONAL INFORMATION
The information has been provided by <mailto:[EMAIL PROTECTED]>
Microsoft Product Security.
========================================
This bulletin is sent to members of the SecuriTeam mailing list.
To unsubscribe from the list, send mail with an empty subject line and body
to: [EMAIL PROTECTED]
In order to subscribe to the mailing list, simply forward this email to:
[EMAIL PROTECTED]
====================
====================
DISCLAIMER:
The information in this bulletin is provided "AS IS" without warranty of any
kind.
In no event shall we be liable for any damages whatsoever including direct,
indirect, incidental, consequential, loss of business profits or special
damages.
--
Senarai kumpulan sokongan komputer dan internet.
Hantarkan email kosong kepada [EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>
http://www.portalsinc.com/hafnie
( Iklan - E-Makalah di http://www.bigfoot.com/~emakalah )
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
( Melanggan ? To : [EMAIL PROTECTED] pada body : SUBSCRIBE HIZB)
( Berhenti ? To : [EMAIL PROTECTED] pada body: UNSUBSCRIBE HIZB)
( Segala pendapat yang dikemukakan tidak menggambarkan )
( pandangan rasmi & bukan tanggungjawab HIZBI-Net )
( Bermasalah? Sila hubungi [EMAIL PROTECTED] )
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Pengirim: "Harisfazillah Jamel" <[EMAIL PROTECTED]>
