Today, when I take the sample and resend it to my mailserver, amavis will identify it as trojan infested. But a few days ago my virusscanner did not know this variant of Locky. To reproduce today, what had happened then, I had to disable the virus scan temporarily.
When I now resend the sample to my mailserver, amavis will scan the attachment, identify the javascript inside and, according to its configuration, quarantine the message. That is exactly what should be expected - but this is not, what happened a few days ago. So I manipulated the sample a little bit: After line 53 (Content-Type: application/x-compressed; x-unix-mode=0600) I inserted a new line containing nothing but a binary zero and a newline 0x00 0x0a. And now amavis stumbles into the trap! Now Amavis adds an "BAD HEADER SECTION" alert and does not scan the attachment for illegitimate attachments! Since I can't quarantine each "BAD HEADER SECTION" alert, this would block a lot too much legitimate mail, the mail will be delivered to the intended recipient, and he has no problem to open the attachment and to infect his computer. In my eyes that is a really serious problem! Once again: I can't quarantine each "BAD HEADER SECTION" alert, this would block a lot too much legitimate mail. And I can't trust virus scanners, since they are mostly one day behind reality. So the last barrage between the trojan and the user is a check of the attachments for unwanted, illegitimate file formats. But each rascal can bypass this barrage by simply crafting a few bytes of whitespace into the mimeheaders. I filed this bug with a minor severity, but I think it should be lifted to a higher, to serious severity, because checking of unwanted attachments is a really important feature of amavis, and if this feature can be bypassed in such a simple way, it should be considered broken.
