Bug#941850: clamav: inconsistent results with "better zip bomb" reproducers

Hugo Lefeuvre

unread,

Oct 6, 2019, 10:40:03 AM10/6/19

to

Package: clamav
Version: clamav/0.101.4+dfsg-1
Severity: normal

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

----------- SCAN SUMMARY -----------
Infected files: 0
Time: 120.771 sec (2 m 0 s)
$ clamdscan /tmp/zbsm.zip
/tmp/zbsm.zip: Heuristics.Zip.OverlappingFiles FOUND

----------- SCAN SUMMARY -----------
Infected files: 1
Time: 51.885 sec (0 m 51 s)

* 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

----------- SCAN SUMMARY -----------
Infected files: 0
Time: 0.000 sec (0 m 0 s)
$ clamscan /tmp/zbxl.zip
/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/

--
Hugo Lefeuvre (hle) | www.owl.eu.com
RSA4096_ 360B 03B3 BF27 4F4D 7A3F D5E8 14AA 1EB8 A247 3DFD
ed25519_ 37B2 6D38 0B25 B8A2 6B9F 3A65 A36F 5357 5F2D DC4C

signature.asc

Sebastian Andrzej Siewior

unread,

Oct 6, 2019, 4:20:04 PM10/6/19

to

On 2019-10-06 16:14:15 [+0200], Hugo Lefeuvre wrote:
> * 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
>
> ----------- SCAN SUMMARY -----------
> Infected files: 0
> Time: 120.771 sec (2 m 0 s)
> $ clamdscan /tmp/zbsm.zip
> /tmp/zbsm.zip: Heuristics.Zip.OverlappingFiles FOUND
>
> ----------- SCAN SUMMARY -----------
> Infected files: 1
> Time: 51.885 sec (0 m 51 s)

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
>
> 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
>
> ----------- SCAN SUMMARY -----------
> Infected files: 0
> Time: 0.000 sec (0 m 0 s)
> $ clamscan /tmp/zbxl.zip
> /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).

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

|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

|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.

> cheers,
> Hugo

Sebastian

Hugo Lefeuvre

unread,

Oct 7, 2019, 3:20:03 AM10/7/19

to

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.

> 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.
>

> [...]

>
> 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.

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

> So far I don't see anything wrong.

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

signature.asc

Sebastian Andrzej Siewior

unread,

Jun 29, 2021, 4:30:04 PM6/29/21

to

On 2019-10-07 08:41:51 [+0200], Hugo Lefeuvre wrote:
> Hi Sebastian,
Hi Hugo,

> 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!

What do we do here?

> regards,
> Hugo

Sebastian

Hugo Lefeuvre

unread,

Jun 30, 2021, 2:50:03 AM6/30/21

to

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

signature.asc