How to crash an email server with a single email (2018)

Better design would be not allocating any memory based on the message content and do parsing with callbacks or iterator approach.

Eh, there's a limit where it is not reasonable to continue parsing. I worked on the mailer for a huge webmail service, and it will at a certain point stop considering your inputs and respond with SMTP 5xx. Its just about knowing the limits of your software. If you knowingly write a recursive descent MIME parser then you have to also reason about the limits of how many stack frames you are permitted, or whatever limitations your language and runtime have. It's not OK to write such a parser and then just obliviously accept all inputs.

I wonder if the lazy nature of Haskell's Attoparsec parsing library would have prevented the issue by default (without needing to set-up a limit in the parser). I think it depends on how the resulting lazy structure is used, but it might be true that the person writing the parser may not need to worry in the least about it, since evaluation and resulting memory allocation would be up to the person that uses the result from the parser because of the language's lazy-by-default nature.

There are things that the parser must necessarily decide because nobody higher up the stack will understand them or think to limit them and override the default, even if a configuration object were to be exposed.

For example, one variant of this kind of MIME bomb would be defeated by a limit on the number of RFC 2231 parameter continuations acceptable per header. Even if you were to allow the user to override the default limit as you propose, your library would still need a sane default, because you would probably find that not many people would see RFC 2231 parameter continuations as a threat vector or even think to specify a limit, let alone know what a sane limit would be.

In the end, to be secure, you would have to expose so many limits that just using the library would be a mess.

As soon as you say "that's not for the parser to decide" you run the risk of things falling through the gap and no policy decisions being made at all.

You also have to accept that sometimes the parser designer alone knows best the complexity analysis of the resources the library will need.

Even tech companies such as Microsoft (https://blogs.technet.microsoft.com/exchange/2004/04/08/me-t... or https://www.businessinsider.nl/microsoft-employee-github-rep...) aren’t immune to that. The generic term for this kind of thing is “email storm” or “reply apocalypse” (https://en.wikipedia.org/wiki/Email_storm)

Usually you have a moderator that manually approves messages before they actually get sent to all members of a company wide distribution list.

We had a similar problem at my last company, where out boss sent a mail with his trip photos to the access limited everyone@ list - so our mailserver had a good 2 hours downtime while filling 2k email boxes with 20MB of attachments...what a mess

This isn't really a garbage collection problem. Any runtime using the same basic code would allocate system-crushing amounts of RAM, which is a problem on its own regardless. This will cause other problems for other memory allocation techniques, such as this being a great recipe for fragmenting all of your RAM, and still having a fairly slow deallocation process due to sheer number of objects being churned.

The real problem here is that where a streaming parse is called for, a parser that fully manifests all the objects in RAM was used. Streaming parsers remain relatively rare.

(It's actually a legit advantage of the XML library infrastructure; they're readily available there, though typically you'll be using them directly because the libraries that build further layers of abstraction on parsing often concretely manifest everything in RAM anyhow....)

Github returns:

> There isn’t anything to compare. We couldn’t figure out how to compare these references, do they point to valid commits?

It's because HN parsed the right angle bracket as part of the URL, so Github is looking for the branch/tag "v2.3.0>", which doesn't exist.

Same issue with your other link. snyk.io returns:

> Invalid vulnerability. This vulnerability does not exist.

The correct links are:

https://github.com/nodemailer/mailparser/compare/v2.2.0..v2....

and

https://snyk.io/vuln/npm:mailparser:20180625

They used to.

This would have been in early 2000's, when all the major AV products - particularly those doing mail gateway scanning, were vulnerable to them. At first it was a zip attachment, expanding to several GBs. That got patched. Then it was bzip2. That got patched. By the fourth iteration, the companies finally caught up with what was being done and took active countermeasures in their software to protect themselves.

One of the first ones I remember was to limit the unpack memory and if the attachment was getting allocated too much, give up. If I recall correctly, it took a couple of weeks before malware authors came up with the idea of padding their executable payloads with a few tens of megs of leading NOPs...

Yes, they are still a thing, especially with David Fifield's variant, but even with simpler zip bombs. You would be amazed at what can crash an antivirus engine.

Coincidentally, https://github.com/ronomon/zip can catch David Fifield's zip bomb.