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>
pgp7IUaHYZmLh.pgp
Description: PGP signature
_______________________________________________ balsa-list mailing list [email protected] https://mail.gnome.org/mailman/listinfo/balsa-list
