Hello, I have found a number of questionable security policies in Outlook 2002 which allow the "bad guys" to bypass some of the security features which where introduced in the Outlook security patch. These problems likely affect earlier versions of Outlook as well as Outlook Express. Here is the list of problems: Problem #1: In an HTML email message, Outlook will automatically download an executable file from a Web site whose URL is specified in an IFRAME tag embedded in the message. The download happens when the email message is read. Outlook will put up a dialog box asking a user if they want to open the file (i.e., run the executable), save it, or cancel the download. There is no security warning that the executable file might be dangerous. Unfortunately, the default action of the dialog is "Open". Recommendation: IFRAMEs should be restricted to HTML, image, and text files. If an IFRAME attempts to download another kind of file, then the file should be discarded. Outlook 2002 already discards executable files attached to an email message, so it should do the same thing with executable files in IFRAMEs. The dialog message is particularly confusing in Outlook since a user never initiated the download in the first place. (As a side note, Hotmail already offers this protection.) Problem #2: In an HTML email message, JavaScript code can still be executed in spite of the fact that scripting is turned off by default in Outlook. The trick is to embed the JavaScript code in either an "about:" or "javascript:" URL that is used an HTML <a href=> tag. When the link is clicked on, the JavaScript code in the link will be executed. In Outlook, URLs are limited to about 2,000 characters which is probably enough space to contain a simple worm which could exploit one of the known Internet Explorer security holes. Recommendation: about: and javascript: URLs should be disabled in Outlook. (As a side note, Hotmail already offers this protection.) Problem #3: Cookies can be set and read in HTML email messages in spite of the fact that the default security settings in Outlook 2002 claim that cookies are turned off. This is a privacy leak problem and not a security hole. For information of the implications of this leak, see http://www.computerbytesman.com/privacy/cookleak.htm. Recommendation: This is a software bug that just needs to be fixed. Problem #4: The Outlook and the Internet Explorer (IE) development groups at Microsoft just can't seem to agree how dangerous .URL files are. The Outlook group sees them as security threat, while the IE group does not. This disagreement makes the "Send a Link" command in IE cumbersome and confusing to use. If one emails a friend the link of a Web page using the command, IE generates an email message with the link in the body of the email message plus a second copy of the link in an attached .URL file. When the message is sent, Outlook proceeds to generate an annoying "security" warning dialog box saying that the attached .URL file might be dangerous. How a link to a Web page can be dangerous is mystery to me. The only option is to send the message with the "dangerous" .URL or abort the send. Outlook doesn't appear to have any method for removing a "dangerous" .URL file from an outgoing message. When I spoke to Microsoft about this particular issue last year, I was told that the Outlook group is concerned that a .URL file might point to a .EXE file instead of a Web page. The "bad guys" could use a .URL file then to download and run malicious executables. Recommendation: There are two solutions to this battle between the Outlook and IE groups. Either IE should stop generating .URL files in email messages or Outlook should be smarter about its handling of them. For example, Outlook can safely allow through a .URL file that points to a Web page, but reject ones that point to an executable file. Something needs to be done here because the current operation of the "Send a link" command is very confusing because Outlook is constantly "crying wolf". I brought all of these issues to Microsoft's attention over the last 12 months. I am not sure what Microsoft's plan are for addressing them. Problem #1 seems most critical. Richard M. Smith http://www.ComputerBytesMan.com
