"Archives: Filename Rules" is being bypassed by badly formatted Content-Type header
mailbag at partnersolutions.ca
Wed Sep 2 16:03:13 UTC 2015
Hello, World! (aka, MailScanner list..),
I had a batch of viruses come through yesterday within a zip that managed to bypass our checks in "Archives: Filename Rules". My rule file is configured to not let .exe attachments through, even if they're in zip files, which has been working fine up until this specific message (to my knowledge, at least). After putting MS in debug on a test server and uncommenting a lot of the print to STDERR's, it turns out that there's an extra newline in the Content-Type header right before the name= segment. When this is found on a separate line, the attachment isn't decoded and is stored in the work folder in the original base64 format. I wasn't able to track where this was happening specifically, but I'm guessing it's with MIME::Parser under Explode(). The files are named nmsg-<PID>-<attachment #>.dat. Since the attachment isn't properly decoded, UnpackZip() fails to extract the content and it gets sent happily on its way.
This happened to me with MS 4.84.6 on CentOS 6.7, but it also happens on 4.85.2 (validated this morning). I've tested it against perl-MIME-tools 5.427 from the base CentOS repo, as well as 5.503 from FSL's old MailScaner gold repo. I haven't had a chance to confirm against the latest 5.506 from CPAN, though.
Broken header that skips the extraction:
Working header that properly extracts:
Content-Type: application/x-zip-compressed; name="7636557481_Trantow-Deckow_Jewel Mosciski.zip"
Has anyone else run into this or have more time to properly track and kill this bug? I can provide a copy of the raw message for test purposes as well.
More information about the MailScanner