Internet Explorer Security Issues (1996-1999)

Microsoft Internet Explorer

Security Center

 

About
Sources
Safety/Security
IE Security
MS Info
Misc
Home

What Security Issues are Known So Far?                  Click here for issues from the year 2000.


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):

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 IssueNote: 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, 1999Juan 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 siteIf 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, 1999NOTE: 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 WindowsUpdateNOTE: 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: