July 2015

Please note that republishing this article in full or in part is only allowed under the conditions described here.

Dubious MIME - Conflicting Multipart Boundaries

Summary

Because of different interpretations of standards in standalone and web mail clients, IDS/IPS and antivirus products, it is possible to pass malware undetected to the end user. This is especially dangerous if different interpretations happen inside a single product, like happened in GMX Web Mail (fixed).

What is this about?

In the beginning e-mail was plain ASCII. To add the possibility so use something else than ASCII and to attach files MIME was created. This made is possible to add the required functionality while still maintaining compatibilty with old e-mail by mapping all the shiny features to plain ASCII for transport and back in the client.

A typical mail with a binary attachment looks like this: 

     From: foo
     To: bar
     Subject: foobar
     Mime-Version: 1.0
     Content-type: multipart/mixed; boundary=barfoot
   
     --barfoot
     Content-type: text/plain
   
     This is only ASCII text, but the attachment contains an image.
     --barfoot
     Content-type: image/gif
     Content-transfer-encoding: base64
   
     R0lGODlhHgAUAOMJAAAAAAgICAkJCRUVFSEhIfDw8PLy8vX19fj4+P//////////////////////
     /////yH5BAEKAA8ALAAAAAAeABQAAARaMMlJq7046827/2DoFQBQcKRJpWfCSm8Vw2VrzROOr/Xd
     57/YzvWjqYjHYarEZLaERWBz+vwZAgKD72isHg+DwWFrQ3pbCAIBQeYloxhdEH6Rv+/lrvusF3ki
     ADs=
     --barfoot--

The Content Transfer Encoding of base64 is used to map the bytes of the binary image to ASCII (for evasion in this area see Dubious MIME - Conflicting Content-Transfer-Encoding). And to declare the mail as consisting of several parts (the plain text and the image attachment) and mark the boundaries between the parts the Content-type is defined as 'multipart/mixed' and 'barfoot' is defined as the boundary around the parts.

Violating the specification

Of course it makes no sense from the perspective of a sane user to declare multiple boundaries. But it is possible. Thus from the view of an attacker it makes only sense to try it and see how different systems handle it and if evasion might be possible. We take as example the following mail: 

     From: foo
     To: bar
     Subject: eicar - conflicting boundaries
     Mime-Version: 1.0
     Content-type: multipart/mixed; boundary=foo
     Content-type: multipart/mixed; boundary=bar
     
     --foo
     Content-type: text/plain
     
     --bar
     Content-type: application/octet-stream; name=eicar.com
     Content-Transfer-Encoding: base64
     
     WDVPIVAlQEFQWzRcUFpYNTQoUF4pN0NDKTd9JEVJQ0FSLVNU
     QU5EQVJELUFOVElWSVJVUy1URVNULUZJTEUhJEgrSCo=
     --bar--
     --foo--

How this mail gets interpreted depends on which boundary is used. If the first boundary 'foo' is used the client will see a single text/plain part with the following garbage content: 

     --bar
     Content-type: application/octet-stream; name=eicar.com
     Content-Transfer-Encoding: base64
     
     WDVPIVAlQEFQWzRcUFpYNTQoUF4pN0NDKTd9JEVJQ0FSLVNU
     QU5EQVJELUFOVElWSVJVUy1URVNULUZJTEUhJEgrSCo=
     --bar--

But if the second boundary 'bar' is used, then the client will instead the an attachement named 'eicar.com' which contains the Eicar test virus.

Observed Behavior: Mail clients, Web mail, MTA, IDS

Like expected, the interpretation differs between the clients. All of the following detailed results are based on tests done in 06/2015.

The first boundary 'foo' is used by:

The last boundary 'bar' is used by:

About half of the scan engines at virustotal.com are able to handle mail messages:

fail: GMX Web Mail

While GMX Webmail uses the second boundary for display and download of attachment, the virus scanner used the first boundary. The issue was reported to GMX in 06/2015 and fixed within a few weeks.

Conclusion

Expect attackers to make creative use of standards. If in doubt reject or normalize the data but don't let it pass unchanged.