Comment by _urga | Hacker News Reader

Comment by _urga | Hacker News Reader

Parent Full thread

I wrote @ronomon/mime (https://github.com/ronomon/mime) as a strict fuzz-tested MIME parser in a memory-safe language to prevent similar attacks such as:

1. Malicious character encodings that can crash email clients such as Apple Mail.

2. Malicious RFC 2231 continuation indices designed to cause overallocation.

3. Base64 data containing illegal characters such as null bytes.

4. Unterminated comments and quoted-strings.

5. Missing multipart parts (e.g. no terminating boundary delimiter).

6. Malicious data designed to cause CPU-intensive decoding or stack overflows (aka MIME bombs, the email equivalent of zip bombs).

7. Malicious multiple occurrences of crucial headers and parameters, which could cause clients to render an email differently from that scanned by antivirus software.

8. Encoded words containing malicious control characters (cf. Mailsploit).

While it won't prevent this exact attack because it seems to be purely size-based, @ronomon/mime was able to detect attacks such as Tim Cotten's "Ghost Emails" Gmail hack [1] as well as recent CVEs reported against ClamAV [2] and SpamAssassin [3], which are variants of a MIME multipart attack I disclosed through Snyk, "How to crash an email server with a single email" [4].

[1] https://blog.cotten.io/ghost-emails-hacking-gmails-ux-to-hid...

[2] https://blog.clamav.net/2019/11/clamav-01021-and-01015-patch...

[3] http://mail-archives.apache.org/mod_mbox/spamassassin-announ...

[4] https://snyk.io/blog/how-to-crash-an-email-server-with-a-sin...

> as a strict fuzz-tested MIME parser in a memory-safe language to prevent similar attacks such as

As the "memory-safe language" appears to be JavaScript, which lacks integers, how does the parser safely handle the 7bit encoding that still comes out from a large variety of email hosts?

I just googled "email 7 bit encoding" and yeesh, that is gnarly (here's an explanation for anybody who's curious: https://stackoverflow.com/questions/25710599/content-transfe...).

However, I can tell you that JavaScript doesn't lack integers. It tries to make you think that numbers are just numbers, but if you store an integer in JavaScript it is represented as an actual integer. Equivalence checks work, there are even bitwise operators. It's only once a decimal is introduced that the representation changes to floating-point.

> Equivalence checks work, there are even bitwise operators.

That's not exactly proof that JS has integers. I mean you can still do this:

> 1 === 1.00000000000000000000000000000000000000000000001

JS implementations may use integers as an optimisation. The problem is when you need to sure something actually is an integer.

You can also have bitwise operations on doubles, you just take part of the number and toss away the rest, and pretend it's an integer. But occasionally, and unexpectedly, it may cause a rounding issue, depending on how it is done.

However, looking more into it, this library relies heavily on the Buffer [0] API from Node (which does have proper integers, and Buffer is a Uint8Array). Which handles 7bit data by treating it as latin1 (ISO 8859-1), and tossing away 1 bit of every byte. Which might not be a bad way of handling it.

I don't know enough about Node's particular implementation to judge whether or not there are problems here. I do know that 7bit encodings can break a whole lot of parsers in unexpected ways.

[0] https://nodejs.org/api/buffer.html

> I do know that 7bit encodings can break a whole lot of parsers in unexpected ways.

That would be interesting. Would you please share some unit test cases and I will run them past @ronomon/mime?

This is good work, thank you. I've added to my testing toolbox.

Reply on news.ycombinator.com