Even the best file-blocking plans and tools can be susceptible to at least one method of attack. Obviously, you can't block every file attachment and keep users happy, and an inherent risk exists in whatever files you must let users access. You can block 40 file extensions, but you'll have problems if the one type you let through contains malware. You can, however, defend against the most likely culprits.

More and more programs and data are being delivered over the Internet, and finding adequate file-blocking mechanisms for use with Web browsers is more work than blocking file attachments that arrive through email. Malicious JavaScript and VBScript code is difficult to stop, and each browser add-in (e.g., Shockwave Flash, Adobe Acrobat, Nullsoft Winamp) gives intruders an additional entry route. And file blocking rarely prevents buffer-overflow attacks, making that type of attack a popular choice with intruders.

Other increasingly popular intruder mechanisms are header malformation or MIME-type mismatches. With header malformations, intruders craft a file header with the purpose of causing an intentional problem such as a buffer overflow or Denial of Service (DoS) attack. MIME-type mismatches occur when an intruder intentionally confuses a client browser or add-in program by preparing the browser or program for one type of program (e.g., a text file), then delivering a different type (e.g., an HTML file). MIME-type exploits are often successful in getting around file-blocking mechanisms that check for the appropriate file type in the email or MIME header only and fail to reverify against the actual file delivered.

Another way to hide a malicious file's identity is to use the file's class ID (CLSID) in the filename. Most program files have a unique associated CLSID that registers the file with the Windows COM object handler. When a filename ends with a CLSID in brackets (\{\}), the bracketed portion often remains hidden (although several ways to verify the real file type exist, including viewing the file's Properties dialog box). For example, the CLSID for an HTML document is 25336920-03F9-11CF-8FD0-00AA00686F13. If you name an HTML file readme.txt.\{25336920-03F9-11CF-8FD0-00AA00686F13\}, the file will appear as readme.txt in many applications, even though the file is a valid HTML file and will execute as such. (The VBS.Postcard virus used this trick, disguising the file post-card.tif.vbs as post-card.tif.)

Some files' headers internally identify the file as a particular file type, so whether a user runs a file within an email client or saves the file to disk can make a difference in how it is handled and executed. For example, a Microsoft Word document, when saved to disk and opened through Windows Explorer, can be crafted to load in Word, regardless of the file's extension. However, a Word document that arrives as a Microsoft Outlook attachment must use the .doc extension to load in Word when run from within the message. Thus, a user might be fooled into saving a Word document called readme.txt to their local hard disk, thinking the file is safe to open when in fact it contains malicious scripting.

Finally, the advent of macros and scripts that can execute external commands has complicated file blocking. A Microsoft Excel macro can execute an external command such as format.com. An apparently safe .rtf file can contain a link that executes malicious code. And GUI skins that users might download can contain hidden mischievous scripting.