Michael Haardt wrote:
According to MIME, that's fine, but I am used to clients and scanners
recursively descending into message/rfc822 parts and I failed to find
anything describing that.
Changing the second Content-Type to message/rfc822 should generate an
error, because the "body" should be yet another header and a following
body. Right? Should I expect software to detect that error?
No, because the content-type is a "hint" at best, it does not dictate
the exact format of the contained data. Enforcing your expectations of
"well-formed" MIME parts will get you lots of false positives :)
I see the potential for an attacker to use 50 headers and a 100 kB body,
thus generating 50 message files, each a little over 100 kB, and 5 MB
in total to scan.
DoS attacks against inline scanners are always easy. You can get the
same effect with the infamous 42.zip file. :)
Does anybody know how other software works? To parse everything in a
linear fashion, you had to keep a stack of active boundaries. If any
boundary but the top matches, the MIME elements above are truncated.
Is that correct?
Yes. The current Exim implementation(s) are lazy in that respect and do
not carry a stack of boundaries, they only check for the last one (so
they expect well-formed messages). I want to improve on that in the near
future (there's another bug with B64 decoding that needs to be fixed).
/tom
--
## List details at http://www.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://www.exim.org/eximwiki/
