What Security
Issues are Known So Far?
Click here for issues
from the year 2003.
The
Princeton
Word Macro Virus Loophole was the first IE security issue that was
discovered. It was first reported on August 22, 1996,
nine days after IE3.0's release. This security problem was discovered by
Ed Felten, an assistant professor at Princeton University, and fellow
researcher Dirk Balfanz. Felton had previously discovered a flaw in
Netscape's Navigator related to malicious java applets. As stated in
the PC Week
article, "The security loophole would allow an attacker to deliver a
document to a visiting computer without the visitor's knowledge. It also
would let an attack site bypass the pop-up box that warns users a file is
about to be transferred."
Felton warned web surfers again in December, 1996 about
the ability of web browsers to be fooled by "spoofed sites." The
full story can be read at
InfoWar.Com,
with related reports at
C|Net
and
ZDNet. The
story was originally reported in The Boston Globe.
The "Cybersnot"
problem is an example of a design flaw that exploits Win95/NT's ability to
launch .URL and .LNK links. IE has a design flaw in it that allows a
programmer to write code in a web page that, when viewed by IE, can launch
a program or an executable capable of causing damage to a computer by
deleting files or by performing some other destructive process. Although
the programmer would have to know the specific name and path of the
program they want to run, some potentially destructive applications, such
as FDISK, FORMAT and DELTREE are located in the same well-known place on
the majority of users' hard drives. People who use Internet Explorer for
Windows 3.1, Windows for Workgroups 3.x, Windows NT 3.51, or Macintosh
computers are NOT affected by the Cybersnot problem (see
http://www.microsoft.com/ie/security/cybersnot.htm).
The "MIT"
problem is another example of an IE design flaw. This design flaw is a
variation of the Cybersnot problem, except that it exploits a different
file type -- .ISP files. Go to (http://www.microsoft.com/ie/security/mit.htm)
for additional information.
Another security flaw was discovered by the University of Maryland.
According to Microsoft, "[T]his problem can potentially affect a
small subset of Internet Explorer users. Users might be at risk if their
corporate firewall or Internet Service Provider (ISP) allows file system
calls to be passed to the Internet. This same scenario is unlikely for
home users who dial into an ISP, or for corporate users accessing the
Internet through a firewall." Basically, this hole allows a
programmer to create a web page containing a framed shortcut to a program
or executable on the web server or a user's hard drive which can then be
executed outside IE's security framework. See
http://www.microsoft.com/ie/security/umd.htm
for information on this. Also, see
http://dec.dorm.umd.edu
for the complete story from the source -- UMD.
It is arguable that the Cybersnot, MIT and UMD problems are not design
flaws at all and could be considered features. There were several postings
on
microsoft.public.inetexplorer.ie3
and
microsoft.public.inetexplorer.ie4
(not to mention many other newsgroups, such as comp.os.ms-windows.advocacy)
from users who had been exploiting the benefits of IE's tight integration
with Windows95 and Windows NT 4.0. Some programmers (particularly
those responsible for intranets) want to keep exploiting these features.
Those that want complete protection can download the security patch from
Microsoft at
http://www.microsoft.com/ie/security/download.htm.
When browsing some sites, Internet Explorer may divulge your password
file. Aaron Spangler at the University of Washington discovered a
way to get password files from Windows95, Windows NT and Windows 98 users
by exploiting the SMB support built into Microsoft's networking client.
Microsoft has acknowledged these issues in Knowledge Base article
Q165403.
Also, see the
note
on their security site. To test your machine, point your browser at
http://www.ee.washington.edu/computing/iebug/.
WARNING: Going to this site MAY cause your password to be transmitted to
this site if you're running Windows 95, Windows 98 or Windows NT. Windows
95 users can also check out
http://www.security.org.il/msnetbreak/.
This site has a demonstration you can run to see if your password
can be transmitted unknowingly over the Internet. Windows NT
Users -- check out
http://www.efsl.com/security/ntie/
for another IE bug that affects NT users. This is similar to the SMB
method, except that it uses NTLM instead. A
patch
that fixes the Windows 95 issue was released by Microsoft on August
26, 1997.
On March 14,
Tea Vui
Huang, an Advanced Applications Engineer for Singapore Cable Vision,
posted information on
a
web site stating that a bug was discovered that can dupe unsuspecting
users into disabling their own security settings in IE, thus leaving the
IE user exposed wide open to hacking. Apparently this can be done using
standard links or Java.
On March 27, it was reported in
Inter@active
Week Online that Internet Explorer is susceptible to what some called
the "biggest security hole yet." This security hole was
discovered by David Klein, a consultant in Pittsburgh. The security
hole is the result of how IE (and other browsers) handle information sent
sites that contain forms. Many of these sites ask for sensitive
information, such as credit card numbers, and the like. The browsers and
the servers exchange the form data in an encrypted format in an effort to
protect it. The problem is that if someone who has just filled out a
secure form clicks on a link to another page, all of the information
entered in to the "secure" form is transferred to the
logs of the link's server. These logs are routinely used to determine what
page the users is coming from. Unfortunately, these logs are often
unprotected, whether or not the rest of the site is protected. Even worse,
all the original information is sent unencrypted. See
Inter@active
Week Online for the full details on this shocking discovery, which
still remains unresolved.
At the end of April, a team Princeton University computer
scientists (led by Ed Felton) discovered a Java security issue that can
allow hackers to gain unauthorized access to the browsing computer by
impersonating a "trusted" software publisher. This was
the same team that discovered the
Princeton
Word Macro Virus Loophole. Note: this issue is related to
Sun's Java Development Kit 1.1.1; because IE doesn't support this kit, it
is unaffected by this security issue.
Did you know that if you use Internet Explorer, someone snooping around
your system can learn quite a bit about you. Here's why:
According to Section 9 of
Bryan
Pfaffenberger's article entitled "10 Ways to Configure Internet
Explorer for the Enterprise User,"
Internet Explorer keeps "an exact
byte-by-byte record of where [you've] been online. This record is stored
in .DAT files located in the Temporary Internet Files folder. Amazingly
enough, these files also include an exact byte transcription of
everything you've uploaded and everything you've downloaded, right back
to the time you installed the program."
Bryan, who by the way is the author of The
Official Microsoft Internet Explorer Book (from
Microsoft
Press), goes on to say:
"Unlike files stored in Internet
Explorer's cache, you can't delete these .DAT files. (Try it -- you'll
be denied access.) By copying these files and inspecting them with a
binary decoder, a knowledgeable intruder could reconstruct your users'
every move going back months, even years. If you're worried about
snooping, the best defense is to install a bulletproof, password-based
authentication program on your users' computers."
Actually, you can delete these files if you
boot your PC into DOS, boot from a DOS floppy, or simply boot into
"Safe Mode Command Prompt Only" in Windows 95. Bryan's
article was featured in the May 1997 issue of
TechNet
(which is an excellent, must have subscription for technical professionals
working with Microsoft products).
On May 8, 1997,
C|Net
reported on another security issue. This security issue is the result
of ActiveX; however, only those IE users who also have PowerPoint (either
'95 or '97) loaded are affected. This security issue is quite severe, as
it allows for links that can execute applications on the browsing
computer, including the deletion of data or uploading of private data. The
problem, which was discovered by Andrew Smith, webmaster for Kaiser
Permanente in Latham, NY. According to Kevin Unagast, an IE product
manager at Microsoft, other browsers, such as Netscape Navigator are also
affected by this issue. Microsoft issued a patch for this problem on
May 9. You can get the patch at
Microsoft's
Security Information and Code Update page for the PowerPoint issue.
June 30, 1997
is the
expiration date for Authenticode for IE users. Microsoft wants IE
users to download Authenticode 2.0 before the end of the month. This
update requires IE 3.02! You need to upgrade to this version before you
can use the Authenticode 2.0 update. According to Microsoft (as
reported by Nick Wingfield at C|Net), "If users
don't download the update by then, their browsers will still work but they
could receive clusters of security warnings every time they visit a Web
site with digitally signed ActiveX controls or Java applets on it."
Remember, Authenticode is Microsoft's technology that attempts to
make it safer for users to download programs over the web using IE.
Authenticode works by scanning the program for a digital certificate which
verifies its authenticity. Microsoft has improved Authenticode somewhat in
version 2.0 (which will be included in IE4), by adding time stamping
support and tracking of revoked certificates. In any event, you should go
and get the
Authenticode
2.0 Update now and avoid the numerous security warnings you're likely
to get.
Internet Explorer does not appear to be
immune to the Year 2000 issue. According to the recent story in
InfoWorld
"Ambiguities in Netscape's JavaScript and in Microsoft's JScript
can create situations where dates after Dec. 31, 1999, may not work
consistently. As an added bonus, dates prior to 1970 can create problems
as well..." The article also goes on to say that IE 3.02 cannot
handle dates before 1970. Read the full article
here.
If you are using date objects in JScript, you'll want to be aware of these
issues, and you may need to start looking for faulty code. Update:
A
Year
2000 patch for IE 3.02 (Win95 and NT 4.0) was released on May
18, 1998.
On July 10, 1997, C|Net
reported
on a JavaScript issue that affects only the Windows 95 and Windows NT
versions of IE 3.02. A researcher at Bell Labs discovered a security hole
that could allow web sites to capture sensitive information such as credit
card and other information. This is a very serious security issue.
CERT, the Computer Emergency Response Team,
issued an
advisory
warning of the hole. CERT recommends that affected users disable
JavaScript. You'll definitely want read
Microsoft's
Q&A document on the Bell Labs issue, too. And when you're finished
reading the details, you might want to download the JavaScript patch.
There are two separate fixes for this issue; be sure to read the details
carefully to make sure you get the version you need. If you have
installed the File Upload Add-On to IE 3.02, then you'll want to get the
patch
here.
If you have not installed the Add-On, then you'll want
this
version of the patch.
On August 9, 1997, Microsoft posted
information regarding a new
"java
mischief" security issue which affects Windows 95, Windows
3.1 and Windows NT 3.51/4.0 users. According to Microsoft, "This
security issue specifically affects the JVM and not the browser."
While this issue cannot harm your PC, it does demonstrate the level of
vulnerability inherent to web browsing--specifically that one web site can
get copies of information you sent or received from another web site
without your knowledge or consent. Of course, as Microsoft points out,
someone would certainly need to know a great deal of information about the
data they wanted to steal, including it's exact path and filename.
However, out of the tens of millions of Windows users out there, there's
bound to be some common files in common locations that could be easily
obtained by a malicious web site. At this time, there is no patch
for this issue for Win95 or WinNT users. Microsoft has
a
suggested workaround until a patch is released.
On August 19, 1997, Microsoft released
a patch for Windows 3.1 users. You can find the 40-bit version
here
or the 128-bit version
here.
On September 2, 1997, it was reported
that a new security hole was discovered. This hole apparently allows a
malicious webmaster to author a page that can corrupt or overwrite files
on the browsing PC. The hole, which was discovered by Tim Macinta at the
Massachusetts
Institute of Technology, exploits the DirectX component that ships
with IE4. Tim reported this to Microsoft only to find out that they were
already aware of it!
Apparently, users of IE3 who have upgraded to
the latest Java virtual machine can be similarly affected. MIT has more
details and a demonstration of the issue on their
web
site. According to MIT, "Microsoft Internet Explorer 3 and
Microsoft Internet Explorer 4 running on Microsoft Windows 95 are both
vulnerable, although not all copies of Internet Explorer 3.0 are
vulnerable. Internet Explorer 3 requires additional components to be
installed for this bug to pose a threat while these components ship
standard with Internet Explorer 4 on Windows 95. Furthermore, several of
these components changed names between the release of IE3 and IE4 so the
same scripts that work in IE4 need some minor modifications to work in IE3
and vice versa, however a web page could easily contain an exploit for
both browsers." The issue is Microsoft's implementation of Java,
and not Java itself. Microsoft has already posted
information
regarding this issue on their web site.
On September 12, 1997,
Microsoft released a temporary patch for Java SDK users which you can find
at
http://www.microsoft.com/ie/security/nodjx.exe.
Microsoft has also posted a workaround at
http://www.microsoft.com/ie/security/directxbeta.htm
which details how to disable Java.
During the end of September/beginning
of October, there was some discussion on the Internet regarding
Channel Definition Format ("CDF") and security. CDF is a
method for pushing content from web sites to web clients. You can
find the specifications for CDF 1.0 at
http://www.microsoft.com/standards/cdf-f.htm.
The issue involves CDF's use of
logging
and the potential for a web site provider to make your browser deliver
logs of your web usage via an http post or put. On the client side,
this is known as "page hit counting." Page hit counting
can be enabled/disabled in IE4 by clicking on View | Internet Options and
going to the Advanced tab. For additional information, right-click
on "Enable page hit counting" and click "What's
this?". I am currently investigating this matter, but
initially I would say that it seems likely to be a non-issue, perhaps even
a false rumor intentionally started by an anti-Microsoft or anti-IE person
or group. Warnings have appeared in diverse newsgroups and mailing
lists of all kinds. If you have any information on this, let
me
know.
I sent a mail message to Site Builder Network
asking them about the CDF logging issue. Their response was:
"There are <LOG> and <LOGTARGET>
tags that allow you to record online and offline user activity to an
event log that you can upload to a specified URL during scheduled
updates. The current CDF spec only logs whether specific Channel items
(and their subitems) have been viewed. The log information is anonymous
and logging can be disabled by the user (on the Advanced tab of the
Options dialog in Internet Explorer's View menu) or administrator (in
the Registry)."
There is more information about this at the
IE4 Technologies section of the SBN site at
http://www.microsoft.com/workshop/prog/ie4/,
the CDF spec at
http://www.microsoft.com/standards/cdf-f.htm,
and in the IE4 SDK CDF Reference, located at
http://www.microsoft.com/msdn/sdk/inetsdk/help/content/ref_cdf/cdfref.htm#content_cdfref."
On October 16, 1997,
Ralf
Hueskes from
Jabadoo Communications
in Freiburg, Germany discovered what some are calling a "dangerous
security hole" in IE 4.0. This security issue, which
involves the use of JScript, could allow a malicious web site to view the
contents of certain file types from a user's hard disk. Only text,
HTML and graphic images are vulnerable, and they can be viewed only, not
modified or deleted. You can read the details at
http://www.jabadoo.de/press/ie4_us.html,
and if you speak German, at
http://www.heise.de/ct.
This security hole is serious enough that Microsoft has already
posted a
fix
for this issue, which they have dubbed the "Freiburg text-viewing
issue." You can read all of Microsoft's details at
http://www.microsoft.com/ie/security/?/ie/security/freiburg.htm.
According to Daniel Will Harris,
a charter member of
TypeRight - a
non-profit group formed to protect typeface designs - IE4 has a security
hole that allows embedded fonts to be "captured" and used as
fonts on a local system. While not dangerous to the end user in any
way, this security issue seriously affects the intellectual property
rights of font designers and foundries. Get the full story
here.
On November 10, 1997,
L0pht
Heavy Industries released a security
advisory
warning on Internet Explorer 4.0 for Windows 95. This is a very
serious issue, but it only affects Windows 95. According to
dildog@l0pht.com, IE4 and it's suite
components that process HTML are "subject to a buffer overflow in
the HTML decoding process." Because the process involves
the HTML decoding system, IE's new security zone settings cannot overcome
the problem. IE4 processes a new URL type -- "res://"
which under Windows 95, can only handle 256 characters. Any more and
the buffer overflows, crashes the system, and a hole opens which can
expose a Windows 95 machine to viruses or other harmful code. Get
the full story
here,
and try it out on your own machine
here.
The example crashed my PC hard. Fortunately, on November 11,
1997, Microsoft released a
patch
for this issue (which also includes a fix for the Freiburg text-viewing
issue. Windows 95 users should get this patch now!
Non-Windows 95 users can get the Freiburg patch at
http://www.microsoft.com/ie/security/?/ie/security/freiburg.htm.
On November 21, 1997,
Microsoft released a
patch
for the "Page Redirect" issue that affects IE 3.02 and IE 4.0
for Windows 95 and Windows NT. This issue does not
affect Internet Explorer for Windows 3.1, Windows NT 3.51, or Macintosh.
It does affect Preview 1 of Internet Explorer 4.0 for UNIX, and there is
no patch available for the Unix version. Basically the problem is
that when you connect to a site that requires basic user authentication
information (name and password), and the Web site redirects you to another
Web site, your authentication information could potentially be captured by
the second Web site. Keep in mind that this patch does not
fix the SMB issue discovered by Aaron Spangler (see above) that can also
grab your username and password.
In the December issue of TechNet, Microsoft published
an article by Robert Bechtel at Microsoft Consulting Services entitled "Security
Management with Internet Explorer 4.0." You can
read
this informative document in HTML, or
download
it in Microsoft Word format. This article is recommended reading for
all IE4 users.
Internet Explorer 4.0 for Windows 95 and Windows NT can hang when
browsing a page that uses irregular or faulty programming. I have
created some pages that offer samples for
demonstration purposes only. Originally, I regarded this as a
security issue, as some systems that were tested actually crashed the
operating system (Win95 went blue screen and NT simply froze altogether);
however, after learning that many people only experienced IE freezing
without crashing the system, I have re-thought that position. Most
users apparently can use CTRL-ALT-DEL or End Task to kill the frozen IE.
One issue to consider, however, is that when installed, IE4 becomes the
"shell" of Win95/NT. As a result, when you kill the shell
of 95/NT, you're killing the GUI interface (explorer.exe), as well.
While this is typically not a problem with NT, Win95 does not always
recover. And if it does recover, it is very common that not all of
the SysTray icons return with the reinitialized Explorer.
On December 2, 1997, Microsoft released Internet
Explorer 4.01, which includes all of the IE4.0 bug fixes and some
accessibility enhancements. You can read the Press Release
here,
and you can download it
here.
IE 4.01 is only available for Win95 and Windows NT (Intel and Alpha).
If you want to know what's new, click
here.
On January 14, 1998,
L0pht
Heavy Industries released an
advisory
regarding a vulnerability of IE 4.0x on Win95 and Windows NT.
This bug may also affect Internet Explorer 3.0 if Visual Studio (VC++/J++
etc) is installed. This vulnerability is very similar to the res://
buffer overflow problems; it exploits the "mk:" URL, a special
URL used for Microsoft's InfoViewer topics which are displayed using the
InfoViewer application (which includes Microsoft TechNet) or Microsoft
Visual Studio. As a result of the buffer overflow, the application
page faults, or in the worst case, executes arbitrary precompiled native
code. Although it is possible for a malicious web master to exploit
this issue, they would need to know details about each target system.
In fact, according to DilDog, the programmer who discovered and posted the
exploit, the exploit would have to be adjusted for each system being
targeted. Because the issue falls within the HTML decoding system of
the IE4 suite, IE4's security zones cannot prevent the exploit.
Technical details and a working example of some exploit code for Win95
(which caused IE4 to page fault in KERNEL32.DLL on my system), can be
found at http://l0pht.com/advisories.html.
If you run IE 4.x, you should also install the patch available from
Microsoft. IE 4.x users can find the patch at
www.microsoft.com/msdownload/ieplatform/IE4mkbuff/mkbuff.htm.
Currently, a patch is not available for IE3 users.
On January 16, 1998, Microsoft released information
regarding a "Contact Name" issue within the Macintosh
version of Outlook Express. This issue can apparently cause e-mail
to be sent to unwanted recipients. The problem occurs when entering
a new e-mail address in the address book without first filling in either
the first or last name field. When both name fields are left blank, all
messages you send will include the unintended e-mail address(es) on the
"cc:" line. If you're running Outlook Express on a
Macintosh, you should download the
4.0c
patch.
On January 18, 1998, Microsoft acknowledged a bug in
the 128-bit Macintosh version of IE4 that prevents users
from accessing sites using Secure Sockets Layer (SSL). This bug
actually prevents Mac users from getting to SSL pages; all they see is a
blank page. On the one hand, this means no information will be
compromised. On the other hand, Mac users cannot enter into secure
transactions. Go
here
for more details, and go
here
for the patch. One important note on the patch, though: people who
downloaded the patch before 7p.m. on January 16 may have
been blocked from some secured sites, and should download the patch again
to ensure connection to all SSL sites.
On January 23, 1998, new flaws were discovered in
Internet Explorer and other Microsoft Internet-based products that allow
private encryption keys to be stolen. This, in turn, allows the
thieves to impersonate their victims. Peter Gutmann, a security
expert in New Zealand, said that both Internet Explorer and Internet
Information Server are flawed in such a way that digital signatures can be
stolen. Gutmann, who by the way has a
web
site that details the recent history of, and current state of, New
Zealand's crypto export policy, believes the flaws are so serious that IE
users should stop surfing the web. Gutmann also has a
page
on how to recover private keys from Internet Explorer, Internet
Information Server and Outlook Express. The arguments presented in
Gutmann's page were
refuted
by Microsoft on January 28, 1998.
On February 4, 1998, Peter Gutmann
rebutted
Microsoft's arguments regarding security weaknesses in various Microsoft
Internet products. Also, an
"mk
buffer overrun" patch was released for IE3 users.
On April 2, 1998, Microsoft released a patch for a new
security issue known as the "Embed issue."
Apparently it is possible to exploit the <EMBED> tag to execute code
on a machine running IE4. On April 24, 1998,
Microsoft released a patch for the Macintosh and Unix versions of IE.
Below is a list of versions that are at risk (from Microsoft's
page
on this issue):
- Internet Explorer for Windows 95 and Windows NT:
- Internet Explorer for Windows 3.1 and Windows NT 3.51:
- Internet Explorer 4.0 for Windows 3.1, Windows NT 3.51, and
Windows for Workgroups: Not at risk.
- Internet Explorer 3.0/3.02 for Windows 3.1, Windows NT 3.51, and
Windows for Workgroups: Not at risk.
- Internet Explorer for Macintosh:
At
risk.
Download
the fix now. (Once you click the link, you'll need to choose your
version from the drop-down box.)
- Internet Explorer 4.0 for Unix:
At risk.
Download
the fix now.
Microsoft's
page
on this issue will also indicate whether or not you are affected by this
issue. Currently, only the English version of the patch is
available, but other language versions should be available shortly.
On May 13, 1998, Microsoft released IE 4.01 for
Macintosh. Get all the details
here.
On May 15, 1998, Microsoft released a
Year
2000 patch for IE 3.02 (Win95 and NT 4.0).
On May 20, 1998, Microsoft released Service Pack 1 for
IE 4.01 (Win95 and NT4.0), which you can download
here.
Note, that if you have the 128-bit version of IE 4.01, this patch
will preserve that.
On July 27, 1998, Microsoft's Product Security
Response Team issued
Security
Bulletin MS98-008 which describes the Outlook Express File Attachment
Issue -- a security issue regarding the way Microsoft mail clients,
including Outlook Express, handle file attachments with extremely long
filenames. According to the bulletin, "When a user attempts
to download, open or launch a file attachment that has a name greater than
a certain number of characters, the action might cause the client to shut
down unexpectedly. Once the client has crashed, a skilled hacker could
possibly run arbitrary code in the computer's memory."
This issue was discovered by
OUSPG.
Microsoft has a
web
page which will examine your system and indicate whether or not you're
affected. This issue affects the version of Outlook Express that
shipped with Internet Explorer 4.0 or 4.01 on Windows 98, Windows 95,
Windows NT 4.0, Windows NT for DEC Alpha, Macintosh, or UNIX.
Windows 3.1 and Windows NT 3.51 versions of Internet Explorer are not
affected by this issue. This issue is further documented in
Microsoft Knowledge Base (KB) article
Q168019,
Update Available For Outlook Express Security Issue. Note:
While investigating this matter, Microsoft has determined that, although
the patch does correct this issue, there is a similar issue that is
corrected by the patch released on August 11, 1998.
On August 11, 1998, Microsoft released an updated
patch for Outlook Express that addresses a variation of the Outlook
Express File Attachment Issue that was discovered during the testing of
that issue. Microsoft has updated
Security
Bulletin MS98-008 to reflect this new information. Note:
Macintosh users don't need the updated patch; the original patch fixes
both issues. To check to see if your computer needs the update(s),
click
here.
On August 17, 1998, Microsoft's Product Security
Response Team issued released
Security
Bulletin MS98-011 which describes a JScript scripting security issue.
Microsoft also released a patch that fixes this issue, which you can find
at
http://www.microsoft.com/msdownload/vbscript/scripting.asp
(Windows 98 users can find this patch as a "Critical Update" on
the Windows Update site).
This problem, which was reported by Georgi Guninski and
NTBugTraq,
arises out of a vulnerability in Internet Explorer's JScript scripting
engine. When surfing a web page that uses JScript script to invoke
the Window.External function with a very long string, Internet Explorer
might terminate. It is possible that someone could exploit this
vulnerability and run arbitrary computer code contained in the long
string. It is highly recommended that this patch be installed.
On September 4, 1998, Microsoft's Product Security
Response Team issued released
Security
Bulletin MS98-013 which describes the "Cross Frame
Navigate Vulnerability" in Internet Explorer.
Microsoft has also released a
Knowledge
Base article on this issue. The vulnerability, which was
reported by Georgi Guninski, could allow a malicious webmaster to read
files on the remote computer by circumventing Internet Explorer's
safeguards that pertain to scripts interacting with other instances of IE.
The following versions of IE are affected:
- Microsoft Internet Explorer versions 3.0, 3.01, 3.02, 4.0, 4.01
for Windows 95
- Microsoft Internet Explorer versions 3.0, 3.01, 3.02, 4.0, 4.01
for Windows NT 4.0
- Microsoft Windows 98
- Microsoft Internet Explorer versions 4.0, 4.01 for Macintosh
- Microsoft Internet Explorer versions 4.0, 4.01 for Windows 3.1
- Microsoft Internet Explorer versions 4.0, 4.01 for Windows NT 3.51
You can see if you're at risk
here.
There won't be a patch for IE 3.x. Microsoft recommends that IE3.x
users (except for IE 3.x Macintosh users who are unaffected) upgrade to
the latest version of IE, and then install the
patch.
On October 8, 1998, a web
developer from Spain named
Juan
Carlos G. Cuartango reported his discovery of what he is calling the "Cuartango
Hole." According to Mr. Cuartango, a
malicious webmaster can write a script that can cause files to be sent to
the webmaster's server. All the webmaster needs to know if the path
and filename. In addition, the contents of the clipboard can also be
sent. This security issue affects IE 4.01 and 4.01 SP1 on
Windows NT 4.0 and Windows 95; Windows 98; and IE 4.01 for Windows 3.1 and
Windows NT 3.51. This issue does not affect IE running on Macintosh
or UNIX operating systems, IE 3.x running on any operating system, or
IE 4.0 running on any operating system.
This security hole is demonstrated
on
Mr.
Cuartango's web site. It works by exploiting a design flaw in
Internet Explorer. Mr. Cuartango has said that his web site has
been/is being attacked by hackers and that, as a result of this attack,
the security hole may not be properly demonstrated. In other words,
you may get a false negative result when testing your browser for this
hole. You can, however, also test your browser
here.
On October 13, 1998,
Microsoft posted information on their
Internet
Explorer site indicating that they have confirmed the "Cuartango
Vulnerability (aka Untrusted Scripted Paste Security Issue).
Microsoft says that a patch will be available for download within the next
week. In the meantime, Microsoft indicates that customers can
protect themselves by disabling Active Scripting in the Internet Zone of
IE's Security Zones feature.
On October 16, 1998,
Microsoft issue
Security
Bulletin MS98-015 and
Knowledge
Base article Q169245 which discuss the Untrusted Scripted Paste issue.
Microsoft has also released a patch which closes this security hole.
Like all other patches, Windows 98 users can obtain the patch from the
Windows
Update web site. All other affected users can find the patch
here.
On October 17, 1998, a new
and dangerous security hole was discovered in the Windows versions of IE4
and higher. According to
Sune
Hansen, webmaster of
http://WorldWideWait.com,
the hole was discovered as the result of his inquiry in
dk.edb.internet:
"This is the way the bug was discovered: I found an URL
like: http://12345678 on the internet. I was confused about how and
why it worked. The next thing I did was that I started a new thread
in the newsgroup: dk.edb.internet about the funny URL issue. One guy
gave me the calculation method. Another guy wrote that the funny URL
also worked for him. He ended his comment by saying: "BTW: the
security zone changes" He didn't think of the change in the
security zone as important. I instantly thought about it as a
major security risk and started writing mails to internet related
news sites. So, I didn't discover the bug _all_ by myself.
-- Sune Hansen"
Two fellow Danish newsgroup participants,
Jakob
Paikin and
Jacob Albers, also
share credit in the discovery of this issue. IE 4 and higher
versions segregate the Internet world into zones, so that you can assign a
web site to a zone with a specific security level. There are four
zones: Internet, Local Intranet, Trusted Sites and Restricted
Sites. There are different ways to address a web site: (1)
by its fully qualified domain name (e.g.,
http://www.nwnetworks.com),
(2) by its host name (e.g.,
http://NorthwestNetworks),
(3) by its IP address (e.g.,
http://216.65.128.112),
or (4) by a number like http://3628171376,
to name a few. Converting an IP address to a number such as the one
in the 4th URL, is performed using the following formula:
W(256�) + X(256�) + Y(256) +
Z
where w.x.y.z is the IP address.
All four URLs will take you to Northwest Networks, unless you access the
Internet through a proxy server, in which case you'll get a 404. But
unlike the first three, which IE correctly recognizes as being in the
Internet Zone, URL number 4 (http://3628171376) causes the site to be
placed in the Local Intranet Zone. Apparently this has to do with
the fact that there are no dots in the URL. If IE encounters an
address without any dots, it assumes the page is on an intranet and it
applies its Local Intranet Zone settings.
By default, both the Internet zone and the
Local Intranet zone are set to medium security, so ordinarily this isn't a
problem. But say, for example, that you've configured your Local
Intranet Zone to use Low security. This means that a site that
normally would use Medium security could now end up with a Low security
setting. This is a major security hole which can expose system
data, as well as user names and passwords. One rogue applet could
take out the system, and perhaps even other systems if the target machine
is on a network.
On October 23, 1998,
Microsoft released
Security
Bulletin 98-016 and Knowledge Base article
Q168617
which discuss what Microsoft calls the "Dotless IP Address"
issue. Microsoft has also released a patch for this issue. Like
all other patches, Windows 98 users can obtain the patch from the
Windows
Update web site. All other affected users can download the patch
here.
On November 5, 1998, a design flaw in IE's
DirectDraw Java foundation classes was discovered by
Fabio
Ciucci. This flaw allows a malicious webmaster to create a java
applet that can completely crash a Win9x system running IE4 and higher
(including IE5). It can also crash IE4 and higher on NT (although NT
remains unaffected). According to an
article
published by C|Net, Microsoft has acknowledged this "obscure but
serious" issue. Mr. Ciucci has a demonstration of a hostile
applet on his
web site.
On November 18, 1998, Microsoft
released an
Update
to Microsoft Security Bulletin MS98-015, as well as an updated patch
for the Cuartango Hole (aka Untrusted Scripted Paste issue). This
"Son of Cuartango" hole was discovered by
Juan
Carlos G. Cuartango, who also discovered the original issue. The
new variant of this issue poses the same security risks as the original
hole. Full technical details can be found on
Mr.
Cuartango's web site. A patch has been made available which
fixes this vulnerability. Windows 98 users can download the patch
from the
Windows Update web
site. All other IE 4.01 users can download the patch at
http://www.microsoft.com/ie/security/paste.htm.
On December 10, 1998, Microsoft
released
Security
Bulletin MS98-18 and KB article
Q196791,
which discuss the "CALL" vulnerability in Microsoft Excel.
The CALL function can be used in a macro or as a worksheet function.
While Excel alerts the user before running a macro ( including macros that
contain the CALL function), no such warning appears before a worksheet
function is calculated. An external DLL could be called and run
without the user knowing about it. This also means that certain
types of executables can be copied to a user's computers and run without
any warning to the user. An attacker could exploit this
vulnerability by embedding an Excel spreadsheet with the CALL function in
a web page. The attacker would then be able to control whether the
CALL function fired when the spreadsheet was opened or even when another
event occurs. Keep in mind that the CALL function does not perform
any malicious action by itself; it is only an initiator for a malicious
DLL. In order for Internet Explorer users to be affected by this
issue, Excel needs to be installed on their computer (not running, just
installed). Microsoft also released the
Excel
97 SR-2 CALL Function Patch which requires the Office 97 SR-2 update
to be installed prior to applying the patch. Microsoft has not
released a patch for Excel 95, which is also affected. Excel 95
users should disable the CALL function until a patch is available.
On December 23, 1998, Microsoft
released
Security
Bulletin MS98-20 and KB article
Q167614,
which discuss the newly discovered "Frame Spoof" vulnerability.
This issue was discovered and reported by Dr. Richard Reiner of
SecureXpert
Labs. The problem exists because IE's cross-domain protection
doesn't extend to frames navigation. This means a web site can put
content into a frame within another web site's window. The
user might not even be able to tell that the frame contents were not from
the legitimate site. As a result, the user could be tricked into
providing personal data to the malicious site. Both HTTP and
HTTPS sites are at risk. Juan Cuartango, the Spanish developer
who discovered the Untrusted Scripted Paste Issue, has a demonstration of
the Frame Spoof issue on his
web
site.
According to Microsoft's Security Bulletin,
only the following versions of IE are vulnerable:
- Versions 3.X, 4.0, 4.01, 4.01
Service Pack 1 for Win95
- Versions 4.01 Service Pack 1 for
Win98
- Versions 3.X, 4.0, 4.01, 4.01
Service Pack 1 for NT 4.0
- Versions 3.X, 4.0, 4.01 for
Windows 3.1
- Versions 3.X, 4.0, 4.01 for NT
3.51
- Versions 3.X, 4.X for Macintosh
- Version 4 for UNIX on HPUX
- Version 4 for UNIX on Sun Solaris
Windows 98 users can download and install the
patch from
Windows Update.
IE 3.X and 4.0 users must first upgrade to IE 4.01 with Service Pack 1.
After installing the upgrade, you need to apply the IE 4.01 patch as
discussed below. IE 4.01 users (with or without SP1) can obtain the
patch
here.
The patches for the Macintosh, HPUX and Solaris versions will be slightly
delayed. When they are available, a notice will be posted
here.
On January 21, 1999, Microsoft
released Security Bulletin
MS99-002
and KB article
Q214652,
which discuss the "Word 97 Template Vulnerability." This
issue was reported by Woody's Office Watch, and DavidF, one of their
readers. The vulnerability allows malicious macro code to be run in
a Word 97 document without warning a user when the document is opened.
A security feature within Word 97 warns users when a document containing
macros is opened. But, if the document doesn't contain macros,
but rather is linked to a template that contains macros, no warning to the
user appears. It is possible for someone to exploit this
vulnerability by causing malicious macro code to run without any warning
if a Word document attached to an email, or on a web site, is opened.
This malicious macro could then possibly be used to damage or retrieve
data on a user's system. Microsoft has released a
patch
for this issue. If you run Word 97, I strongly recommend that you
install the patch.
On January 28, 1999, a Javascript
vulnerability in IE 4.x was reported by
Georgi
Guninski. Mr. Guninski is credited with the discovery and
reporting of other IE security issues, including the Cross Frame
Navigate Vulnerability issue that was reported in September 1998.
This security hole allows a malicious webmaster to read files on users'
hard drives, if the webmaster knows the path and filename. Mr.
Guninski demonstrates this vulnerability on his
web
site. In addition, IE is vulnerable to "window
spoofing." This means that a malicious webmaster can create a
link or a page that causes the user to believe they're surfing a trusted
site, when in fact the content originates from the hostile site.
This means that any information the user enters (e.g., name, address,
credit card, etc.) will go to the hostile site, and not to the trusted
site that the user thinks they're surfing. Apparently, this
vulnerability can be also exploited using an HTML email message. Mr.
Guninski demonstrates this second vulnerability at on his
web
site. He also has a third
demonstration
that reads the local autoexec.bat file. Microsoft has not confirmed
this issue as yet.
On February 10, 1999,
Juan
Carlos G. Cuartango reported his discovery of what he is calling the "new
Clipboard vulnerability" in Internet Explorer 4.0.
According to Mr. Cuartango, there is a vulnerability in the Microsoft Web
Browser ActiveX control that allows a malicious webmaster to bypass the
normal safeguards that prevent Internet Explorer scripts from pasting the
contents of the clipboard into an input box unless IE owns the clipboard
content. This can be exploited in both a web page and an HTML mail
message. This vulnerability is demonstrated at Mr. Cuartango's
web
site. Microsoft is aware of this issue and a fix for the
vulnerability will be in the next Service Pack for IE. Neither IE3
nor IE5 are affected by this issue.
On March 10, 1999,
Phar
Lap Software President Richard Smith reported his discovery of a
security problem with an ActiveX control that's installed on every Windows
98 machine. During the Windows98 installation process, a unique
hardware ID and a unique "Microsoft ID" are generated and stored
in the registry. Windows 98 also ships with an information gathering
tool and software registration application called the Registry Wizard
("RegWiz" for short). A core component of this Wizard is
the RegWiz ActiveX control. Mr. Smith discovered that by
implementing this ActiveX control in a web page, a malicious webmaster can
cause Windows 98 to send some registration information to the web site,
which includes these unique IDs. A demonstration of this security
issue can be found at the Phar Lap
web
site. Because I've found that site slightly difficult to connect
to, I've modified Mr. Smith's demo page and mirrored it
here.
Because this hole makes it possible for a malicious webmaster to receive
private information from within the Windows 98 registry, I would consider
it a major hole. Microsoft is aware of the issue and is working on a
fix. As soon as the fix is released it will be reported here, so
keep checking the FAQ.
On March 25, 1999,
Juan
Carlos G. Cuartango reported his discovery of what I believe to be the
first reported IE5 security issue. IE5 comes with two similar
ActiveX controls. One is called the "DHTML Edit Control for
IE 5." The other is called the "DHTML Edit Control
Safe for Scripting for IE5." According to Mr. Cuartango,
who has himself discovered and reported several other IE security issues,
there are two security holes within "Safe for Scripting" ActiveX
control.
First, there's the vulnerability that Mr.
Cuartango has dubbed the "DHTML Editor Clipboard
vulnerability." This issue presents another instance where
a malicious webmaster can cause the contents of the Windows clipboard to
be transmitted to their web site. You'll recall that Microsoft has
implemented safeguards that prevent IE scripts from pasting the contents
of the clipboard into an input box unless IE owns the clipboard content.
Using the following simple code, this protection can be bypassed:
function getcb()
{
dh.DOM.body.innerHTML="";
// clear body
dh.execCommand(5032);
// paste
S1.value = dh.DOM.body.innerText; // copy to text area
}
You can find a demonstration of this
vulnerability on Mr. Cuartango's
web
site.
Second, there's the vulnerability that
Mr. Cuartango has dubbed "The DHTML Editor cross-frame hole."
This hole is serious for two reasons: (1) it bypasses the rule that
scripts can only access documents in the same domain using the same
protocol; and (2) it allows transaction spoofing. While the
"Safe for Scripting" control cannot navigate, it can submit
forms. This means that a malicious web page (or HTML mail message)
can perform transactions using your IP address without your knowledge.
To make matters interesting, according to
Mr. Cuartango, even if Microsoft fixes this hole, it could exist forever.
In his report to NTBugTraq, Mr. Cuartango said:
"As far as I know this is
the first time a hole is "SIGNED". MS has released an
"dhtmed.cab" file as an ActiveX component signed by
Microsoft ,anibody can distribute this file and the victim will only
see a message telling him that the component is "Microsoft
signed", I trust MS, everybody trust MS, we will accept the
ActiveX. MS has invented a very clever method to sign software, but
there is not a way to revoke the signature.
There is something rare in the
CLSID. Whenever an HTML page references a not registered CLSID
nothing happens, just the object is not created. The "DHTML
Edit Control" CLSID
(clsid:2D360201-FFF5-11d1-8D03-00A0C959BC0A) is very special,
Internet Explorer (4 and 5) will try to download the component from
MS even if CODEBASE is not defined for the object. Is this a
documented feature ? You can test this behaviour, : unregister the
component "dhtmle.ocx" (using regsvr32.exe) and then load
the page
http://pages.whowhere.com/computers/cuartangojc/dhtmle2.html
Why the browser decides to go to MS site ? It only knows :
clsid:2D360201-FFF5-11d1-8D03-00A0C959BC0A. Acoording whit MS
documentation a CODEBASE parameter must be explicited in the OBJECT
"object" to download the component."
Microsoft's official response came from
Harry
Goodwin (quote from NTBugTraq):
"I wanted to take a moment
to thank Juan Carlos for bringing these issues to Microsoft's
attention prior to posting the issues publicly. I also wanted to
post Microsoft's response to the issues he's discovered.
1) Internet Explorer has
customizable security settings in place for users who are concerned
about allowing certain functionality. In this particular case,
concerned users can easily block this behavior by checking either
'disable' or 'prompt' under "Allow paste operations via
script" in the custom settings section in security zones. Using
the IEAK, admins can also adjust the default setting for this option
before distributing Internet Explorer to their users. The option is
set to 'enable' by default to allow enhanced functionality.
2) Upon investigation we did
find a cross domain security violation in the DHTML edit control
which we will revoke, fix, and release.
3) Internet Explorer has a
mechanism in place which allows Microsoft to release a .reg file to
block ActiveX controls by changing a bit in the registry.
4) The following information
found on MSDN (search on CodeBaseSearchPath) addresses this concern:
When Internet Component Download is called to download code, it
traverses the Internet search path to look for the desired
component. This path is a list of object store servers that will be
queried every time components are downloaded using
CoGetClassObjectFromURL. This way, even if an <OBJECT> tag in
an HTML document does not specify a CODEBASE location to download
code for an embedded OLE control, the Internet Component Download
will still use the Internet search path to find the necessary code.
Internet search path syntax The search path is specified in a string
in the registry, under the key HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Internet
Settings\CodeBaseSearchPath. The value for this key is a string in
the following format: CodeBaseSearchPath = <URL1>;
<URL2>; ... <URLm>; CODEBASE; <URLm+1>; ...
<URLn-1>; <URLn> In this format, each of URL1 through
URLn is an absolute URL pointing to HTTP servers acting as
"object stores". When processing a call to
CoGetClassObjectFromURL, the Internet Component Download service
will first try downloading the desired code from the locations URL1
through URLm, then try the location specified in the szCodeURL
parameter (corresponding to the CODEBASE attribute in the
<OBJECT> tag), and will finally try the locations specified in
locations URLm+1 through URLn. Note that if the CODEBASE keyword is
not included in the key, calls to CoGetClassObjectFromURL will never
check the szCodeURL location for downloading code. By removing the
CODEBASE keyword from the key, corporate intranet administrators can
effectively disable Internet Component Download for corporate
users."
Needless to say, these are some very
interesting issues. Even as time passes, and browsers become more
and more advanced, there still remains many opportunities for malicious
webmasters to exploit security vulnerabilities in web browsers. On April
21, 1999, Microsoft released a
patch
for this issue.
On March 26, 1999,
BugNet
issued an
alert
regarding IE5's interaction with Point-to-Point Tunneling Protocol (PPTP).
PPTP is a networking technology that supports multi-protocol virtual
private networks (VPNs). It allows remote users to dial into a local
Internet service provider, connect securely to their corporate network
through the Internet, and access the corporate network securely from NT
Workstation, Win9x, and other point-to-point protocol (PPP)-enabled
systems. But according to KeyLabs, simply enabling PPTP on an NT 4
server or workstation has the effect of disabling web browsing with IE5.
According to BugNet's alert, Microsoft has not responded to repeated
requests for comment on this.
On March 26, 1999, Microsoft
release Knowledge Base article
Q223780
which discusses cookie support in IE5. Earlier versions of IE used
global cookie settings, which means they're either on or off. IE5
introduces cookies on a per-zone basis. This enhances cookie use
because it means you can turn them off on the Internet and keep them on in
your Intranet or other trusted sites. The issue here is that if you
have cookies turned off and you upgrade to IE5, cookies are re-enabled
during the IE5 setup process. For more details, check out this
article, and articles
Q196955
and
Q174360.
On March 31, 1999, Georgi Guninski
reported his discovery of a serious security hole in IE5 that allows the
sending of local files to a malicious web server. According to Mr.
Guninski, who is credited with the discovery of other IE security
problems, there is a bug in the DHTML Edit control that allows the pasting
of a file name into a file object. As a result, a simple JavaScript
form can be used to send the contents of a file to a remote web server.
The only caveat is that the path and file name must be known to the
malicious webmaster in order for them to be able to receive it. This
isn't too difficult given the default paths and filenames typically found
on a Windows PC. Mr. Guninski has posted an example of this exploit
on his web site. Mr.
Guninski also thanked Juan Carlos G. Cuartango for his IE security
discoveries and indicated that they helped him make this discovery.
Microsoft has not yet commented on this, so the status of a fix is
unknown. Fortunately, there are two workarounds: (1) disable
JavaScript; or (2) go into the Tools menu, then Internet Options.
Click on the Security tab, then Custom Level, and set Allow paste
operations via script to either Prompt or Disable.
On April 1, 1999, Microsoft
released Service Pack 2 for IE 4.01. SP2 is an update for
both IE 4.0 and IE 4.01, and it is identified as build 4.72.3612.1712.
SP2 addresses the following security issues:
KB
Article |
Description |
Q181860 |
Secure Lock Symbol
Disappears Connecting to Secure Web Page |
Q188706 |
Problems Connecting to
Secure Web Site with 128-Bit Encryption |
Q193489 |
Internet Explorer
Returns Error Message When Being Redirected |
Q195567 |
Wininet Credentials
Are Not Reset on Keep-Alive Connections |
Q189854 |
Internet Explorer
Issues Extra Challenge with NTLM |
Q179221 |
Limit Access to Local
Computer with Internet Explorer 4.01 |
Q186485 |
Update Available for
Cross-Frame Security Issue |
Q168617 |
Update Available for
Dotless IP Address Security Issue |
Q168109 |
Update Available For
Outlook Express Security Issue |
Q168614 |
Update Available For
"Frame Spoof" Security Issue |
Q169245 |
Update Available for
"Untrusted Scripted Paste" Issue |
Q191200 |
Update Available for
Window.External JScript Security Issue |
On April 21, 1999,
Microsoft released
Security
Bulletin 99-011 and Knowledge Base article
Q226326
which discuss the release of an
update
for what Microsoft calls the "DHTML Edit Security Issue."
This refers to the issues reported on March 25, 1999 by
Juan
Carlos G. Cuartango (see above). This update eliminates the
vulnerability in the DHTML Edit ActiveX Control that allows a malicious
web site to read information that has been loaded into the control.
The vulnerability also allows files with known names to be copied from the
local hard disk. Click
here
to see if you are affected by this issue and to download the fix.
On April 21, 1999, Microsoft also
released
Security
Bulletin 99-012 which discusses the release of an "MSHTML
Security Update for Internet Explorer." This
fix
is an updated version of MSHTML.DLL, IE's HTML parsing engine which
corrects three unrelated problems in the engine.
- The first vulnerability, which was
originally reported by
Phar Lap
Software President Richard M. Smith, is a privacy issue involving
the processing of the "IMG SRC" tag in HTML files. The
IMG SRC tag identifies and loads images that are displayed as part of
a web page. The vulnerability results because the tag can be
used to point to files of any type -- not just image files -- at which
point document object model methods can be used to determine
information about the file. A malicious web site could use this
vulnerability to determine the size, date and other information about
files on the computer of a visiting user. The malicious web site
would have to know the name of each file, and it wouldn't be able to
read, change or transmit the files.
- The second vulnerability is a the
variant of the previously-identified cross-frame security
vulnerability which was reported by Georgi Guninski. A
particular malformed URL can be used to execute a Java scriplet in the
security context of a different domain. This allows a malicious
web site to execute a scriptlet on a visiting user's machine as though
it were from a trusted site.
- The third vulnerability affects only
IE 5.0, and is a new variant of the previously-identified untrusted
scripted paste vulnerability, which was also reported by Georgi
Guninski. The vulnerability allows a malicious web site to create a
particular type of web page control and paste into it the contents of
a visiting user's clipboard.
The fix also includes all previous fixes
for the "Frame
Spoof," "Untrusted
Scripted Paste" and "Cross
Frame Navigate" vulnerabilities in IE versions 5, 4.01 Service
Pack 1, and 4.01 Service Pack 2 running on Windows. To check to see
if you're affected and to download the update, click
here.
On May 4, 1999, Jesse Berst's
AnchorDesk issued a
report
describing a security bug they discovered in IE 5. This report was
then followed by a ZDNet
report.
The bug, which was uncovered by AnchorDesk Technical Director Jon DeKeles
and confirmed by Microsoft, affects users who share the same machine for
browsing. If one user goes to a web site - in particular, a Unix web
site that used the .ht access method for accepting usernames and passwords
- any other user with access to the system can also access that page,
without having to enter a username or password. In order to view a
secure page that User A visited, User B would have to (1) enter in the
URL, (2) cancel the username/password dialog box, and (3) click the
Forward button. The secure page is then retrieved from the local web
cache, and displayed to User B. Microsoft is currently investigating
this issue. They agree that this is a bug, and they are determining
the extent of the breach and whether or not a patch can be issued.
Until such time as one is issued, you can employ one of a couple
workarounds:
- Manually clear your web cache each
time you're finished browsing
- Configure IE to purge the cache
when the browser is exited
- Configure IE to check for a new
version of the page every visit
- Configure IE to not save encrypted
pages to disk
On May 27, 1999, Microsoft
released
Security
Bulletin MS99-018 and Knowledge Base articles
Q231450
and
Q231452
which discuss the release of patches for IE4 and IE5 for two security
issues: the "Malformed Favorites Icon" vulnerability, and the
"Legacy ActiveX Control" vulnerability.
Malformed Icon Vulnerability:
This only affects IE5 on Win9x. Neither IE4 nor NT systems are
vulnerable. If you're using IE5, you're probably very familiar
with the Favorites feature in Internet Explorer. The icons on the
Favorites don't need to be provided by Windows; they can come from the
linked web site. Within the code that allows this there is an
unchecked buffer. Because the buffer is unchecked, a malformed icon can
overrun the buffer and allow code to be executed on the user's system.
This issue was discovered and reported by
Flavio
Veloso.
Legacy ActiveX Control Vulnerability:
This affects IE4 and IE5 on Win9x and NT. An ActiveX control from
earlier versions of IE was mistakenly included in IE4 and IE5.
Although neither version uses the control, the control's existence
allows it to be exploited in a malicious manner. This issue was
discovered and reported by Steve Loughran.
Microsoft has released a
patch
to correct both these issues. This is a single patch that will
correct both issues on IE5 machines, and the Malformed Icon Vulnerability
on IE4 machines. If you're running IE4 or IE5 on Win9x or NT, you
should install this patch.
On June 28, 1999, Microsoft
released a Year 2000 patch for Outlook Express 4.01 with SP1 or SP2.
The patch corrects a potential problem that can occur when an IMAP mail
message or an NNTP message with a 2-digit year as part of its sent date.
Under certain conditions the century date may be misinterpreted. If
the 2-digit year is anything other than '99', Outlook Express assumes the
century value is the same as the current century. If the current
year is 2000, and a 2-digit date is received as '97', then the year date
will be interpreted as 2097. However, there is one special case when
different logic is applied. If a 2-digit year of '99 is received and the
current year is a multiple of 100 (e.g. 2000), the year will be
interpreted as the current year plus 98 (e.g. 2098). You can get
details about this problem
here,
and you can download the patch at the
Internet
Explorer download page. Below are the affected versions and the
recommended course of action:
If
your version is 5.00.20xx.xxxx or higher, you do not need
the update.
If
your version is 4.72.36xx.x, you need the update for Outlook
Express 4.01 SP2.
If
your version is 4.72.31xx.x, you need the update for
Outlook Express 4.01 SP1.
If
your version is 4.71.17xx.x or 4.72.21xx.x, you need to
either:
(1)
Upgrade
to version 5.0, or
(2)
Upgrade
to version 4.01 SP1 or SP2 and then apply the
appropriate update.
On June 30, 1999, Microsoft
released Knowledge Base article
Q235524
- Secure FTP Through a Proxy Does Not Work Using NTLM. Microsoft
has a hot-fix for this issue, which can be obtained at no charge through
one of their many
support
channels.
On August 24, 1999,
Georgi
Guninski reported his discovery of a vulnerability within Internet
Explorer 5.0 that allows a malicious webmaster to exploit a
Microsoft-provided ActiveX control -- Script.Tylib -- allowing them to
create or write to files on systems that execute the control. Mr.
Guninski has posted a live demonstration of this exploit on his
web
site. If you don't want the exploit to run, follow one of
the workarounds listed below. The vulnerability exists
within "Object for constructing type libraries for scriptlets"
ActiveX control. The control allows for creating, writing to, and
overwriting local files. In Mr. Guninski's demonstration, an HTML
Application file is created, fed exploit information and written to the
Windows StartUp folder. The next time a user reboots, the HTML Application
file will be executed. Microsoft released a
patch
for this vulnerability on August 31, 1999. NOTE: Circa
September 7, 1999, the patch should also be available through
Windows
Update.
On August 25, 1999, released
Security
Bulletin MS99-031 and Knowledge Base article
Q240346
which discuss the "Virtual Machine Vulnerability." This is
a vulnerability in the Microsoft Virtual Machine that could allow a
malicious Java applet to operate outside the "Java sandbox."
A Java applet could exploit a
privilege
elevation vulnerability to take almost any action against visitors to
a malicious web site; the applet it could create, delete or modify files
on the user's computer, reformat the hard drive, copy data to or from a
web page, or take any other desired action. Microsoft also released
a
FAQ
bulletin regarding this vulnerability. As stated in the FAQ: "The
Microsoft VM ships as part of a number of Microsoft products, but by far
the most prevalent ship vehicle is Internet Explorer. If you have Internet
Explorer 4.0 or 5 on your machine, you definitely have an affected version
of Microsoft VM and should consider applying the patch." To
find out if you're affected by this issue:
Go to a command prompt, type "JVIEW"
and hit the enter key. The version information will be at the right of
the topmost line. It will have a format like
"5.00.xxxx", where the "xxxx" is the build number.
- If you have a build number of 1520
or lower, you are not affected by this vulnerability.
- If you have a build number higher
than 1520, you are affected by this vulnerability.
Microsoft has also released a
patch
for this vulnerability for Windows 9x and NT 4.0. This is a highly
recommended patch. The build number for the patched version is 3186.
On August 31, 1999, Microsoft
released
Security
Bulletin MS99-032 and Knowledge Base articles
Q240308
and
Q240797
which discuss a
patch
for the "Scriptlet.typlib/Eyedog Vulnerability." This is a
fix for both the Script.Typlib vulnerability reported by Georgi Guninski
on August 24, 1999, and the Eyedog vulnerability reported by Shane
Hird of Australia, Adrian O'Neill, and Richard Smith. The Eyedog
vulnerability refers to an ActiveX control (eyedog.ocx), which is used in
the Microsoft System Information Utility (MSINFO.EXE). Although
these controls are not related in terms of functionality, they do have the
serious consequences:
- scriptlet.typelib could allow a
malicious webmaster to cause commands of his or her choice to
execute.
- Eyedog could allow a malicious
webmaster to gather information from the user's computer, such as
registry settings, user name, hardware settings, etc.
This is a highly recommended
patch. The patch is also available through
Windows
Update. Microsoft released a
FAQ
for the patch, as well.
On September 10, 1999, Microsoft
released
Security
Bulletin MS99-037 which discusses the "ImportExportFavorites
Vulnerability" within Internet Explorer 4.01 and 5. IE 4.01 and
5 include a feature that allows users to import and export lists of web
sites. The ImportExportFavorites() method used to perform this function is
only supposed to allow particular types of files to be written, and to
only be written to specific locations. However,
Georgi
Guninski discovered that a malicious web site could invoke this
method, bypass the restrictions and write files that could later be
used to execute system commands. This means that a malicious webmaster
could potentially take any action on the computer they wanted to. As
an immediate you can protect yourself by disabling Active Scripting.
To do this:
- Select Tools | Internet Options, then click on the Security tab.
- Select the Internet Zone, then click on the "Custom Level"
button.
- Under "Scripting", find the entry labeled "Active
Scripting" and set it to "Disable."
- Click OK twice
Microsoft also released a
FAQ
for this security bulletin.
On September 24, 1999, Microsoft released a patch for the "ImportExportFavorites
Vulnerability" which is discussed in
Security
Bulletin MS99-037 and Knowledge Base article
Q241361.
The patch is available on Microsoft's FTP site. To obtain the
version of the patch specific to your environment, select one of the
following links:
Internet
Explorer 4.01 for Intel
Internet
Explorer 4.01 for Alpha
Internet
Explorer 5 for Intel
Internet
Explorer 5 for Alpha
The patch also will be available shortly via
Windows
Update.
On September 28, 1999, Microsoft released
Security
Bulletin MS99-040 and Knowledge Base article
Q242542
which discuss a workaround for the "IE5 Download Behavior
Vulnerability" which could permit a malicious webmaster access to
files located on visiting systems running Internet Explorer 5.0.
IE5 contains a feature called "download behavior" that permits
web pages to download files that can be used in client-side scripts. A web
site should only be able to download files that reside in its domain.
However, Georgi Guninski
discovered that
a server-side redirect can be used to bypass this protection, thereby
enabling a malicious web site operator to read files on the user's
machine. Microsoft also released a
FAQ
with
Security
Bulletin MS99-040. Also, a patch was made available for this
issue on October 8, 1999 (see below).
On October 8, 1999, Microsoft released an update to
Security
Bulletin MS99-040 and Knowledge Base article
Q242542
which discuss the availability of a patch for the "IE5 Download
Behavior Vulnerability." The patch can be downloaded from
WindowsUpdate
or at
http://www.microsoft.com/msdownload/iebuild/dlbhav/en/dlbhav.htm.
On October 11, 1999, Microsoft released
Security
Bulletin MS99-042 which discusses a workaround for the newly
discovered "IFRAME ExecCommand Vulnerability" within IE5 that,
under certain circumstances, could allow a malicious webmaster to read
files on visitor's computers. IE5's security model normally
restricts the Document.ExecCommand() method so as to prevent the taking of
inappropriate action on a user's computer. However,
Georgi
Guninski discovered that at least one of these restrictions is not
present if the method is invoked on an IFRAME (a sub-window of the main
browser window). This vulnerability has nothing to do with IFRAMEs
per se; but it does exist because some of the normal security checks are
not present within IFRAMEs. Microsoft's patch will restore all of the
normal security checks. Assuming the exact path and filename is
known, a malicious webmaster could read the contents of files on visitor's
computers. This vulnerability does not allow the malicious webmaster
to list the contents of folders, create, modify or delete files, or to
usurp any administrative control over the machine. Nevertheless,
this is another serious issue and Microsoft is working on a patch to
correct the problem. In the meantime, Microsoft recommends that
customers add trusted web sites to the Trusted Zone, and then disable
Active Scripting within the Internet Zone. This will maintain full
functionality for trusted sites, while preventing un-trusted sites from
being able to exploit this vulnerability. For more information on
how to do this, refer to the
FAQ
that was released with this bulletin.
On October 12, 1999, Karsten Sohr, a graduate student at the
University
of Marburg in Germany, discovered a security hole within Microsoft's
implementation of Java that allows an untrusted Java program to masquerade
as a trusted one. A bug in Microsoft's bytecode verifier (which
screens Java applets before executing them) permits code sequences that
can violate Java's typing rules. A malicious applet could
exploit this flaw and do anything it wants on the victim's computer (e.g.,
read private data, modify or delete files, etc.). A malicious applet
could also be contained within a mail message within Microsoft Outlook or
Outlook Express. Dirk Barlfanz and
Edward
Felten, from Princeton's
Secure
Internet Programming Lab have constructed a demonstration applet that
exploits this flaw to delete a file. Microsoft has reportedly
acknowledged this problem but they also said it would require "a very
sophisticated programmer" to exploit it.
On October 15, 1999, Microsoft released an update to
Security
Bulletin MS99-042 and Knowledge Base article
Q243638
which discuss the availability of a patch for the "IFRAME ExecCommand
Vulnerability" in IE 4.01 and IE5. Internet Explorer 4.01 users
should apply IE 4.01 Service Pack 2, which you can find at
http://www.microsoft.com/windows/ie/download/windows.htm.
Internet Explorer 5 should apply that patch for this vulnerability at:
- Intel Platform:
ftp://ftp.microsoft.com/peropsys/IE/IE-Public/Fixes/usa/IE50/MSHTML-fix/x86/q243638.exe
- Alpha Platform:
ftp://ftp.microsoft.com/peropsys/IE/IE-Public/Fixes/usa/IE50/MSHTML-fix/Alpha/q243638.exe
The IE5 patch also will be available shortly at
WindowsUpdate.
NOTE: This patch also includes the previously-released fix
for the "Download Behavior Vulnerability" discussed in
Security
Bulletin MS99-040.
On October 18, 1999, Microsoft released
Security
Bulletin MS99-043 which discusses a workaround for the "Javascript
Redirect Vulnerability" that exists in Internet Explorer 4.01 and 5.
This vulnerability could allow a malicious webmaster to read files on a
visitor's computer, provided the path and filename are known. Data
that resides on a visitor's machine that is displayed within IE can be
made available to the web server by using a redirect to a Javascript
applet that is running in the same window. This bypasses security, making
the data available to the applet, which could send the data to the web
server. Assuming the exact path and filename is known, a malicious
webmaster could read the contents of files on visitor's computers.
This vulnerability does not allow the malicious webmaster to list the
contents of folders, create, modify or delete files, or to usurp any
administrative control over the machine. Nevertheless, this is
another serious issue and Microsoft is working on a patch to correct the
problem. In the meantime, Microsoft recommends that customers add
trusted web sites to the Trusted Zone, and then disable Active Scripting
within the Internet Zone. This will maintain full functionality for
trusted sites, while preventing un-trusted sites from being able to
exploit this vulnerability. For more information on how to do this,
refer to the
FAQ
that was released with this bulletin.
On October 21, 1999, Microsoft released
Security
Bulletin MS99-045 and Knowledge Base article
Q244283,
which discuss the availability of a
patch
for the "Virtual Machine Verifier Vulnerability" that exists in
Windows 95, Windows 98 and Windows NT. The version of the Microsoft
Virtual Machine (MVM) which ships with Internet Explorer 4.0 and 5.0
contains a security vulnerability in the bytecode verifier that could
allow a Java applet to operate outside the bounds set by the sandbox.
This is the vulnerability that was report on October 12, 1999 by Karsten
Sohr, a graduate student at the
University
of Marburg in Germany (see above). Microsoft also released a
FAQ
that discusses this vulnerability in more detail. The patch should
also be available at the
WindowsUpdate
web site.
On October 29, 1999, the Microsoft Product Security Team
confirmed the existence of a regression problem with the patch for the
"IFRAME ExecCommand Vulnerability." The problem and the
patch were first discussed in
Security
Bulletin MS99-042 and Knowledge Base article
Q243638.
However, on October 28, 1999,
Francis
Favorini reported that "after applying the IFRAME ExecCommand
patch from MS9-042, IE 5.0 is again vulnerable to Georgi Guninski's
cross-frame bugs. You can visit his page at
http://www.nat.bg/~joro/read2.html
to test. I tested this on 2 NTW 4.0 SP5 machines with IE 5.0 and all
released fixes. Georgi also confirmed his test machine is vulnerable again
after this patch." Microsoft is working on an updated
version of the IFRAME ExecCommand patch that will eliminate this problem.
The patch should be ready shortly, and when it's available, Microsoft will
update the MS99-042 and its FAQ.
On November 4, 1999, Microsoft released an update to
Security
Bulletin MS99-042 which discusses the availability of a new patch for
the "IFRAME ExecCommand" vulnerability. This new patch
fixes a regression problem in the original patch that opened up a
previously closed security hole. The regression problem only affects
the IE 5.0 version of the patch. IE 5.0 users can get the new patch
at:
On November 4, 1999,
Georgi
Guninski reported a problem with Internet Explorer 5.0 that allows a
remote user to read local text and HTML files and files from any domain.
The reading of other file types may be possible as well, and window
spoofing is also possible, as is reading files behind a firewall in some
cases. As Georgi explains on his
web
page, the vulnerability is within HTTP redirects to javascript URLs.
Georgi's web page also includes sample exploit code, as well as a
demonstration.
This problem has been reported to Microsoft. Until a patch is
available, the workaround recommended by Georgi is to disable Active
Scripting.
On November 8, 1999, computer virus researchers received an
anonymous email containing the code for a new type of Internet worm -
known as the Bubbleboy or VBS/Bubbleboy. This vulnerability affects
Outlook 98, Outlook 2000 or Outlook Express 5.0 running under the English
or Spanish version of Windows 95, Windows 98 or Windows 2000 systems that
also have Internet Explorer 5.0 and Windows Scripting Host (WSH) installed
(WSH is standard on Windows 98 and Windows 2000). This is a new type
of worm, in that it doesn't involve an attachment. The VBScript code
for the worm is embedded within an HTML email message. There are two
variants, .a (non-encrypted) and .b (encrypted). The worm is
activated when the email is opened in Outlook or Outlook Express, or
previewed in the Outlook Express preview pane. Previewing the
message in the Outlook preview pane does not cause it to execute.
The vulnerability has already been addressed by Microsoft in
Security
Bulletin MS99-032. Microsoft also released a separate
Bubbleboy
Virus bulletin. They've also had a patch available for this
issue since August 31, 1999. You can get the patch at one of these
locations:
On November 11, 1999, Microsoft released
Security
Bulletin MS99-048 and Knowledge Base article
Q244540,
which discuss the availability of a
patch
for the "Active Setup Control Vulnerability" in Internet
Explorer 4.0 and 5.0. This vulnerability, which was discovered by
Juan
Carlos Garcia Cuartango, exploits an ActiveX control that allows
cabinet (.CAB) files to be executed. A user could receive an email
containing malicious script which could be used to execute an attached
cabinet file. For more information on this, including special
instructions for IE 4.01 with SP1 users, see the
FAQ
that was released with the Security Bulletin.
On November 12, 1999, Microsoft released
Security
Bulletin MS99-049 and Knowledge Base article
Q245729,
which discuss the availability of a patch for the "File Access URL
Vulnerability" in Windows 95 and Windows 98. This
vulnerability, which was discovered by UNYUN, the Shadow Penguin Security
Research
Group of Japan, could allow a malicious web site or e-mail message to
crash Windows, or run arbitrary code. There is a buffer overflow in
the networking components of Windows 95 and Windows 98 that process file
name strings. If these components were fed a very long random string
as input, they could cause Windows to crash. If fed a
specially-malformed argument, it could allow arbitrary code to be run on
the machine. The vulnerability can be exploited remotely in cases
where a file:// URL or a Universal Naming Convention (UNC) string on a
remote web site included a long file name or where a long file name was
included in an e-mail message. You can get the patch at one of these
locations:
Windows 95:
http://download.microsoft.com/download/win95/update/245729/w95/en-us/245729us5.exe
Windows 98: http://download.microsoft.com/download/win98/update/245729/w98/en-us/245729us8.exe
Microsoft also released a
FAQ
for this issue.
Also on November 12, 1999,
Microsoft released
Internet
Explorer 5.01 for Windows 95, Windows 98 and Windows NT.
On November 14, 1999,
Georgi
Guninski reported a problem with Internet Explorer 5.0 and the Windows
Media Player that allows for the checking of the existence of local files
and directories. The problem is an error code returned by a Windows
Media Player ActiveX object when a file is attempted to be opened.
The ActiveX object returns "-2147220970" error in the ErrorCode
property when a file or directory does not exist but is tried to be
opened. A harmless exploit of this code can be found
here.
To protect yourself against this vulnerability, you can disable ActiveX
controls or set them to prompt before executing. Microsoft is aware
of this problem, but they have not yet released a patch.
On November 17, 1999, Microsoft
re-released
Security
Bulletin MS99-043 and Knowledge Base articles
Q244356
and
Q244357,
which discuss the availability of a patch for the "Javascript
Redirect Vulnerability" in Internet Explorer 4.01 and 5.0.
Microsoft has also updated their
FAQ
on this issue. You can get the patch at one of the following
locations:
http://www.microsoft.com/downloads
http://www.microsoft.com/msdownload/iebuild/jsredir/en/jsredir.htm
NOTE: The patch for IE 4.01 requires
Service Pack 2 in order to install, which you can get at
http://www.microsoft.com/Windows/ie/download/windows.htm.
On November 29, 1999, Microsoft
released Security
Bulletin MS99-051 and Knowledge Base article Q246972,
which discuss the availability of a patch
for the "IE Task Scheduler Vulnerability" present in Internet
Explorer 5. This vulnerability, which was discovered and reported by
Arne Vidstrom and Svante
Sennmark, could allow a malicious user to gain additional privileges
and create or modify files on a Windows NT machine. The
vulnerability, which is discussed in detail at the NTSecurity.NU
web site, only affects Internet Explorer 5 running on an NT 4.0
machine that have the optional (not installed by default) Offline Browsing
Pack component installed. The Offline Browsing Pack replaces the
Windows NT Schedule Service (ATSVC.EXE) with the Task Scheduler (MSTASK.EXE).
A vulnerability in the Task Scheduler allows for a privilege elevation
attack and could allow a user without administrative rights to execute
code on the local machine under the Local System security context.
The Task Scheduler controls who can submit scheduled jobs. The AT
utility, which is used to create scheduled jobs can only be run by an
administrator, and the Task Scheduler will only execute scheduled jobs
that are owned by administrators. However, if a malicious user had change
permissions to a file owned by an administrator they could modify the file
by turning it into a valid scheduled task and placing it in the
appropriate folder for execution. This would effectively bypass
security control mechanisms and would allow the task to be executed.
The patch eliminates this vulnerability by
digitally signing all AT jobs at creation time, and verifying the
signature at execution time. Microsoft has also released a
FAQ
for this security bulletin.
On December 1, 1999, Microsoft
released
Security
Bulletin MS99-054 and Knowledge Base article
Q247333,
which discuss the availability of a
patch
for the "WPAD Spoofing Vulnerability" present in Internet
Explorer 5. The Web Proxy Auto-Discovery (WPAD) feature in Internet
Explorer 5 enables web clients to automatically detect proxy settings
without intervention. The algorithm used adds "wpad" to the
fully-qualified domain name and removes subdomains until it either finds a
server answering the hostname or reaches the third-level domain. For
instance, web clients in the domain a.b.company.com would query
wpad.a.b.company, wpad.b.company.com, then wpad.company.com. In
international usage, the third-level domain may not be trusted. As a
result, a malicious user could set up a WPAD server and serve proxy
configuration commands of his or her choice. Only http traffic can
be re-rerouted by exploiting this vulnerability. Email, network and
other traffic would not be affected. In addition, if SSL is used to
encrypt the web traffic, the malicious user would be unable to decrypt the
data even if they could re-route it through their site. Microsoft
has also released a
FAQ
for this bulletin.
On December 8, 1999, Microsoft
released
Security
Bulletin MS99-050 and Knowledge Base article
Q246094,
which discuss the availability of a
patch
for the "Server-side Page Reference Redirect Vulnerability"
present in Internet Explorer 4.01, 5.0 and 5.01. This vulnerability
could allow a malicious webmaster to view files on the computer of a
visiting user, provided that they knew the path and filename. When
an HTTP server performs a server-side redirect, IE's security model checks
the server's permissions on the new page. Under certain conditions, the
server can create a reference to a client window that the server is
permitted to view, then use a server-side redirect to a client-local file,
thus bypassing IE's security restrictions. The end result is that a
malicious webmaster could view files on the computer of a visiting user.
Microsoft has also released a
FAQ
for this bulletin. NOTE: Microsoft produces security patches
for IE 4.01 SP2 and higher. If this patch is applied to IE 4.01 SP1,
a message erroneously appears stating that this fix is not needed. The
vulnerability does exist on IE 4.01 SP1 and earlier releases of IE 4.01.
If you are using IE 4.01 SP1 or earlier, you need to upgrade to the latest
version of IE to resolve this issue.
On December 10, 1999, Microsoft
issued a security warning to users of Internet Explorer 4.5 for the
Macintosh over the impending expiration of some digital security
certificates. According to Microsoft, some users won't be able to
shop or pass information in a secure fashion. After midnight, Dec.
31, users who are trying to shop on some Web sites may get this message: "Unable
to establish a secure connection. The information you view and send will
be readable to others while in transit, and it may not go to the intended
party. Continue loading this page?" Microsoft is currently
working on a fix for this issue. This particular problem only
affects people who have recently downloaded Outlook Express 5 - Macintosh
Edition and use Internet Explorer.
On December 22, 1999, Microsoft released
Security
Bulletin MS99-060 and Knowledge Base article
Q249082,
which discuss the availability of a
patch for the
"HTML Mail Attachment Vulnerability" present in the Macintosh
versions of Internet Explorer 4.5 and Outlook Express 5.0. This
patch addresses two issues:
- It eliminates a security vulnerability in the
Macintosh version of Outlook Express which allow attachments to HTML
messages to be automatically downloaded onto the user's
computer. By design, when an HTML message is received, the
content is downloaded onto the user's machine and processed.
However, attachments should not be downloaded unless the user
requests it. A bug in OE5 for Macintosh causes all content to
be downloaded, including attachments. This vulnerability does
not provide a way to launch the downloaded attachments.
- It provides replacements for digital certificates
which will expire on December 31, 1999. The patch provides
updated certificates, and adds support for X509 V3 certificates.
This does not represent a security vulnerability; the replacement
certificates and X.509 V3 support is being provided as a community
service.
Microsoft has also released a
FAQ
for this bulletin.
On February 16,
2000, Microsoft released
Security Bulletin
MS00-009, which discusses
the availability of a patch for the "Image Source Redirect Vulnerability"
in Internet Explorer 4.0, 4.01, 5.0 and 5.01. This vulnerability could
allow a malicious webmaster to view files on a visitor's computer. The malicious
webmaster would need to know exact path and filename of the file, and could only
view files that can be opened in a browser window. Exploiting this vulnerability
depends on timing; the vulnerability is only present if
particular actions happen within a narrow window of time. Most of the factors involved in the timing are under the
webmaster's control, and the needed
adjustments to exploit the vulnerability could be made if the malicious
webmaster is determined enough. However, if the visited site was in a Security Zone that
has Active Scripting disabled, the vulnerability could not be exploited.
The patch can be obtained at the following locations:
http://windowsupdate.microsoft.com
http://www.microsoft.com/windows/ie/security/patch5.asp
Microsoft has also release a
FAQ
with this bulletin. Microsoft will also be releasing a Knowledge
Base article for this issue shortly.
On February 18, 2000, Microsoft released Security
Bulletin MS00-011, which discusses the availability of a patch for the
"VM File Reading Vulnerability" in the Microsoft Virtual Machine
("VM") that ships with Internet Explorer 4.x and 5.x. This
vulnerability, which was discovered by Hideo Nakamura of NEC Tokyo, could allow
a Java applet to operate outside the bounds set by the Java sandbox. A malicious
user could write a Java applet that could read files on visitor's
computers. Like most similar vulnerabilities, the malicious user needs to
know the exact path and filename of a files before it can be read. The
download location of the patch depends on what build of the VM you have:
2000 series builds were shipped with IE4.x
3100 series builds were shipped with IE5
3200 series builds were shipped with IE5.01
Build
Number |
Shipped
With |
Status |
2000-2444 |
IE 4.X |
Vulnerable |
3000-3190 |
IE 5 |
Vulnerable |
3229-3234 |
IE
5.01 |
Vulnerable |
|
|
|
All other
values unaffected by vulnerability
|
You can use JVIEW at a command prompt to determine your
build number. Microsoft has also released a FAQ
with this bulletin.
On March 13, 2000 Microsoft notified it's Internet Explorer
Administration Kit (IEAK) users of a serious security problem that exists
when a user attempts to install the 128-bit security patch for Internet
Explorer 5.0, 5.0a and 5.0b on Windows 2000 as part of an IE5.0 IEAK
package. The original instructions for installing the patch
contained an incorrect parameter which, when used, caused older files to
replace newer files and subsequently breaking Windows 2000. Breaking
it so bad, in fact, that you can no longer log on the system.
Microsoft has documented this issue on their web
site and in Knowledge Base article Q255669.
If you use the IEAK, you can check your distribution packages by
following these instructions:
- Open your IEAK package in the IEAK Wizard and go to the Custom
Components screen.
- Examine each custom component. If you have included ie5dom.exe as a
custom component, check the command line switches for '/R:N /Q:A /N:V'
*OR*
If you don't have the IEAK Wizard available to you:
- Extract your custom IE 5.0x package by running this command line:
'ie5setup.exe /c /t:<path to an empty directory>'
- Browse to the directory. Open 'iesetup.cif' in Notepad.
- Look for a section like this:
[CUSTOM0]
SectionType=Component
DisplayName='128-bit Security'
URL1='Ie5dom.exe',2
GUID=128PATCH
Command1='Ie5dom.exe'
Switches1='/R:N /Q:A /N:V'
Type1=2
UninstallKey=''
Version=
Size=216
Platform=win95,win98,nt4,nt5,
Modes='0,1,2'
Details='128-bit Security'
Group=CustItems
Priority=500
UIVisible=0
- Examine for:
Switches1='/R:N /Q:A /N:V'
- If you have this switch listed, immediately freeze distribution of
this package.
On May 17, 2000, Microsoft released Security
Bulletin MS00-033, which discusses the availability of a patch
for three serious security vulnerabilities within Internet Explorer 4 and 5:
-
The "Frame Domain
Verification Vulnerability," which could allow a malicious webmaster to
read files on the computer of a visiting user.
-
The "Unauthorized Cookie
Access Vulnerability," which could allow a malicious webmaster to
access "cookies" belonging to a visiting user.
-
The "Malformed Component
Attribute Vulnerability," which could allow a malicious webmaster to
take whatever action they wish on the computer of a visiting user.
These three vulnerabilities are
unrelated to each other, although they all exist in the same .dll. Microsoft
has created a single patch that corrects all three. These are very
serious vulnerabilities:
-
Frame Domain Verification
Vulnerability. This was reported by Andrew Nosenko of Mead &
Company. When a frame is opened within a window, IE's security model
should allow only a parent window in the same domain to access the
data in the frame. However, IE fails to perform proper domain checking.
As a result, a parent window from another domain can open a frame containing
a file on the local computer, and then read it. The webmaster would
need to specify the specific path and filename before the file could be
read, however, only file types that can be opened within IE can be
read.
-
Unauthorized Cookie Access
Vulnerability. This was reported by Marc
Slemko. IE's security model restricts the reading of cookies to
sites within the originator's domain. However, with a
specially-malformed URL, it is possible for a malicious webmaster to gain
complete control over a visiting user's cookies. The user would need
to click a link in order for the webmaster to be able to access each
cookie. The webmaster would not be able to obtain a listing of the
cookies available on the visitor's system. The scope of this vulnerability
depends on what information is contained in the cookie. The type and
amount of personal information depends completely on the practices followed
by the site that placed created the cookie. In some cases, this
vulnerability may not present anything to be concerned about; however, if
you use secure web sites, or if you have purchased products or services over
the Internet, this could be an extremely serious privacy compromise. A
working example of this exploit can be found here.
-
Malformed Component
Attribute Vulnerability. This buffer overrun vulnerability was
reported by UNYUN, the Shadow Penguin Security
Research Group of Japan. The code used by IE to invoke ActiveX
components has an unchecked buffer which could be exploited by a malicious
webmaster, enabling them to run code on the computer of a visiting
user. The malicious webmaster could then take any action the user
could take, including adding, changing or deleting data; reformatting the
hard drive; or transmitting data to a remote system. This
vulnerability only occurs in under very specific conditions and only when
certain other attributes are specified. If a web site is in a IE
Security Zone that doesn't allow ActiveX components to run, this
vulnerability cannot be exploited.
Only Windows 95, Windows 98,
Windows NT and Windows 2000 running one of the following versions of IE are
vulnerable:
-
Internet Explorer 4.0
-
Internet Explorer 4.01
-
Internet Explorer 5.0
-
Internet Explorer 5.01
All affected users can download
the patch here.
Note: You must have IE 4.01 Service Pack 2 or IE 5.01 to install the patch. If
you are using earlier versions of IE, you may receive a message reading
"This update does not need to be installed on this system."
This message is incorrect; more information on this issue can be found in KB
article Q262509.
Additional information can be found in the following KB articles:
-
Q251108
and Q255676
discuss the Frame Domain Verification Vulnerability
-
Q258430
discusses the Unauthorized Cookie Access Vulnerability
-
Q261257
discusses the Malformed Component Attribute Vulnerability
Microsoft has also
released a FAQ
for this security bulletin.
On June 2, 2000, Microsoft released Security
Bulletin MS00-037 and Knowledge Base article Q259166, which discuss the availability of a patch for the
"HTML Help File Code Execution Vulnerability" within Internet Explorer 4.0, 4.01, 5.0 and
5.01. IE's HTML Help feature enables the launching of code via
shortcuts from within HTML Help files. If a compiled HTML Help file
(a .chm file) were referenced by a malicious webmaster, it could be used
to execute code on a visitor's computer without their approval. Once
executed, the code could take any action available to the user, including
adding, changing, deleting or transmitting data.
This vulnerability can only
be exploited if the HTML Help file resides on the user's machine or on a
network share accessible from the user's machine. Firewalls that
blocks NetBIOS can prevent HTML Help files on a network share from being
exploited, and implementing standard security practices can prevent the
this vulnerability from being exploited when the file resides on the
user's machine. In addition, this vulnerability requires Active
Scripting to be enabled in the Security Zone in which the malicious web
site resides.
The patch eliminates this
vulnerability by only allowing an HTML Help file to use shortcuts if the
help file resides on the user's machine. You can download the patch
from one of these locations:
- Internet Explorer 4.0,
4.01, 5.0, or 5.01 running on Windows 9x or NT 4.0:
http://www.microsoft.com/Downloads/Release.asp?ReleaseID=21705
- Internet Explorer 5.01 on
Windows 2000:
http://www.microsoft.com/Downloads/Release.asp?ReleaseID=21706
Microsoft has also released a FAQ
for this issue.
On June 5, 2000, Microsoft released
Security
Bulletin MS00-039 and Knowledge Base article Q254902, which discuss the availability of a patch for the
"SSL Certificate Validation Vulnerability" within Internet Explorer 4.0, 4.01, 5.0 and
5.01. This vulnerability, which was discovered and reported by the
ACROS Penetration Team of Slovenia, could enable a malicious webmaster to
pose as a trusted web site. There are two problems with the way
Internet Explorer handles digital certificates:
-
When an SSL connection
is made via an image or a frame, IE only verifies that the server's
SSL certificate was issued by a trusted root. It does not verify
the server's name or the certificate's expiration date.
Connections made via all other means validate properly.
-
If the initial
validation is made correctly, IE does not re-validate the certificate
when a new SSL connection is established with the same server during
the same session.
It would be very difficult
to exploit these vulnerabilities. In both cases, the malicious
webmaster would need to either poison the visitor's DNS cache or
physically replace the trusted site's server. Moreover, timing would
be especially crucial in the second case, as the malicious webmaster would
have to poison the DNS cache or replace the server during the gap between
the two SSL sessions.
The patch, which can be
found here,
also eliminates all vulnerabilities discussed in Microsoft
Security Bulletin MS00-033 (see above). Note: This patch
requires IE 5.01 to install; a version that supports IE 4.01 Service Pack
2 will be released shortly. If you attempt to install this patch on
other versions of IE, you will receive the message "This update
does not need to be installed on this system." This message
is incorrect; more information is available in Q254902.
Microsoft has also released
a FAQ
for this issue. In addition, CERT (the Computer Emergency Response
Team) has also issued an advisory
on these vulnerabilities, as well.
On June 29, 2000, Microsoft released Security
Bulletin MS00-042 and Knowledge Base article Q265258, which discuss the availability of a patch for the
"Active Setup Download Vulnerability" within Internet Explorer 4
and 5. This vulnerability, which was reported by the venerable IE
bug-finder, Juan Carlos Garcia
Cuartango of Spain, could enable a malicious webmaster to overwrite
files on a visitor's computer. The patch
corrects a vulnerability in the Active Setup ActiveX control included in
Internet Explorer.
The Active Setup Control
enables the downloading of cabinet files (.cab files) as part of the
install process for software updates. Cuartango discovered two flaws
in the control:
-
The control treats all
Microsoft-signed .cab files as trusted, thereby allowing them to be
installed without asking the user's approval.
-
The control provides a
method by which the caller can specify a download location on the
user's hard drive.
When combined, these flaws
allow a malicious webmaster to download a Microsoft-signed .cab file to a
visitor's machine, potentially overwriting files. It is even
possible that system files could be overwritten as a result of this
vulnerability, thereby rendering the visitor's system unusable.
Since the visitor's computer could be rendered unusable, this
vulnerability is classified as a denial of service exploit. While
Windows 2000 has the System File Protection feature to prevent this from
happening, it does not protect users against data files, such as Microsoft
Office documents and other application files, from being overwritten.
All Windows users running
IE4 and IE5 should get this patch.
Note: The patches require IE
4.01 Service Pack 2 or IE
5.01 to install. If you receive the message "This update does
not need to be installed on this system," see Q265258.
On July 13, 2000, Microsoft released Security
Bulletin MS00-049 which discusses a workaround for the
"The IE Script Vulnerability" within Internet Explorer 4.01 and
5.x. The IE Script Vulnerability can allow malicious script code on
a web page to reference a remotely hosted Microsoft Access database, which
can then be used to execute VBA macros. According to the FAQ
that accompanies this Security Bulletin,
"By default
Microsoft Access files are treated as unsafe for scripting; however, a
certain script tag can be used to reference an Access (.mdb) file and
execute VBA macro code even if scripting has been disabled in Internet
Explorer."
Internet Explorer allows the use of object tags for loading ActiveX
controls, which can be an executable or a Microsoft Office document, such
as an Access database. In the default Microsoft Office installation,
ActiveX controls load without prompting the user and execute any VBA code
within the document.
Although this is issue has been dubbed the "IE Script
Vulnerability," it has nothing to do with Active Scripting.
This vulnerability doesn't rely on scripting, so disabling scripting does
not prevent this vulnerability from being exploited.
One consideration is that this
vulnerability can be exploited within HTML e-mail without the recipient
having to open any attachments. Moreover, Microsoft Outlook, Outlook
Express, and other HTML mail readers have a preview pane feature that
displays HTML messages. Because Outlook and Outlook Express use IE's
HTML rendering engine, the exploit can execute just by previewing the
email. As a result, Outlook and Outlook Express users that run
Microsoft Access 97 or 2000 are at serious risk.
While a patch that
permanently resolves this issue has not been released, Microsoft has
provided a workaround to the problem. The workaround is to set an
administrator password for Microsoft Access. This causes Access to
prompt for this password before VBA code within an Access database
is executed. Specific instructions for doing this can be found in
the
FAQ
for this Security Bulletin. Microsoft Access 97 and Access 2000
users running Internet Explorer 4.01 SP2 or any variant of IE 5.x
are affected by this vulnerability.
A patch for this issue is in the
works, but in the meantime, Microsoft recommends that all affected IE users set an
administrator password within Microsoft Access. In addition, users
should make sure that File and Print Sharing (or any kind of Windows file
sharing) is not available via the Internet. Those of you with
firewalls should make sure that UDP port 138, UDP and TCP port 139, and UDP
and TCP port 445 (all outbound) are closed.
On July 18, 2000, Microsoft released
Security
Bulletin MS00-043 and Knowledge Base article
Q267884 which discuss the
availability of a solution for the "Malformed E-mail Header Vulnerability"
within Outlook and Outlook Express. The Internet Explorer component
Inetcomm.dll, which is shared by Outlook and Outlook Express, contains an
unchecked buffer in the functionality that parses e-mail headers.
A malicious user could exploit this vulnerability by sending an e-mail that
overruns the buffer, causing one of the following two
effects to occur:
- If the affected field were filled with random data, the
e-mail application could crash
- If the affected field were filled with carefully-crafted
data, the e-mail application could execute code
Outlook Express 4.0x and 5.0x users are
affected by this vulnerability; however users who have installed Internet
Explorer 5.01 SP1, and users who have installed Internet Explorer 5.5 on any
system other than Windows 2000, are affected by this vulnerability.
Similarly, Outlook users who only use MAPI services are not be affected,
regardless of what version of Internet Explorer is installed.
This vulnerability, which was discovered
and reported by USSR Labs and Aaron
Drew, can be eliminated by installing:
Windows 2000 users running IE 5.5 will need
to wait for Windows 2000 SP1 to correct this problem. Microsoft has
also released a
FAQ
with this Security Bulletin.
On July 20, 2000,
Microsoft released an updated version of
Security
Bulletin MS00-043 and Knowledge Base article
Q267884 which discuss the
availability of a patch for the "Malformed E-mail Header Vulnerability"
within Outlook and Outlook Express. The original Security Bulletin
recommend that affected IE users install one of two Service Packs in order to
eliminate the vulnerability. The July 20, 2000 update was released to
announce the availability of patches that eliminate the vulnerability.
This vulnerability can now be eliminated by taking a variety of actions:
Taking any of the above steps will also
eliminate the vulnerabilities discussed in
Security
Bulletins MS00-045 and
MS00-046
(see below).
On July 20, 2000, Microsoft also
released
Security
Bulletins MS00-045 and Knowledge Base article
Q261255,
which discuss the availability of a patch for the "Persistent
Mail-Browser Link
Vulnerability" within Outlook Express. This vulnerability could
allow a malicious user to send an e-mail message that would enable them to
"read over the recipient's shoulder" as Outlook Express displays
subsequent messages in its Preview Pane. HTML e-mail messages can
contain script code, which can be used to open a browser window that links
back to the Outlook Express windows. Script can also be used read HTML
e-mail that is displayed in Outlook Express. However, there is a
vulnerability that results because the link can be made persistent, enabling
the browser window to retrieve the text of messages displayed in the preview
pane. Once the text has been retrieved, it can then be relayed to a
malicious web site or user. Several significant restrictions prevent
this vulnerability from being ultra-dangerous
- The recipient has to first open the HTML
e-mail message in order to establish the link.
- The attack ends when the user either
closes the browser window, or exits Outlook Express.
- The malicious user could only read mails
that were displayed in the Preview Pane. If the Preview Pane is
disabled, they could not retrieve or relay any information under any
conditions.
This vulnerability can now be eliminated by taking a variety of actions:
Microsoft has also released a
FAQ
for this Security Bulletin.
On July 20, 2000, Microsoft also
released
Security
Bulletins MS00-046 and Knowledge Base article
Q247638,
which discuss the availability of a patch for the "Cache Bypass
Vulnerability" within Outlook and Outlook Express. This
vulnerability is somewhat serious for two reasons. First, a malicious
user could exploit this issue by sending an HTML e-mail message that, when
opened, could read files on the recipient's computer. Moreover, the
vulnerability can be used in tandem with other exploits, enabling it to be
used in more advanced attacks.
An HTML e-mail message that creates a file
on the recipient's computer should only be able to create it in an area
called the cache. Files in the cache are considered within the
Internet Zone. This vulnerability allow an HTML e-mail message to
bypass the cache altogether, and create a file in an alternative location on
the recipient's computer. If a file is created outside the cache, it
is considered to be within the Local Computer Zone. Once in this zone,
the HTML e-mail message could be used to open a file on the recipient's
computer and send it a malicious web site. This vulnerability could
also be used to store an executable file on the recipient's machine, which
could then be launched by some other mechanism.
This vulnerability can now be eliminated by taking a variety of actions:
Microsoft has also released a
FAQ
for this Security Bulletin.
On August 9, 2000, Microsoft released an update to
Security
Bulletin MS00-049 which discusses the availability of a
patch for the
"The IE Script Vulnerability" within Internet Explorer 4.01 and
5.x. Microsoft also released Knowledge Base article
Q269368 which provides details on the files that are affected by this
issue.
Microsoft also re-released Security
Bulletin MS00-55, which discusses the availability of a patch for the "Scriptlet
Rendering Vulnerability" within Internet Explorer 4.01 and
5.x. This
patch also corrects the IE Script Vulnerability discussed in
Security
Bulletin MS00-049.
On February 22, 2001, Microsoft
released
Security Bulletin MS01-012, which discusses the availability of a
patch for the "Malformed vCard vulnerability in the Outlook and Outlook
Express components responsible for processing vCards. According to
the Bulletin, by creating a vCard, editing it to contain certain data and
then sending it to another user, a malicious individual could take one of
two actions if the recipient opens the vCard. One action is to
simply cause Outlook Express to fail. If this happens, the recipient
can restart Outlook Express, delete the hostile email and remove the
problem. However, it is also possible that the attacker could cause
Outlook Express to run code of their choice on the victim's machine.
Such code could then take any desired action within the permission
boundaries of the machine. This vulnerability, which was reported by
Ollie Whitehouse of
@Stake, requires
the user to open the vCard in order for the vulnerability to be exploited.
Currently, there is no known way to cause a vCard to be automatically
opened by a recipient.
IE 5.01 SP1 and IE 5.5 SP1 users can
download the patch from
http://www.microsoft.com/windows/ie/download/critical/q283908/default.asp.
Read the
Security Bulletin for additional information about this issue.
On March 6, 2001, Microsoft
released
Security Bulletin MS01-015, which discusses a vulnerability in
Internet Explorer 5.01 and 5.5 that could allow a malicious individual to
determine the location of cached content on another user's computer.
Internet Explorer's security architecture allows for a caching mechanism
that is used for storing content that needs to be downloaded and processed
on the user's computer. The cache is supposed to conceal the physical
location of the cached content, so that access to the information can be
properly restricted.
However, as
Oliver Friedrichs discovered and
reported to Microsoft, it is possible
for a web page or HTML email to learn the physical location of cached
content. Once the location of cached content is learned, an attacker
could open cached content under the security context of the Local Computer
Zone. From there, they could launch compiled HTML help files containing
shortcuts to executables, which could then be launched by the attacker.
You can download the patch from:
On March 29, 2001, Microsoft released
Security Bulletin MS01-020, which discusses the availability of a
patch for Internet Explorer 5.01 and 5.5 for a vulnerability that
could allow an attacker to run code of their choice on the victim's
machine. Internet Explorer renders web pages and opens binary
attachments in a way that is appropriate to their MIME types.
Veteran bug finder
Juan Carlos
Cuartango discovered and reported a flaw in the type of processing
that is specified for certain unusual MIME types.
He found that 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 MIME types is handled
incorrectly, IE would launch the attachment automatically when it rendered
the e-mail. This represents an obvious security problem. By
exploiting this vulnerability, an attacker could host an affected HTML
email on a web site and wait for users to click it, or, they could simply
send the HTML email directly to the user.
Such code could then take any desired action within the permission
boundaries of the machine.
On October 10, 2001,
Microsoft released
Security Bulletin MS01-051, which discusses the availability of a
patch for Internet Explorer 5.01,
5.5 and 6.0. This patch eliminates three
vulnerabilities:
-
This bug involves how IE
5.01 and 5.5 handles URLs that include dot-less IP addresses (e.g., http://12345678912
versus
http://216.65.128.112).
If the request were malformed in a specific manner, IE would mistakenly
believe that the in the Local Intranet zone. This would enable
code on the site
to run with fewer security restrictions in place. IE 6 is not
vulnerable to this exploit. IE 4 was vulnerable to this issue back
in
1998. See also, Microsoft Knowledge Base article
Q306121 for additional details on this issue.
- This bug how IE handles URLs that specify third-party sites.
A malicious individual could create links using encoded URLs that cause HTTP requests
to be transmitted to a Web site as soon
as a connection to that site was established. The Web server
believes the HTTP requests are originated from the user, so if this
vulnerability was exploited a service-oriented site, the malicious
individual may be able to take action's available to the unsuspecting
user, including deleting or transmitting data.
- This is a newly discovered variant of a vulnerability discussed in Microsoft
Security Bulletin MS01-015.
IE enables you to launch telnet sessions within its process. However, when doing so, IE
can start Telnet using any
command-line options the web site specifies. When using the Telnet client that
ships with Microsoft Services for Unix (SFU) 2.0 on NT 4.0 or Windows 2000,
a vulnerability exists that provides an option for
creating a transcript of a Telnet session. Once this logging option
was invoked, a malicious individual could stream an executable file
onto the user�s system and place it in a location that would cause it to be executed
automatically the next time the user booted the machine. The telnet
client is operating properly; it is IE that should not allow Telnet to be
started remotely with command-line arguments.
On October
23, 2001, Microsoft released
Security Bulletin MS01-053, which discusses a vulnerability in
Internet Explorer 5.1 for the Mac. This vulnerability could allow a
downloaded MacBinary or BinHex file to execute upon completion of its
download. A
patch
for this vulnerability is available. For additional details, see
Microsoft Knowledge Base article
Q311052.
On November 8, 2001, Microsoft
released
Security Bulletin MS01-055, which discusses a vulnerability in
Internet Explorer 5.5 and 6.0 that enables a malicious webmaster to read
and alter cookies by "injecting a script."
By design Web sites should only be allowed to access its own cookies.
However, someone recently discovered a vulnerability whereby a
specifically formed URL can
allow a Web site to gain access to any cookie, and even modify the data in
a cookie. This is very dangerous because some Web sites hide
personal or sensitive data in their cookies, such as a password for entry
to the site. Unfortunately, at this time, no patch is available to
correct this issue because according to Microsoft,
"The
person who discovered this vulnerability has chosen to handle it
irresponsibly, and has deliberately made this issue public only a few
days after reporting it to Microsoft."
Microsoft is preparing a patch
for this issue, but in the meantime they recommend that you disable Active
Scripting in all Zones. The risk factor is
high
in all Zones except for the Restricted Zone which has Active Scripting
disabled by default. Details on how to do this can be found in the
Frequently Asked Questions section of the
Security Bulletin.
On November 13, 2001, Microsoft updated
Security Bulletin MS01-055 to include a link to the
patch that fixes the Script Injection Vulnerability.
On December 13, 2001,
Microsoft released
Security Bulletin MS01-058, which discusses the availability of a
Cumulative Patch for Internet Explorer 5.5 and 6.0.
- The first vulnerability affects version 6.0 only. It concerns
a flaw in how the Content-Disposition and Content-Type header fields in
an HTML stream are handled. Along with other data, these fields
determine what IE does with a file upon download. If a malicious
person altered the HTML header information in a certain way, IE might be
tricked into opening without the file without requesting confirmation.
CERT has also issued a
bulletin on
this vulnerability.
- The second vulnerability is a newly discovered variant of the "Frame
Domain Verification" vulnerability discussed in
Security Bulletin MS01-015. This vulnerability affects both IE
5.5 and 6.0.
- The third vulnerability involves the display of file names in the
File Download field. A flaw exists that could enable a malicious
person to alter the name of the file and potentially expose the browser
to unsafe HTML or other code. This vulnerability affects both IE
5.5 and 6.0.
Additional details can be found in Microsoft Knowledge Base article
Q313675.
On February 21, 2002, Microsoft released
Security Bulletin MS02-009, which discusses the availability of a
patch that eliminates another vulnerability that enables local files
to be read by a malicious Web site. The vulnerability, which was
reported by
Zentai Peter Aron at
Ivy
Hungary Ltd, enables a
Additional details can be found in Microsoft Knowledge Base article
Q318089.
On March 4, 2002, Microsoft released
Security Bulletin MS02-013, which discusses the availability of
version 3805 of
the Java Virtual Machine used by Windows and Internet Explorer. This
version eliminates two security vulnerabilities:
To find out what version of the Java Virtual Machine you have on your
system, go to a command prompt and enter JVIEW. The version will be
displayed. All builds up to and including build 3802 are affected by
these vulnerabilities. If you aren't running version 3805 or later,
you should install the patch.
Additional details can be found in Microsoft Knowledge Base article
Q300845.
On
March 28, 2002,
Microsoft released
Security Bulletin MS02-015, which discusses the availability of a
Cumulative Patch for Internet Explorer 5.01, 5.5 and 6.0.
- Incorrect security zone determination could allow a script within a
cookie execute in the context of the Local Computer Zone. This was
reported by Andreas Sandblad of Sweden.
- Incorrect handling of object tags could allow an attacker to invoke
any executable on the victim's machine.
If you are running Internet Explorer 5.01, 5.5 or 6.0, you should apply
this patch.
Additional details can be found in Microsoft Knowledge Base article
Q319182.
On May 15, 2002, Microsoft
released
Security Bulletin MS02-032, which discusses the availability of a
Cumulative Patch for Internet Explorer 5.01, 5.5 and 6.0.
- A cross-site scripting vulnerability in a Local HTML Resource.
IE includes several HTML files to provide functionality. One of
these files contains a cross-site scripting vulnerability that could
allow a script to execute and run in the local computer zone.
- An information disclosure vulnerability related to the use of an
HTML object that provides support for Cascading Style Sheets could allow
an attacker to read, but not add, delete or change, data on the local
system.
- An information disclosure vulnerability related to the handling of
script within cookies that could allow one site to read the cookies of
another.
- Two variants of the "Content Disposition" vulnerability discussed in
Microsoft
Security Bulletin MS01-058 affecting how IE handles downloads when a
downloadable file's Content-Disposition and Content-Type headers are
intentionally malformed. These were reported by
Jani Laatikainen and Yuu Arai
of
LAC SNS Team.
- Finally, it introduces a behavior change to the Restricted Sites
zone. Specifically, it disables frames in the Restricted Sites
zone.