Decompression bomb?
in [Anti-Virus]
|
Prev: hotfixq0306270.exe
Next: regsvr.exe and q387.exe
From: David H. Lipman on 13 Nov 2005 10:47 From: "louise" <louise(a)nospam.com> | 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. -- Dave http://www.claymania.com/removal-trojan-adware.html http://www.ik-cs.com/got-a-virus.htm
From: Roger Wilco on 13 Nov 2005 15:36 "Virus Guy" <Virus(a)Guy.com> wrote in message news:437754F2.9094F2C5(a)Guy.com... > "Norman L. DeForest" wrote: > > > It's a recursive zip file which, when fully unzipped, would use > > up all of the resources on the target computer. > > Well what's the point of a payload like that? 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?) 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? 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. > > 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. > > Like which one? 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.
From: Joe King on 13 Nov 2005 17:23 "Norman L. DeForest" <af380(a)chebucto.ns.ca> wrote in news:Pine.GSO.3.95.iB1.0.1051113080444.14486A-100000(a)halifax.chebuc to.ns.ca: > > On Sat, 12 Nov 2005, Sam wrote: > >> 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 > > 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, 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.
From: Norman L. DeForest on 13 Nov 2005 20:25 On Sun, 13 Nov 2005, Virus Guy wrote: > "Norman L. DeForest" wrote: > > > It's a recursive zip file which, when fully unzipped, would use > > up all of the resources on the target computer. > > Well what's the point of a payload like that? 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. -- Norman De Forest http://www.chebucto.ns.ca/~af380/Profile.html "> Is there anything Spamazon DOESN'T sell? Clues. The market's too small to justify the effort." -- Stuart Lamble in the scary devil monastery, Fri, 13 May 2005
From: Norman L. DeForest on 13 Nov 2005 21:17
On Sun, 13 Nov 2005, Joe King wrote: > "Norman L. DeForest" <af380(a)chebucto.ns.ca> wrote in > news:Pine.GSO.3.95.iB1.0.1051113080444.14486A-100000(a)halifax.chebuc > to.ns.ca: > > > > > On Sat, 12 Nov 2005, Sam wrote: > > > >> 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 > > > > 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. > > > > 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. 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). -- Can you Change: *alchemy to alchemy* (* == Unicorn) mindworks mindworks in 103 moves? Try http://www.chebucto.ns.ca/~af380/AMPuzzle.html (Needs a browser supporting the W3C DOM such as Firefox, Opera or IE v6) |