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>Attachment:
pgpqFaL8K9rLc.pgp
Description: PGP signature