Notes taken by Matt Power, mhpower@mit.edu
Richard M. Smith is involved with research on computer-security issues in client-based software. His main focus is on Windows systems (he uses Windows 98 himself) and many of the security issues are in mail-reader applications (such as Eudora and the various mail software distributed by Microsoft and Netscape).
One timely issue involves the computer-security concerns with the alleged presence of classified information on a laptop computer in the home of John M. Deutch, former Director of Central Intelligence. In this case, the laptop computer was a Macintosh and the alleged incident took place in 1996. Smith felt that due to the computing platform and the risk levels at that time, there was "not a lot of danger", and he estimated that there was a "one in a million chance" that the laptop was compromised.
Shortly into the discussion, someone pointed out that we were caught on camera. Jeff Schiller commented, "that's the first thing I noticed when I entered the room."
A much higher risk level is currently associated with Windows PCs that are configured as clients (no server software in use) and are, for example, located in persons' homes. Smith indicated that he knew of no way to send IP data to this type of PC such that the supplied data would (in part) be directly executed by the Windows system without user intervention. For example, he does not know of a way to compose malicious IP packets such that any portion of the packet data would be executed directly by the Windows TCP/IP stack.
Breakins to Windows PCs are, however, likely to occur in some cases by transmitting the malicious content via e-mail. This, of course, requires that one know an e-mail address of the user of a Windows PC.
Another person involved in research on Windows mail-reader security is Georgi Guninski from Bulgaria. One attack approach that Guninski has written about involves the ability of some ActiveX controls to write to files. The ActiveX control can be referenced in an e-mail message and will in some cases be automatically executed by mail-reader software. A specific example is that one can write a file to the Start group, and the Windows system will execute that file upon the next boot. In general, the two main classes of exploits are those that can be used to read files off the victim's hard drive, and those that can be used to run arbitrary programs on the victim's machine. (Obviously the latter class is a subset of the former.)
In many cases, exploits of this type are specific to a particular mail-reader software version. To select the correct exploit for a particular intended victim, it is useful to know what mail-reader software is used by that person. Nearly all such software is also able to send e-mail, and will in most cases put the software-product name and version number into a header line in each outgoing e-mail message. Therefore, if one can arrange to receive a piece of e-mail from the intended victim, one will often then immediately know the exact software in use. However, often this is problematic in that, for some intended victims, to send one a response to an e-mail message would be highly unlikely.
Instead, a good guess about the mail-reader software can be obtained based on other information that can be obtained more easily. One approach is to send the victim an e-mail message that contains what is known as a webbug or tracking GIF. This is a URL referring to an image file that would be retrieved from a web server, presumably one operated by the sender, at the time that the e-mail message is displayed. The sender can then consult the web server's log files to obtain information about the victim's web browser and operating-system type. (The victim's IP address is also sometimes revealed, which can be useful in some cases. The available client IP address may, however, be that of a web proxy server. Kevin Fu suggested that it might be valuable to use a gopher URL rather than an http URL, in case the victim's machine is configured to use a proxy server only for http URLs.)
One possibility is an exploit that results in the ability to force the victim's machine to divulge the timestamp listed for any file on that machine's hard drive. These timestamps will often be sufficient to determine exactly what patches are installed on that machine. Using that information, a more damaging exploit can be constructed that is usable for attacking a machine that has that particular set of patches.
Some exploit programs might result in a warning box popping up giving the user an option to click in order to grant the required privileges (required trust level) to the exploit program. Many users would not choose such an option. However, it is possible that if the warning box keeps popping up again each time the user chooses not to grant the privileges, the user might eventually give up and allow the privileges, solely to avoid the annoying pop ups.
Another option is to use, as the basis of the exploit approach, a signed ActiveX control supplied by the PC's manufacturer (or another trusted vendor) that is automatically trusted with full execution privileges. One example is "Selective Quickrestore" which exists on some PCs manufactured by Compaq; another is "Launch" which exists on some PCs manufactured by Hewlett-Packard.
One possible way for manufacturers to block this exploit method is for the ActiveX control to refuse to run except in the context of the specific web pages intended by the manufacturer. The problem with this approach is that a lot of ActiveX software development is outsourced and the ActiveX control authors do not know what web environment will ultimately be intended by the PC manufacturer, and therefore are unaware of what security concerns would be relevant. Jeff Schiller suggested that the handling of security concerns is better suited to the developer of the larger application (i.e., the programmers who develop the mail-reader software or the combined mail-reader/web-browser software).
Currently, the trusted ActiveX control problem is being addressed by having only a limited number of ActiveX controls marked safe for scripting. On a typical PC sold nowadays, about a thousand ActiveX controls exist, and about 50 to 100 are marked safe for scripting. (The ones not marked this way would not be usable for an exploit embedded in an HTML document.) However, the exploit possibilities will likely continue to exist until the current 50-100 number becomes much smaller. For example, on Windows 98 systems, there is an ActiveX control that is able to create or overwrite arbitrary files (although it does not have the ability to put arbitrary content into files).
Other exploits use the concept of a "Lurker Window". Here, a window (usually one that is not visible and accessible via the normal mechanisms) remains present for a long time and has a program running that (for example) communicates with a server controlled by an attacker. The program might, every five seconds, ask the server what file it would like sent from the victim's hard drive, and then transmit that file to the server.
For an even longer-term exploit program, an initial exploit can cause the Windows registry to be modified such that a program will always be started at boot time. Also, an initial exploit can modify the privilege/trust settings on the victim's machine such that programs of a certain origin are always trusted with full privileges.
As a more general solution to these problems, it would be valuable if Javascript, Java, and ActiveX could all be turned off (preferably as the shipped default) in all mail-reader software. Currently, users of some software packages only have the option of turning off these capabilities for both mail reading (where the capability is not needed and probably not ever desired) and for reading web pages (where the capability is often needed).
Smith suggested that he may later contact the certificate authority that issued digital certificates used for signing ActiveX controls that result in important security vulnerabilities, and request that the certificates be revoked. He believes this is reasonable in that the certificate was issued with the understanding that it must not be used to sign any malicious code. Jeff Schiller pointed out that major certificate authorities likely disclaim all responsibility for authentication of malicious code. He mentioned that the only revocations he knows about were done in cases of signed ActiveX controls that were written specifically as demonstrations of ActiveX security problems.
Another type of exploit approach involves an HTML document containing an IFRAME within which Microsoft Word (or Excel) can run. This potentially gives an attacker the ability to run exploit programs via Word macro viruses.
There is also a potential vulnerability area related to URLs beginning with "money:". These have some function on systems that have Microsoft Money installed. Smith believes that investigating the potential Microsoft Money vulnerabilities (which could conceivably involve transferring funds from one account to another) is a useful research area.
Yet another class of vulnerabilities are those that exploit buffer overflows in ActiveX controls. One published vulnerability has demonstrated the ability to execute an arbitrary program via a buffer overflow in an ActiveX control related to the Adobe Acrobat reader.
A question for Smith was why he read his mail using Outlook, when he knows there are many vulnerabilities affecting Outlook. Smith responded by saying that Outlook can, according to his current knowledge, be run safely if appropriate security restrictions are set up. He normally has these set up at all times except when giving security demonstrations such as today's.
The issue of the recent CERT advisory regarding cross-site scripting came up. Jeff Schiller indicated that he had worked with CERT on the preparation of this advisory. One issue is that there are difficulties with filtering out HTML tags from content that is supposed to be plain text, due to the many possible encodings of characters. For example, to filter out (or escape) the '<' character would involve matching a multi-character sequence if the UTF-7 encoding were used.
There was a question about whether Windows NT would be safer for mail reading than Windows 98. Smith said that one safer aspect would be that programs run by unprivileged Windows NT users could not alter arbitrary registry entries.
There was a question about whether it is useful for an organization to try to block all active content in e-mail at its mail servers, as long as the mail servers were fast enough to convert the encodings used for all incoming messages, and as long as the organization were willing to block some legitimate e-mail. Smith said that this would, in general, be a good solution for many small companies, since it is simpler to enforce a restriction at the level of a mail server than to enforce a restriction on the configuration of every employee's desktop PC. He added that restricting incoming e-mail in this way would likely not be a good solution at MIT. Also, he pointed out that there are problems with denial-of-service attacks on mail servers that attempt to do this filtering. For example, an attacker could sent a small compressed file that uncompressed to 10 gigabytes of data consisting of only the '0' character. There was an evaluation of all popular mail-filtering products and all of them had this denial-of-service problem. (Of course, in theory the problem could be avoided by imposing resource limits on the filtering of each e-mail message.)