S 4.199 Avoiding problematic file formats

Initiation responsibility: Administrator, IT Security Officer

Implementation responsibility: Administrator, User

Today e-mail is the most significant means of transmitting malicious software. A purely text-based e-mail without attachments is harmless. An e-mail only poses a threat if attachments are executed, if the e-mail is based on HTML, or if the mail recipients are lured to visit manipulated websites via links contained in the e-mail (see below). In principle, e-mails can have any type or number of attachments attached to them. Too many attachments can impact the availability of an e-mail client or the e-mail server (see T 5.75 Overload due to incoming e-mails). But the most serious danger is attachments that contain executable code and hence can trigger unexpected side effects.

Attachments

Attachments containing executable code can trigger unexpected side effects. For this reason, rules must be established for dealing with file formats that are viewed as potentially problematic. It is important that all those concerned are aware of the problem and handle these file formats with an appropriate degree of caution.

In order to provide protection against unintended execution of malicious code, the e-mail clients should be configured in such a way that attachments cannot be accidentally executed. Instead, the program should warn the user prior to execution of the attachment or, as a minimum, ask the user to confirm whether the file should be opened. The operating system or e-mail client should, moreover, be configured in such a way that files are initially displayed only in a viewer or some other means of presentation without any programming code that may be contained in the files, such as macros or scripts, being executed.

If a user receives an e-mail with a potentially dangerous attachment, he/she should ensure that the source of the e-mail is trustworthy. This can be realised by using cryptographic signatures by the sender and by appropriate verification of the signature by the recipient. The sender of potentially dangerous attachments should also ensure that his/her attachment is not actually dangerous. As a minimum, this includes a scan with a virus scanner with up-to-date malicious code signatures.

Problematic file formats

A number of different rules can be established for dealing with file formats that are viewed as potentially problematic. However, it is important in every case that all those concerned are aware of the problem and handle these file formats with an appropriate degree of caution.

The most restrictive option is to forbid opening of all file formats viewed as problematic or else to filter them out on the e-mail gateway. However, experience suggests that this procedure is extremely unpopular with customers and employees. Generally speaking, it is better on the one hand to make staff aware of the problem and encourage them to act with caution, and on the other hand to provide technical support by minimising the potential danger through appropriate configuration and security tools (see also S 2.224 Prevention against malware and S 5.69 Protection against active content).

An assessment is provided below of various file formats. This could, however, change at any time if, for example, a manufacturer were to add new features that have unplanned side effects to its product or if some boffin were to find out about such side effects.

• The ASCII, GIF and JPEG formats have been largely harmless up to now.

• The following file formats should be treated as potentially dangerous: all the file formats used by office packages such as Microsoft Office, Star Office or Open Office that have an integrated macro language, e.g. Word, Excel, Powerpoint (.DOC, .XLS, .PPT, ODT etc.), and all documents containing interpretable/executable code, such as PDF, CHM. Particularly critical are all executable programs (e.g. .COM, .EXE, .PIF) or script languages (.VBS, .JS, .BAT under Windows, and Perl or shell scripts under UNIX), registry files (.REG) and screensavers (.SCR).
  
  As a precaution, a "non-dangerous" standard application should be specified with which all these file types may be opened but within which any computer viruses cannot trigger any harmful effects. For example, file types like *.VBS, *.JS or *.BAT should as a matter of principle be opened using a simple text editor that is not capable of running any macros.
  
  Moreover, Windows operating systems should be configured so that the standard procedure specified for registry files (.REG) is Edit rather than Merge. This means that files are initially presented in an editor, and are not added to the registry database when activated.

• The following file types are normally not a problem as long as additional measures are implemented: HTML, as long as a JavaScript filter or other security precautions are implemented, RTF (with COM object filter), ZIP (however, the user should be warned that the files contained could be problematic), PDF (as long as PDF Reader is installed as the standard and not Adobe Acrobat).

A compressed file sent as an attachment can turn out to be an e-mail bomb that generates large amounts of subdirectories or requires large amounts of disk space upon extracting. Archives, i.e. files compressed using compression programs, should never be extracted without being checked beforehand. This includes inspecting the index for type and size of the compressed files and checking for malicious software. Self-extracting archives, i.e. archives with extensions such as *.EXE, should never be opened, as it is not possible to check the content prior to extraction.

HTML mails

More and more e-mails are formatted in HTML these days. On the one hand this is often annoying, as not all e-mail clients are able to display this format. On the other hand unwanted actions can also be triggered when such e-mails are displayed on the client, as HTML e-mails can contain embedded JavaScript or Visual Basic script code.

Images embedded in the HTML source text can be used to provide feedback from the e-mail client to the spammer. If the embedded image is reloaded from the source in the Internet because the e-mail is displayed, the spammer knows that his/her e-mail has been read and thus receives confirmation that the recipient is valid and reads spam e-mails. Automatic reloading of HTML objects should be disabled in the e-mail client.

There have been many cases in the past of HTML-formatted e-mails causing security problems through a combination of security gaps in e-mail clients and browsers (see also T 5.110 Web bugs). Amongst other documents, the CERT-Advisory CA-2001-06 contains an example of this (at http://www.cert.org/advisories/CA-2001-06.html).

You should therefore avoid sending HTML-formatted e-mails or e-mails that have active content. Moreover, the possibility should be examined of filtering out active content in incoming e-mails, for example, on the firewall.

Furthermore, e-mail clients on which HTML-formatted e-mails can be recognised as such should be chosen so that the user does not open them unintentionally.

Generally, rules should be established within the organisation regarding the handling of HTML-formatted e-mails. Where HTML-formatted e-mails are received, the organisation should consider whether these

• should be passed on unchanged to the users and train the users so that they are aware of the dangers and handle such e-mails in a responsible and prudent manner;
• should be converted to pure text format with the aid of server-side tools and then be forwarded to the users with an appropriate message (however, this could mean that some information is lost);
• are not sent directly to the users but to a special workstation where they can be inspected by the recipient with special security precautions in place. (However, if the volume of e-mail is high, this may entail an unacceptable level of additional work for the users.)

As a matter of principle, all users should be made aware of this problem.

To err on the side of caution the e-mail client can be configured so that it displays e-mails as text only as a standard.

Review questions:

• Are there rules for handling HTML-formatted e-mails and for dealing with file attachments of e-mails?