Decompression bomb?

  • Thread starter Thread starter Sam
  • Start date Start date
S

Sam

Hi I'm using Win XP HE SP1, and Avast v.4.6 home edition, which is up to
date.

I ran a scan today, and a couple of files came back with "unable to read -
the file is a decompression bomb".

What on earth does that mean?

Thanks for any help.
Sam
 
Sam said:
Hi I'm using Win XP HE SP1, and Avast v.4.6 home edition, which is up to
date.

I ran a scan today, and a couple of files came back with "unable to read -
the file is a decompression bomb".

What on earth does that mean?
Click to expand...

Probably that the file is a multiply nested archive file designed to
exceed the capability of the AV to decompress. Most good AVs will not
attempt to go more than a certain number of levels of nesting and warn
the user of the "bomb".
 
Roger said:
read -



Probably that the file is a multiply nested archive file designed to
exceed the capability of the AV to decompress. Most good AVs will not
attempt to go more than a certain number of levels of nesting and warn
the user of the "bomb".
Click to expand...
I was using Avast a while ago and had the same response when
running a scan. I contacted Avast tech support and was told
they were too nested to scan. There was no comment about
why that happens or what to do about it.

Now using NOD32. It doesn't give the decompression bomb
response, but there certainly are many files it says it
can't read - I suspect it's the same general thing.

Louise
 
Hi I'm using Win XP HE SP1, and Avast v.4.6 home edition, which is up to
date.

I ran a scan today, and a couple of files came back with "unable to read -
the file is a decompression bomb".

What on earth does that mean?

Thanks for any help.
Sam
Click to expand...

42.zip
google for it
 
Hi I'm using Win XP HE SP1, and Avast v.4.6 home edition, which is up to
date.

I ran a scan today, and a couple of files came back with "unable to read -
the file is a decompression bomb".

What on earth does that mean?

Thanks for any help.
Sam
Click to expand...

It's a recursive zip file which, when fully unzipped, would use up all of
the resources on the target computer.

1. Take a very large (say, 4GB) file of repeating bytes and zip it.
(Lots of repetition means lots of compression.)
2. Rename it and zip it again.
3. Repeat until you have 16 zipped copies.
4. zip the 16 zip archives to a new zip file.
5. delete the singly-zipped files keeping the doubly-zipped file.
6. repeat steps 2 to 5 until you have 16 doubly-zipped files.
7. zip the doubly-zipped files into a triply-zipped file.
8. delete the doubly-zipped files.
9. repeat steps 2 to 8 until you have 16 triply-zipped files.
10. zip the triply-zipped files into a quadruply-zipped file.
11. delete the triply-zipped files.
12. repeat steps 2 to 11 until you have 16 quadruply-zip files.
13. zip the quadruply-zipped files into a quintuply-zipped file.
14. delete the quadruply-zipped files.
15. repeat steps 2 to 15 until you have 16 quintuply-zipped files.
16. zip them into one final file and
17. delete the quintuply-zipped files.


Trying to recursively unzip the final file and the files in it would use
up the memory and hard drive resources of pretty well every computer I
know of.


Actual figures from a 42374-byte file I have:

Archive: [name snipped].ZIP
Length Method Size Ratio Date Time CRC-32 Name
-------- ------ ------- ----- ---- ---- ------ ----
34902 Defl:X 2553 93% 00-03-28 21:40 c8dc7593 lib 3.zip
34902 Defl:X 2553 93% 00-03-28 21:40 c8dc7593 lib 1.zip
34902 Defl:X 2553 93% 00-03-28 21:40 c8dc7593 lib 2.zip
34902 Defl:X 2553 93% 00-03-28 21:40 c8dc7593 lib 0.zip
34902 Defl:X 2553 93% 00-03-28 21:40 c8dc7593 lib 4.zip
34902 Defl:X 2553 93% 00-03-28 21:40 c8dc7593 lib 5.zip
34902 Defl:X 2553 93% 00-03-28 21:40 c8dc7593 lib 6.zip
34902 Defl:X 2553 93% 00-03-28 21:40 c8dc7593 lib 7.zip
34902 Defl:X 2553 93% 00-03-28 21:40 c8dc7593 lib 8.zip
34902 Defl:X 2553 93% 00-03-28 21:40 c8dc7593 lib 9.zip
34902 Defl:X 2553 93% 00-03-28 21:40 c8dc7593 lib a.zip
34902 Defl:X 2553 93% 00-03-28 21:40 c8dc7593 lib b.zip
34902 Defl:X 2553 93% 00-03-28 21:40 c8dc7593 lib c.zip
34902 Defl:X 2553 93% 00-03-28 21:40 c8dc7593 lib d.zip
34902 Defl:X 2553 93% 00-03-28 21:40 c8dc7593 lib e.zip
34902 Defl:X 2553 93% 00-03-28 21:40 c8dc7593 lib f.zip
-------- ------- --- -------
558432 40848 93% 16 files

Unzipping only *one* of the 34902-byte files listed above gives me:

Archive: lib 0.zip
Length Method Size Ratio Date Time CRC-32 Name
-------- ------ ------- ----- ---- ---- ------ ----
29446 Defl:X 2084 93% 00-03-28 21:38 01eb60c6 book 3.zip
29446 Defl:X 2084 93% 00-03-28 21:38 01eb60c6 book 1.zip
29446 Defl:X 2084 93% 00-03-28 21:38 01eb60c6 book 2.zip
29446 Defl:X 2084 93% 00-03-28 21:38 01eb60c6 book 0.zip
29446 Defl:X 2084 93% 00-03-28 21:38 01eb60c6 book 4.zip
29446 Defl:X 2084 93% 00-03-28 21:38 01eb60c6 book 5.zip
29446 Defl:X 2084 93% 00-03-28 21:38 01eb60c6 book 6.zip
29446 Defl:X 2084 93% 00-03-28 21:38 01eb60c6 book 7.zip
29446 Defl:X 2084 93% 00-03-28 21:38 01eb60c6 book 8.zip
29446 Defl:X 2084 93% 00-03-28 21:38 01eb60c6 book 9.zip
29446 Defl:X 2084 93% 00-03-28 21:38 01eb60c6 book a.zip
29446 Defl:X 2084 93% 00-03-28 21:38 01eb60c6 book b.zip
29446 Defl:X 2084 93% 00-03-28 21:38 01eb60c6 book c.zip
29446 Defl:X 2084 93% 00-03-28 21:38 01eb60c6 book d.zip
29446 Defl:X 2084 93% 00-03-28 21:38 01eb60c6 book e.zip
29446 Defl:X 2084 93% 00-03-28 21:38 01eb60c6 book f.zip
-------- ------- --- -------
471136 33344 93% 16 files

Unzipping only *one* of the 29446-byte files listed above gives me:

Archive: book 0.zip
Length Method Size Ratio Date Time CRC-32 Name
-------- ------ ------- ----- ---- ---- ------ ----
32150 Defl:X 1737 95% 00-03-28 21:36 b4bd441b chapter 4.zip
32150 Defl:X 1737 95% 00-03-28 21:36 b4bd441b chapter 1.zip
32150 Defl:X 1737 95% 00-03-28 21:36 b4bd441b chapter 2.zip
32150 Defl:X 1737 95% 00-03-28 21:36 b4bd441b chapter 3.zip
32150 Defl:X 1737 95% 00-03-28 21:36 b4bd441b chapter 0.zip
32150 Defl:X 1737 95% 00-03-28 21:36 b4bd441b chapter 5.zip
32150 Defl:X 1737 95% 00-03-28 21:36 b4bd441b chapter 6.zip
32150 Defl:X 1737 95% 00-03-28 21:36 b4bd441b chapter 7.zip
32150 Defl:X 1737 95% 00-03-28 21:36 b4bd441b chapter 8.zip
32150 Defl:X 1737 95% 00-03-28 21:36 b4bd441b chapter 9.zip
32150 Defl:X 1737 95% 00-03-28 21:36 b4bd441b chapter a.zip
32150 Defl:X 1737 95% 00-03-28 21:36 b4bd441b chapter b.zip
32150 Defl:X 1737 95% 00-03-28 21:36 b4bd441b chapter c.zip
32150 Defl:X 1737 95% 00-03-28 21:36 b4bd441b chapter d.zip
32150 Defl:X 1737 95% 00-03-28 21:36 b4bd441b chapter e.zip
32150 Defl:X 1737 95% 00-03-28 21:36 b4bd441b chapter f.zip
-------- ------- --- -------
514400 27792 95% 16 files

Unzipping only *one* of the 32150-byte files listed above gives me:

Archive: chapter 0.zip
Length Method Size Ratio Date Time CRC-32 Name
-------- ------ ------- ----- ---- ---- ------ ----
165302 Defl:X 1914 99% 00-03-28 21:34 4ffec4d7 doc 0.zip
165302 Defl:X 1914 99% 00-03-28 21:34 4ffec4d7 doc 1.zip
165302 Defl:X 1914 99% 00-03-28 21:34 4ffec4d7 doc 2.zip
165302 Defl:X 1914 99% 00-03-28 21:34 4ffec4d7 doc 3.zip
165302 Defl:X 1914 99% 00-03-28 21:34 4ffec4d7 doc 4.zip
165302 Defl:X 1914 99% 00-03-28 21:34 4ffec4d7 doc 5.zip
165302 Defl:X 1914 99% 00-03-28 21:34 4ffec4d7 doc 6.zip
165302 Defl:X 1914 99% 00-03-28 21:34 4ffec4d7 doc 7.zip
165302 Defl:X 1914 99% 00-03-28 21:34 4ffec4d7 doc 8.zip
165302 Defl:X 1914 99% 00-03-28 21:34 4ffec4d7 doc 9.zip
165302 Defl:X 1914 99% 00-03-28 21:34 4ffec4d7 doc a.zip
165302 Defl:X 1914 99% 00-03-28 21:34 4ffec4d7 doc b.zip
165302 Defl:X 1914 99% 00-03-28 21:34 4ffec4d7 doc c.zip
165302 Defl:X 1914 99% 00-03-28 21:34 4ffec4d7 doc d.zip
165302 Defl:X 1914 99% 00-03-28 21:34 4ffec4d7 doc e.zip
165302 Defl:X 1914 99% 00-03-28 21:34 4ffec4d7 doc f.zip
-------- ------- --- -------
2644832 30624 99% 16 files

Unzipping only *one* of the 165302-byte files listed above gives me:

Archive: doc 0.zip
Length Method Size Ratio Date Time CRC-32 Name
-------- ------ ------- ----- ---- ---- ------ ----
4168266 Defl:X 10234 100% 00-03-28 19:49 0f6aee37 page 3.zip
4168266 Defl:X 10234 100% 00-03-28 19:49 0f6aee37 page 1.zip
4168266 Defl:X 10234 100% 00-03-28 19:49 0f6aee37 page 2.zip
4168266 Defl:X 10234 100% 00-03-28 19:49 0f6aee37 page 0.zip
4168266 Defl:X 10234 100% 00-03-28 19:49 0f6aee37 page 4.zip
4168266 Defl:X 10234 100% 00-03-28 19:49 0f6aee37 page 5.zip
4168266 Defl:X 10234 100% 00-03-28 19:49 0f6aee37 page 6.zip
4168266 Defl:X 10234 100% 00-03-28 19:49 0f6aee37 page 7.zip
4168266 Defl:X 10234 100% 00-03-28 19:49 0f6aee37 page 8.zip
4168266 Defl:X 10234 100% 00-03-28 19:49 0f6aee37 page 9.zip
4168266 Defl:X 10234 100% 00-03-28 19:49 0f6aee37 page a.zip
4168266 Defl:X 10234 100% 00-03-28 19:49 0f6aee37 page b.zip
4168266 Defl:X 10234 100% 00-03-28 19:49 0f6aee37 page c.zip
4168266 Defl:X 10234 100% 00-03-28 19:49 0f6aee37 page d.zip
4168266 Defl:X 10234 100% 00-03-28 19:49 0f6aee37 page e.zip
4168266 Defl:X 10234 100% 00-03-28 19:49 0f6aee37 page f.zip
-------- ------- --- -------
66692256 163744 100% 16 files

Unzipping only *one* of the 4168266-byte files listed above gives me:

Archive: page 0.zip
Length Method Size Ratio Date Time CRC-32 Name
-------- ------ ------- ----- ---- ---- ------ ----
4294967295 Defl:X 4168158 100% 00-03-28 18:03 00000000 0.dll
-------- ------- --- -------
4294967295 4168158 100% 1 file

I don't even have any partition large enough for *one* of those.


So one 42374-byte zip file
unzips to 16 34902-byte zip files which
unzip to 256 29446-byte zip files which
unzip to 4096 32150-byte zip files which
unzip to 65536 165302-byte zip files which
unzip to 1048576 4168266-byte zip files which
unzip to 1048576 4294967295-byte files.

Total bytes = 42394 + (16 * 34902) + (256 * 29446) + (4096 * 32150) +
(65536 * 165302) + (1048576 * 4168266) + (1048576 * 4294967295)

(Computing the total space needed is left as an exercise for the reader.)

Now try scanning that 42374-byte file with an antivirus program with
scanning inside archives enabled that's too stupid to know when to give
up unzipping.
 
Norman L. DeForest said:
It's a recursive zip file which, when fully unzipped, would use
up all of the resources on the target computer.
Click to expand...

Well what's the point of a payload like that?

Is it to contain an actual, functional piece of mal-ware? (in which
case how could it ever be executed if it can't be unpacked?)

And if it's simply a type of DoS threat, then apparently there is no
reported case of anti-mal-ware software falling for it and trying to
unpack it to the point of locking up the machine?
Now try scanning that 42374-byte file with an antivirus
program with scanning inside archives enabled that's too
stupid to know when to give up unzipping.
Click to expand...

Like which one?
 
From: "louise" <[email protected]>


| I was using Avast a while ago and had the same response when
| running a scan. I contacted Avast tech support and was told
| they were too nested to scan. There was no comment about
| why that happens or what to do about it.
|
| Now using NOD32. It doesn't give the decompression bomb
| response, but there certainly are many files it says it
| can't read - I suspect it's the same general thing.
|
| Louise

No, not the same. Those files that it can't read could be files whose File Handles are held
open by the Operating System and thus can't be scanned.
 
Virus Guy said:
Well what's the point of a payload like that?
Click to expand...

Denial of Service (DoS).
Is it to contain an actual, functional piece of mal-ware? (in which
case how could it ever be executed if it can't be unpacked?)
Click to expand...

No, it is sort of an attack against automatic scanning within archives.
It pales in comparison with the buffer overflow attacks against some
AV's unpacking routines. As a side effect maybe scanners won't look too
hard for nested malware.
And if it's simply a type of DoS threat, then apparently there is no
reported case of anti-mal-ware software falling for it and trying to
unpack it to the point of locking up the machine?
Click to expand...

Scanners may not look very deep now and this opens the door for malware
nested deeper than they scan. Still seems pointless, but I still think
scanning within archives (with some exceptions) is pointless anyway.
Like which one?
Click to expand...

It's not so much a 'name one' situation as it is a case where the
smarter ones are forced to compromise accuracy in the name of
expedience. Then again - there probably are some other situations where
unzipping may be automated.
 
to.ns.ca:
Hi I'm using Win XP HE SP1, and Avast v.4.6 home edition, which
is up to date.

I ran a scan today, and a couple of files came back with
"unable to read - the file is a decompression bomb".

What on earth does that mean?

Thanks for any help.
Sam
Click to expand...

It's a recursive zip file which, when fully unzipped, would use
up all of the resources on the target computer.

1. Take a very large (say, 4GB) file of repeating bytes and zip
it.
(Lots of repetition means lots of compression.)
2. Rename it and zip it again.
3. Repeat until you have 16 zipped copies.
4. zip the 16 zip archives to a new zip file.
5. delete the singly-zipped files keeping the doubly-zipped
file. 6. repeat steps 2 to 5 until you have 16 doubly-zipped
files. 7. zip the doubly-zipped files into a triply-zipped file.
8. delete the doubly-zipped files.
9. repeat steps 2 to 8 until you have 16 triply-zipped files.
10. zip the triply-zipped files into a quadruply-zipped file.
11. delete the triply-zipped files.
12. repeat steps 2 to 11 until you have 16 quadruply-zip files.
13. zip the quadruply-zipped files into a quintuply-zipped file.
14. delete the quadruply-zipped files.
15. repeat steps 2 to 15 until you have 16 quintuply-zipped
files. 16. zip them into one final file and
17. delete the quintuply-zipped files.


Trying to recursively unzip the final file and the files in it
would use up the memory and hard drive resources of pretty well
every computer I know of.


Actual figures from a 42374-byte file I have:

Archive: [name snipped].ZIP
Length Method Size Ratio Date Time CRC-32 Name
-------- ------ ------- ----- ---- ---- ------ ----
34902 Defl:X 2553 93% 00-03-28 21:40 c8dc7593 lib
3.zip 34902 Defl:X 2553 93% 00-03-28 21:40 c8dc7593
lib 1.zip 34902 Defl:X 2553 93% 00-03-28 21:40
c8dc7593 lib 2.zip 34902 Defl:X 2553 93% 00-03-28
21:40 c8dc7593 lib 0.zip 34902 Defl:X 2553 93%
00-03-28 21:40 c8dc7593 lib 4.zip 34902 Defl:X 2553
93% 00-03-28 21:40 c8dc7593 lib 5.zip 34902 Defl:X
2553 93% 00-03-28 21:40 c8dc7593 lib 6.zip 34902 Defl:X
2553 93% 00-03-28 21:40 c8dc7593 lib 7.zip 34902
Defl:X 2553 93% 00-03-28 21:40 c8dc7593 lib 8.zip
34902 Defl:X 2553 93% 00-03-28 21:40 c8dc7593 lib
9.zip 34902 Defl:X 2553 93% 00-03-28 21:40 c8dc7593
lib a.zip 34902 Defl:X 2553 93% 00-03-28 21:40
c8dc7593 lib b.zip 34902 Defl:X 2553 93% 00-03-28
21:40 c8dc7593 lib c.zip 34902 Defl:X 2553 93%
00-03-28 21:40 c8dc7593 lib d.zip 34902 Defl:X 2553
93% 00-03-28 21:40 c8dc7593 lib e.zip 34902 Defl:X
2553 93% 00-03-28 21:40 c8dc7593 lib f.zip
-------- ------- ---
-------
558432 40848 93% 16
files

Unzipping only *one* of the 34902-byte files listed above gives
me:

Archive: lib 0.zip
Length Method Size Ratio Date Time CRC-32 Name
-------- ------ ------- ----- ---- ---- ------ ----
29446 Defl:X 2084 93% 00-03-28 21:38 01eb60c6 book
3.zip 29446 Defl:X 2084 93% 00-03-28 21:38 01eb60c6
book 1.zip 29446 Defl:X 2084 93% 00-03-28 21:38
01eb60c6 book 2.zip 29446 Defl:X 2084 93% 00-03-28
21:38 01eb60c6 book 0.zip 29446 Defl:X 2084 93%
00-03-28 21:38 01eb60c6 book 4.zip 29446 Defl:X 2084
93% 00-03-28 21:38 01eb60c6 book 5.zip 29446 Defl:X
2084 93% 00-03-28 21:38 01eb60c6 book 6.zip 29446 Defl:X
2084 93% 00-03-28 21:38 01eb60c6 book 7.zip 29446
Defl:X 2084 93% 00-03-28 21:38 01eb60c6 book 8.zip
29446 Defl:X 2084 93% 00-03-28 21:38 01eb60c6 book
9.zip 29446 Defl:X 2084 93% 00-03-28 21:38 01eb60c6
book a.zip 29446 Defl:X 2084 93% 00-03-28 21:38
01eb60c6 book b.zip 29446 Defl:X 2084 93% 00-03-28
21:38 01eb60c6 book c.zip 29446 Defl:X 2084 93%
00-03-28 21:38 01eb60c6 book d.zip 29446 Defl:X 2084
93% 00-03-28 21:38 01eb60c6 book e.zip 29446 Defl:X
2084 93% 00-03-28 21:38 01eb60c6 book f.zip
-------- ------- ---
-------
471136 33344 93% 16
files

Unzipping only *one* of the 29446-byte files listed above gives
me:

Archive: book 0.zip
Length Method Size Ratio Date Time CRC-32 Name
-------- ------ ------- ----- ---- ---- ------ ----
32150 Defl:X 1737 95% 00-03-28 21:36 b4bd441b
chapter 4.zip 32150 Defl:X 1737 95% 00-03-28 21:36
b4bd441b chapter 1.zip 32150 Defl:X 1737 95% 00-03-28
21:36 b4bd441b chapter 2.zip 32150 Defl:X 1737 95%
00-03-28 21:36 b4bd441b chapter 3.zip 32150 Defl:X
1737 95% 00-03-28 21:36 b4bd441b chapter 0.zip 32150
Defl:X 1737 95% 00-03-28 21:36 b4bd441b chapter 5.zip
32150 Defl:X 1737 95% 00-03-28 21:36 b4bd441b
chapter 6.zip 32150 Defl:X 1737 95% 00-03-28 21:36
b4bd441b chapter 7.zip 32150 Defl:X 1737 95% 00-03-28
21:36 b4bd441b chapter 8.zip 32150 Defl:X 1737 95%
00-03-28 21:36 b4bd441b chapter 9.zip 32150 Defl:X
1737 95% 00-03-28 21:36 b4bd441b chapter a.zip 32150
Defl:X 1737 95% 00-03-28 21:36 b4bd441b chapter b.zip
32150 Defl:X 1737 95% 00-03-28 21:36 b4bd441b
chapter c.zip 32150 Defl:X 1737 95% 00-03-28 21:36
b4bd441b chapter d.zip 32150 Defl:X 1737 95% 00-03-28
21:36 b4bd441b chapter e.zip 32150 Defl:X 1737 95%
00-03-28 21:36 b4bd441b chapter f.zip
-------- ------- ---
-------
514400 27792 95% 16
files

Unzipping only *one* of the 32150-byte files listed above gives
me:

Archive: chapter 0.zip
Length Method Size Ratio Date Time CRC-32 Name
-------- ------ ------- ----- ---- ---- ------ ----
165302 Defl:X 1914 99% 00-03-28 21:34 4ffec4d7 doc
0.zip 165302 Defl:X 1914 99% 00-03-28 21:34 4ffec4d7
doc 1.zip 165302 Defl:X 1914 99% 00-03-28 21:34
4ffec4d7 doc 2.zip 165302 Defl:X 1914 99% 00-03-28
21:34 4ffec4d7 doc 3.zip 165302 Defl:X 1914 99%
00-03-28 21:34 4ffec4d7 doc 4.zip 165302 Defl:X 1914
99% 00-03-28 21:34 4ffec4d7 doc 5.zip 165302 Defl:X
1914 99% 00-03-28 21:34 4ffec4d7 doc 6.zip 165302 Defl:X
1914 99% 00-03-28 21:34 4ffec4d7 doc 7.zip 165302
Defl:X 1914 99% 00-03-28 21:34 4ffec4d7 doc 8.zip
165302 Defl:X 1914 99% 00-03-28 21:34 4ffec4d7 doc
9.zip 165302 Defl:X 1914 99% 00-03-28 21:34 4ffec4d7
doc a.zip 165302 Defl:X 1914 99% 00-03-28 21:34
4ffec4d7 doc b.zip 165302 Defl:X 1914 99% 00-03-28
21:34 4ffec4d7 doc c.zip 165302 Defl:X 1914 99%
00-03-28 21:34 4ffec4d7 doc d.zip 165302 Defl:X 1914
99% 00-03-28 21:34 4ffec4d7 doc e.zip 165302 Defl:X
1914 99% 00-03-28 21:34 4ffec4d7 doc f.zip
-------- ------- ---
-------
2644832 30624 99% 16
files

Unzipping only *one* of the 165302-byte files listed above gives
me:

Archive: doc 0.zip
Length Method Size Ratio Date Time CRC-32 Name
-------- ------ ------- ----- ---- ---- ------ ----
4168266 Defl:X 10234 100% 00-03-28 19:49 0f6aee37 page
3.zip 4168266 Defl:X 10234 100% 00-03-28 19:49 0f6aee37
page 1.zip 4168266 Defl:X 10234 100% 00-03-28 19:49
0f6aee37 page 2.zip 4168266 Defl:X 10234 100% 00-03-28
19:49 0f6aee37 page 0.zip 4168266 Defl:X 10234 100%
00-03-28 19:49 0f6aee37 page 4.zip 4168266 Defl:X 10234
100% 00-03-28 19:49 0f6aee37 page 5.zip 4168266 Defl:X
10234 100% 00-03-28 19:49 0f6aee37 page 6.zip 4168266
Defl:X 10234 100% 00-03-28 19:49 0f6aee37 page 7.zip
4168266 Defl:X 10234 100% 00-03-28 19:49 0f6aee37 page
8.zip 4168266 Defl:X 10234 100% 00-03-28 19:49 0f6aee37
page 9.zip 4168266 Defl:X 10234 100% 00-03-28 19:49
0f6aee37 page a.zip 4168266 Defl:X 10234 100% 00-03-28
19:49 0f6aee37 page b.zip 4168266 Defl:X 10234 100%
00-03-28 19:49 0f6aee37 page c.zip 4168266 Defl:X 10234
100% 00-03-28 19:49 0f6aee37 page d.zip 4168266 Defl:X
10234 100% 00-03-28 19:49 0f6aee37 page e.zip 4168266
Defl:X 10234 100% 00-03-28 19:49 0f6aee37 page f.zip
-------- ------- ---
------- 66692256 163744 100%
16 files

Unzipping only *one* of the 4168266-byte files listed above
gives me:

Archive: page 0.zip
Length Method Size Ratio Date Time CRC-32 Name
-------- ------ ------- ----- ---- ---- ------ ----
4294967295 Defl:X 4168158 100% 00-03-28 18:03 00000000 0.dll
-------- ------- ---
------- 4294967295 4168158 100%
1 file

I don't even have any partition large enough for *one* of those.


So one 42374-byte zip file
unzips to 16 34902-byte zip files which
unzip to 256 29446-byte zip files which
unzip to 4096 32150-byte zip files which
unzip to 65536 165302-byte zip files which
unzip to 1048576 4168266-byte zip files which
unzip to 1048576 4294967295-byte files.

Total bytes = 42394 + (16 * 34902) + (256 * 29446) + (4096 *
32150) +
(65536 * 165302) + (1048576 * 4168266) + (1048576 *
4294967295)

(Computing the total space needed is left as an exercise for the
reader.)

Now try scanning that 42374-byte file with an antivirus program
with scanning inside archives enabled that's too stupid to know
when to give up unzipping.
Click to expand...

Norman,

Thanks for that analysis, good work. Sounds a real cause for
concern - helluva buffer overflow problem.

Am I right thinking that the AV program is not the only risk? If
the user rt-clicks such a decomp bomb to expand it, there's a risk
it will still 'explode', depending on the behaviour of the
expanding program e.g. Windows XP Explorer, WinZIP, etc.
 
Well what's the point of a payload like that?
Click to expand...

What was the point of viruses that erased someone's hard disk after some
time delay for replication? Some people, for reasons I totally fail to
understand, get kicks from causing damage or harm to others.

In the case of compression bombs, it would cause some people to turn off
the "scan inside archives" feature of their anti-virus software if their
system ends up locking up too often (and filling up the hard disk with
partially uncompressed files) from checking such files. Then the real
worm or virus can sneak through into the system in zipped form.
 
to.ns.ca:
Hi I'm using Win XP HE SP1, and Avast v.4.6 home edition, which
is up to date.

I ran a scan today, and a couple of files came back with
"unable to read - the file is a decompression bomb".

What on earth does that mean?

Thanks for any help.
Sam
Click to expand...

It's a recursive zip file which, when fully unzipped, would use
up all of the resources on the target computer.
[snip]
So one 42374-byte zip file
unzips to 16 34902-byte zip files which
unzip to 256 29446-byte zip files which
unzip to 4096 32150-byte zip files which
unzip to 65536 165302-byte zip files which
unzip to 1048576 4168266-byte zip files which
unzip to 1048576 4294967295-byte files.

Total bytes = 42394 + (16 * 34902) + (256 * 29446) + (4096 *
32150) +
(65536 * 165302) + (1048576 * 4168266) + (1048576 *
4294967295)

(Computing the total space needed is left as an exercise for the
reader.)

Now try scanning that 42374-byte file with an antivirus program
with scanning inside archives enabled that's too stupid to know
when to give up unzipping.
Click to expand...

Norman,

Thanks for that analysis, good work. Sounds a real cause for
concern - helluva buffer overflow problem.

Am I right thinking that the AV program is not the only risk? If
the user rt-clicks such a decomp bomb to expand it, there's a risk
it will still 'explode', depending on the behaviour of the
expanding program e.g. Windows XP Explorer, WinZIP, etc.
Click to expand...

Yes, *if* the unzipper expands recursively by default (stupid behavour
but I have seen stupider stuff in software). Also yes, if you use an
unzipping program that isn't recursive but specify it in a command line or
batch file with a FOR loop or wild cards in it. Suppose c.zip was a bomb:

c:\temp>dir /wkm
a.zip b.zip c.zip d.zip

c:\temp>for %f in ( *.zip ) do unzip %f

or

c:\temp>dir /wkm
a.zip b.zip c.zip d.zip

c:\temp>unzip *.zip

A Unix version wouldn't be quite so vulnerable as the command,
unzip *.zip
would be expanded by the shell to
unzip a.zip b.zip c.zip d.zip
*before* being passed to the unzip program so recursive unzipping
wouldn't occur.

(4DOS version of DIR in the example above. The /k and /m switches
suppress headers and footers. I was too lazy to try to fake them.)

Try this batch file if you have a command-line zipper. It creates
a zip file similar in structure to compression bombs but with much
smaller contents and fewer nesting levels so you can test the behaviour
of any unzipping programs you have:

@echo off
echo xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx >foo
for %f in ( 1 2 3 ) do copy foo fooa%%f.txt
zip fooa.zip fooa?.txt
ren fooa?.txt foob?.txt
zip foob.zip foob?.txt
ren foob?.txt fooc?.txt
zip fooc.zip fooc?.txt
zip bar.zip foo*.zip
del foo*.*

Now try unzipping bar.zip with various unzipping routines and see if,
by default, they just give you fooa.zip, foob.zip and fooc.zip or whether
they give you fooa1.txt, fooa2.txt, fooa3.txt, foob1.txt, foob2.txt,
foob3.txt, fooc1.txt, fooc2.txt and fooc3.txt instead. Unzipping just to
fooa.zip, foob.zip and fooc.zip is the reasonable behaviour. I don't know
personally of any unzipper that uses recursive unzipping by default but
I have seen other Windows programs do stupider stuff by default.

I would be interested in knowing which, if any, unzipping routines do
perform recursive unzipping by default (so I can tell people to avoid
using them).
 
Joe King said:
Thanks for that analysis, good work. Sounds a real cause for
concern - helluva buffer overflow problem.
Click to expand...

Not a buffer overflow, but a HD overflow...
Am I right thinking that the AV program is not the only risk? If
the user rt-clicks such a decomp bomb to expand it, there's a risk
it will still 'explode', depending on the behaviour of the
expanding program e.g. Windows XP Explorer, WinZIP, etc.
Click to expand...

Indeed, though he'll wonder why his machine takes so long to unpack the
file. ZIP-Bombs really are more of a problem for mailservers, it's a
remote DoS against virus-scanning mailservers that can affect hundreds
or thousands of users...

Juergen Nieveler
 
Juergen said:
ZIP-Bombs really are more of a problem for mailservers,
Click to expand...

Perhaps checking the checksum or hash of the packed or zipped file
will be the only way to ID files like that.

After all, how many will morph or be created in the wild?

Which leads to this question: How are they created in the first
place? Couldn't be by packing huge files to start with. Must be
programatically created.
 
Virus Guy said:
Perhaps checking the checksum or hash of the packed or zipped file
will be the only way to ID files like that.
Click to expand...

Wouldn't help, it's trivial to make new files.
After all, how many will morph or be created in the wild?
Click to expand...

As it takes only a few minutes to do so... lots, as long as there are
targets.

But there is an easy solution, mind you... just make sure that the
virus scanner on the mailserver automatically stops unzipping after a
certain limit of either nesting or file size. If your software doesn't
support that, at the very least make sure that the temp directory used
for unzipping is on a separate, small partition.
Which leads to this question: How are they created in the first
place? Couldn't be by packing huge files to start with. Must be
programatically created.
Click to expand...

By having a small script that pipes the output into GZIP, IIRC.

Juergen Nieveler
 
Back
Top