From time to time a vulnerability is found in a virus scanner that allows an attacker to disguise malicious content so that the scanner won't detect it but the virus is still fully functional. Much rarer are discoveries of new attack classes that are able to blindfold not one but many virus scanners. Here is one.
When sending files via e-mail they first have to be encoded in a special way so that they don't break the SMTP protocol, which was invented in a time when all e-mails were just plain text. The internet standard for this procedure is called Multipurpose Internet Mail Extensions (MIME). One method to do this is Base64 encoding in which every three bytes of input result in four bytes of output. While this makes the content larger the result will always be conforming to the relevant e-mail standards. As the name says, Base64 is made up of an alphabet of 64 characters, each representing a previously defined value.
Base64 encoding for MIME is defined in RFC 2045, which lists such an alphabet and clearly states: All line breaks or other characters not found in [the alphabet] must be ignored by decoding software. So it shouldn't make any difference if we insert some random characters not in the alphabet into a Base64 encoded version of our good old EICAR string, right? Wrong. Some virus scanners will happily pass viruses once they come in an unusual but still RFC-compliant encoding. This is even more astonishing given such attacks have already been discussed before.
Things start to get really nasty if some levels of multipart/mixed content are wrapped around the harmful attachment. Then, only one of the six tested virus scanners was able to detect the EICAR file. A simple perl script is provided as a proof of concept. You may have to play with the $loop variable, which controls the number of multipart nestings, depending on your virus scanner and mail server. Note that your mail client may not be able to properly decode the attachment as well (e.g. Gnus doesn't, but Mutt or Outlook will do the job).
1: "Less vulnerable" when using scan-mail.pl, which does not work with all mail servers. "Not vulnerable" if and only if the e-mail is passed to F-Prot with an .eml extension.
For large values of $loop, ClamAV prior to 0.88.7 even crashes due to a stack overflow, creating a denial of service attack. However, arbitrary code execution is probably not possible. Version 0.88.7 issues a warning when a multipart nesting level is exceeded, but still allows the EICAR string to pass if it is nested deeper than the limit. Using the "–block-max" configuration switch does not help either.
Virus scanners for other platforms are probably vulnerable as well.
A virus scanner listed here is unable to detect the EICAR string, however it reports that it could not properly scan the e-mail. The final action depends on the configured policy. Note that this behavior is only a result of deep multipart nesting and has nothing to do with Base64 decoding.
Use a separate daemon performing correct MIME decoding (e.g. amavisd-new). Note that not all mail anti-virus products provide the necessary command-line scanner.
If you have any information on other vendors' status, please let me know.
|2007-05-05||Update information on ClamAV 0.90.2 (thanks to Fabio)|
|2006-12-15||Updated information on F-Prot|
|2006-12-11||Added information on ClamAV update and a clarification to the "Less vulnerable" section|
|2006-12-11||Added information on Barracuda Spam Firewall (thanks to Paul Jacoby)|
Copyright 2006--2011 Hendrik Weimer. This document is available under the terms of the GNU Free Documentation License. See the licensing terms for further details.