Tom Vandepoel wrote:
>> I've been able to grab hold of one of these messages; it seems the
>> worm is sending the mail with incorrect mime headers; it does not put
>> quotes around the filename:
>> Content-Type: audio/x-midi;
>> name=Fichiers AUDIO mr. malpoli CD 1.scr
>> Content-Transfer-Encoding: base64
>> Content-ID: <T1HIVTvXb5n1k>
> I've seen there's a fix for this in anomy-1.56, so I tested it.
> Anomy does fix the incorrect mime header when the "name=" on a seperate
> line, but it still doesn't see the right name when all of this is on the
> same line, e.g.:
> Content-Type: audio/x-midi; name=hi.gif blah.scr
> Maybe the regexp needs to be massaged a bit?
Worse, I've noticed that the regexp in question;
# Detect stupid "name=file with spaces.exe" attributes as sent by
# many massmailer viruses.
$line =~ s/^(\s*[^\s\=]+=)([^\"\=\;]+\S)(\s*)$/$1"$2"$3/gm;
actually corrupts the mime headers on signed mail:
These are is the original content-type header (multiline):
Before the RE, it looks like this (added some debugging statements to
After, like this; the semicolon of the micalg attribute should be
outside the quotes.
Which eventually results in anomy not detecting the seeing the boundary
header and seeing an incorrect micalg attrib...
Got MIME info: boundary="", charset="iso-8859-1",
disposition="inline", encoding="8bit", micalg="sha1;",
As a workaround I've just disabled this regexp, as it wasn't doing much
good anyway... those signed msgs pass through fine now.
-- Tom Vandepoel Security Architect
Ubizen - Philipsite 5 - 3001 Heverlee - Belgium T: +32 16 28 70 00 F: +32 16 28 71 00
Ubizen - We Secure e-Business - www.ubizen.com