Hi,

clamdscan returns surprising results for "better zip bomb" reproducers[0]:

* Inconsistent results with zbsm.zip:

clamdscan returns different results when run different times. The first
time the file is considered sane, the second time as "infected".

It looks like clamdscan doesn't always hit the OverlappingFiles heuristic.

$ clamdscan /tmp/zbsm.zip
/tmp/zbsm.zip: OK
/tmp/zbsm.zip: Heuristics.Zip.OverlappingFiles FOUND
* zbxl.zip

clamdscan returns OK for zbxl.zip after 0.000 sec. clamscan needs more than
one minute. This difference is surprising to me.

$ clamdscan /tmp/zbxl.zip
/tmp/zbxl.zip: OK
/tmp/zbxl.zip: OK
----------- SCAN SUMMARY -----------
Known viruses: 6354861
Engine version: 0.101.4
Scanned directories: 0
Scanned files: 1
Infected files: 0
Data scanned: 0.00 MB
Data read: 43.75 MB (ratio 0.00:1)
Time: 66.032 sec (1 m 6 s)

This is reproducible with 0.101.4 in unstable (not a VM), stretch and
jessie (both VMs).

cheers,
Hugo

[0] https://www.bamsoftware.com/hacks/zipbomb/

I don't understand the difference between the first run vs the second.
Please note that that clamdscan uses the daemon for scanning which *may*
cache the last result. A fresh started daemon:

|$ clamdscan zbsm.zip
|/home/bigeasy/zbsm.zip: Heuristics.Zip.OverlappingFiles FOUND
|
|----------- SCAN SUMMARY -----------
|Infected files: 1
|Time: 119.048 sec (1 m 59 s)
|$ clamdscan zbsm.zip
|/home/bigeasy/zbsm.zip: Heuristics.Zip.OverlappingFiles FOUND
|
|----------- SCAN SUMMARY -----------
|Infected files: 1
|Time: 0.367 sec (0 m 0 s)

So the first scan was *really* performed, the second one used the
previous result. The odd-part is "OK" vs "FOUND" for the daemon and I
can't pin point the 51secs.

zbxl.zip is a different story. It says "Data scanned: 0.00 MB" which
means it didn't do anything. My guess is that your file limit is 25MiB
while the file is ~40MiB. That time here is just load the database. Take
a look at this:
|$ clamscan --max-filesize 50M zbxl.zip
|zbxl.zip: OK
|
|----------- SCAN SUMMARY -----------
|Known viruses: 6354861
|Engine version: 0.101.4
|Scanned directories: 0
|Scanned files: 1
|Infected files: 0
|Data scanned: 44.16 MB
|Data read: 43.75 MB (ratio 1.01:1)
|Time: 34.947 sec (0 m 34 s)
|$ clamscan  zbxl.zip
|zbxl.zip: OK

"Data scanned" > 0.

|----------- SCAN SUMMARY -----------
|Known viruses: 6354861
|Engine version: 0.101.4
|Scanned directories: 0
|Scanned files: 1
|Infected files: 0
|Data scanned: 0.00 MB
|Data read: 43.75 MB (ratio 0.00:1)
|Time: 28.061 sec (0 m 28 s)

"Data scanned" == 0 so ~28secs to load the data base.

|$ clamscan  /etc/ssl/openssl.cnf
|/etc/ssl/openssl.cnf: OK
|
|----------- SCAN SUMMARY -----------
|Known viruses: 6354861
|Engine version: 0.101.4
|Scanned directories: 0
|Scanned files: 1
|Infected files: 0
|Data scanned: 0.02 MB
|Data read: 0.01 MB (ratio 2.00:1)
|Time: 28.566 sec (0 m 28 s)

Here it scanned something and you see the time it needed is almost the
same as in the previous example where it did just load its database.

So far I don't see anything wrong.

Sebastian

Hi Sebastian,

OK, so this is not reproducible on your system. I have no idea why
clamdscan behaves like this on my machine, but my knowledge of this code
base is limited.

Ack, thanks for pointing that out, I forgot about the file size limit.

I have discovered this during my regression tests for the jessie update. My
main worry was to have broken something, I'm glad it's not the case.
Thanks for your time!

regards,
Hugo

Hi Hugo,

What do we do here?

Sebastian

Hi Sebastian,

Not sure, my Debian time is extremely reduced at the moment and I don't
think that I'll have time to try and reproduce again. When I reported the
bug it was a reproducible issue. If you have time, the right thing to do
might be to reproduce once more and bring it upstream...

Thanks!

Best,
Hugo