[Off-Topic] GMime and MIME misuse by attackers

Hi Jeff:

I would like to draw your attention to this talk [1] which has been presented at the this years' IT Security Congress of the German Federal Office for Information Security (Bundesamt für Sicherheit in der Informationstechnik, BSI).  It basically deals with methods for evading security systems by abusing unclear or contradictory definitions as well as incomplete or sloppy implementations of the standards, inter alia for MIME (slide 18 ff).  Unfortunately, the slides are in German, but (some) further information is available from [2].

I think I mentioned a while ago that I try to use GMime in a project which is not a real MUA, but among other tasks tries to classify messages as benign, spam, malicious, etc.  Therefore, it would be important to know if and how GMime detects such attacks, and how I could retrieve more information about them.

I made a few tests with Balsa (which is using GMime 2.6, though, so the situation /may/ actually be different for GMime 3.0) by manually tweaking a MBox file, and found the following results:

- re. slide 20 and [3] (contradictory MIME boundary):
   “Content-Type: multipart/mixed; boundary=bb; boundary=##”: Balsa shows a multipart/mixed with an empty text document
   “Content-Type: multipart/mixed; boundary=##; boundary=bb”: Balsa shows a multipart/mixed with a 'virus.zip' attachment

- re. slide 21 (unexpected line folding):
   Balsa detects and decodes the base64 properly, i.e. no problem should arise here

- re. multiple Content-Transfer-Encoding headers [4]
   GMime seems to use the last definition, i.e. if base64 is the first one, the content is not decoded, but it is if it is the last one

- re. slide 30 (contradictory content type)
   Balsa sees no content at all regardless of the order of the conflicting headers

- re. slide 32 ('=' inside Base64 block)
   Balsa sees only “VI“

As an interesting side note to the last test, feeding the base64 block into g_base64_decode() *does* return “VIRUS!” (i.e. it accepts the “multiple” base64 blocks, glueing the results together), whereas using GMime's g_mime_encoding_init_decode() plus g_mime_encoding_flush() produces “VI\x00RUS!” with a NUL byte inserted at the position of the embedded “=”.

I don't know if these techniques have already been observed in the wild.  However, given the fact that even several of the most advanced security appliances are blind for these attacks, IMO it would be great if the GMime parser could provide information about the aforementioned (and other) errors being detected.  This would be extremely helpful for my “scanner” project, but also for a MUA (like Balsa) which could show an information that the message is broken and might be an attack.

What do you think?

Cheers,
Albrecht.


[1] <https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Veranstaltungen/ITSiKongress/15ter/Vortraege_17-05-2017/SteffenUllrich.pdf?__blob=publicationFile&v=2>
[2] <http://noxxi.de/research/semantic-gap.html>
[3] <http://noxxi.de/research/mime-conflicting-boundary.html>
[4] <http://noxxi.de/research/content-transfer-encoding.html>

_______________________________________________
balsa-list mailing list
[email protected]
https://mail.gnome.org/mailman/listinfo/balsa-list

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQEcBAABCAAGBQJZ4gdPAAoJEEypbw5n59n4BxoIANsWuv1IqHggqosyysxqIwiv
IYTUvjYRrfGqjUWpbqJ4BZcHX8wnhf3Gj1hOsKDK7Zv3WWfuP3iSGVb7KVxz7lmU
wPjDOyCOB2qg4DF5zkL+/WtJDoyWNlzeBhod66qccscbdW0UFEl3Tz9oYsoNQv9y
zso3gfCKkTAQZa2j1s2hu4oFpzuEiq7PmUet8BCmQ73s/1uaJc/VHLnc7Iqr7Hgy
DZW57ACxVUu0ycvUB2eDTHwgCC/YXjlOnRlPIpYxHL9w4G86UuE7VRwWo+f6t4TB
FNILZ6nXhnJRIK1zwuR0NcwZ36cHHUN1uKJ/SUdq8cbHDoH34cqjM4AsM6X9xU8=
=9yXD
-----END PGP SIGNATURE-----