Sober.I virus variant gets Malformed SA reply. SPAMD/1.0 76 Bad header line: (Content-Length mismatch: Expected...

[Rob Kudyba <rk...@raeinternet.com>]

We're running ClamAV .75 and SA 3.01 on RH8 and 9 boxes and we are 
finding that mails with the Sober.I variant get pass ClamAV 0.75 and 
then SA replies with:
"Malformed SA reply. SPAMD/1.0 76 Bad header line: (Content-Length 
mismatch: Expected 77970 bytes, got 77972 bytes)"

Per this thread: 
http://www.redhat.com/archives/redhat-list/2003-June/msg01995.html I did 
both of these:
"I added a line to /etc/init.d/spamassassin: export LANG=en_US"

 and:

 "Another approach for RH 8/9 is to add

 export LANG=en_US SUPPORTED="en_US" LC_MESSAGES=C LC_ALL=C

 to /etc/bashrc. That pretty well picks up all utf-8 probs."

Sample file avaialble at 
ftp://herbie.raeinternet.com:/pub/20041203_073721_27721400c.49866.tar.gz

I see that from this URL: 
http://spamassassin.rediris.es/full/3.0.x/dist/spamd/spamd.raw, the part 
of the code is here:
  # Check length if we're supposed to.
  if ( defined $expected_length && $actual_length != $expected_length ) {
    protocol_error(
      "(Content-Length mismatch: Expected $expected_length bytes, got 
$actual_length bytes)"
    );
    $mail->finish();
    return 1;
  }

This doesn't seem to happen on other OS'es, e.g., OS X/Darwin or 
Solaris, and of course an upgrade to ClamAV 0.80 correctly catches the 
file as a Sober.I virus...anything else to do as we've seen this error 
with non-virus mails as well...

Re: Sober.I virus variant gets Malformed SA reply. SPAMD/1.0 76 Bad header line: (Content-Length mismatch: Expected...

[Theo Van Dinter <fe...@kluge.net>]

On Fri, Dec 03, 2004 at 11:07:48AM -0500, Rob Kudyba wrote:
> "Malformed SA reply. SPAMD/1.0 76 Bad header line: (Content-Length 
> mismatch: Expected 77970 bytes, got 77972 bytes)"
> 
> This doesn't seem to happen on other OS'es, e.g., OS X/Darwin or 
> Solaris, and of course an upgrade to ClamAV 0.80 correctly catches the 
> file as a Sober.I virus...anything else to do as we've seen this error 
> with non-virus mails as well...

The only interesting thing I see is that there are 2 NULL chars (raw
binary) at the end of the pif attachment, making the whole message
completely invalid per the RFC.  That is very likely confusing something
in the system since nulls aren't ever supposed to be there.  You should
just have your MTA drop mails that have raw null characters in them.

-- 
Randomly Generated Tagline:
Be warned that typing \fBkillall \fIname\fP may not have the desired
 effect on non-Linux systems, especially when done by a privileged user.
 (From the killall manual page)