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.ex