<!-- SBZ_reproduce  -->
scan more than 30mails/sec

Same problem on SLES9 SP1 RC3

Ralf Flaxa approved higher priority ;)

It should be noted that it crashed with SLES 9 GA and still crashed 
with SLES 9 SP1 RC3 (+RC4 kernel). So it is no regression. Maybe 
the version we have in SLES 9 has a general problem under high 
load? 
 

I need root access to scanhost for debugging.

I need to clarify this.
I wrote a small watchdog to check the clamd service.
Since Friday 18:00 the service crashed 83 times ...
This is not very good for a production system ...

It seems a malformed zip archive which is present in recent virus emails is
responsible for the crash. Files with the same md5 sum
(5faba3441e7a3c1cdfd498b959c30c43) appear more than 100 times in the leftovers
from the crashes under /var/spool/amavis/unpacked . If I run clamscan on these
files, it exits with floating point exception.

A temporary workaround would be to filter out all emails that contain the string
"_NextPart_000_0009_000007D1.0000090E" before they hit clamav.

I'll discuss the crash with the ClamAV authors.

The authors can reproduce the crash and are working on a fix.

Changing this into a security bug and Cc'ing the security team.
I think we should release update packages when a fix is available.

i agree on releasing an update. 

does the unzip binary also crash on those files? 

It looks like it is meant to be an archive bomb:

$ unzip -l ~/part-00002
Archive:  /suse/max/part-00002
  Length     Date   Time    Name
 --------    ----   ----    ----
4294967295  01-05-05 00:39   image_mails.scr
 --------                   -------
4294967295                   1 file

$ unzip ~/part-00002
Archive:  /suse/max/part-00002
 extracting: image_mails.scr          bad CRC 10d3b64a  (should be 00000000)

$ ls -l image_mails.scr
-rw-r-----  1 max suse 83 2005-01-05 00:39 image_mails.scr

$ rpm -q unzip
unzip-5.51-2

Meanwhile I found out, that we only got a single email containing this malformed
archive, but it stayed in the queue for some days crashing clamd again and
again, whenever it was retried to send it through the scanhost.

There is a (one-liner) fix in ClamAV CVS now, but I am still waiting for the
author's answer to my question whether there will soon be an official update
release containing this fix. If not, I'll add the patch to our 0.80 package.

Author says 0.81 will be released in this month.

Matthias, do you meanwhile want a patched package for scanhost?

There were no new clamd crashes since yesterday when we removed the offending
email from the queue. So while we usually get up to ten thousand virus emails a
day, only a single one from last week triggered this crash so far. Two other
(much lower volume) mail servers I maintain didn't get hit by such a mail yet.

So I think the risk is limited for our customers, and I'd vote for downgrading
this bug and delaying the official update until 0.81 is available.
But I'll leave the decision up to Ralf and the security team.

Well, just apply the patch like we do with any other package. No need for a 
version update. 

Please send me a patched version.

I agree, please just apply the patch that we have and let us 
verify that it works on scanhost. Once this testing has been 
successfull for let's say 24h please submit the package 
to abuild. 
 

To comment #16: I'll submit a version update anyways when 0.81 arrives, because
a virus scanner that isn't kept up to date is pretty useless. So the question is
not "do we want a patch or a version update", but "do we want to update the
package twice within a couple of weeks, or is it sufficient to wait for the new
version".

To comment #17: the RPMs will appear under /work/built/mbuild/nitsch-max-5 in a
couple of minutes.

I thought the virus database is independently updated via the web? So unless 
the format of that database changes there is no need for version updates, 
isn't it? 

Seems to me NEEDINFO is set wrong, I can only find something 
Reinhard has to answer. 
 
Reinhard, what is with Ludwigs last comment? 

To #20: Sometimes the format of the virus database changes when a new version
comes out, but I don't know yet whether this will be the case this time. But
aside from that a new version usually also contains code to detect certain
viruses that can't be handled just by adding a pattern to the database, and
various other improvements.

To #21: I set it to NEEDINFO when adding comment #19.

Then you should write on which info you are waiting, this is not clear 
to me. 
About the version update: Every time we allow a version update we make 
very bad experience with it. So we need to make sure that all options and 
config files of the new version are the same as for the old one and that 
the behavior is the same, too. Not that it breaks existing installations 
due a changed behavior. 

Let me cite myself on the question I was waiting on an answer for:

 So the question is not "do we want a patch or a version update",
 but "do we want to update the package twice within a couple of
 weeks, or is it sufficient to wait for the new version".

We've already done a version update of ClamAV on SLES9, and so far I haven't
heared that anybody had any problems with it. The update added some new options
to the config file, but reasonable defaults are used when they are missing, so
the old config file can be kept.

So this questions cannot be answered by the Reporter and it was a wrong 
usage of "NEEDINFO", which means you need informations from the reporter. 
 
If the next version update will be as painless as the old one, we can 
discuss about this. Upating the package twice within a couple of weeks 
is 100% ok, if the first update fixes a crash or similar like this bug 
report started with. 

Yep, the NEEDINFO feature is incomplete, as it doesn't allow to specify the
person from who the info is needed.

OK, so I'll submit a patch that fixes the crash today and will look into the new
version when it is released.

Package and patchinfo file submitted for SLES9, 9.1, and 9.2.
Reassigning to security team for further tracking.

CAN-2005-0133 

is public now. 

Created attachment 27966 [details]
malicious zip file

Test case
Before YOU:
najar:~ # clamscan image_mails.zip 
Floating point exception

After YOU:
najar:~ # clamscan image_mails.zip 
image_mails.zip: Suspected.Zip FOUND

----------- SCAN SUMMARY -----------
Known viruses: 25253
Scanned directories: 0
Scanned files: 1
Infected files: 1
Data scanned: 0.00 MB
I/O buffer size: 131072 bytes
Time: 1.382 sec (0 m 1 s)

updatea released. 

CVE-2005-0133: CVSS v2 Base Score: 5.0 (AV:N/AC:L/Au:N/C:N/I:N/A:P)