[Dshield] Decompression Bombs

Al Reust areust at comcast.net
Fri Feb 6 03:18:35 GMT 2004

This looks like a chance for a bit of FUN and most admins that have to deal 
with Windows "users" have ran into a similar problems, without a couple of 
gigabytes of files to deal with. Simple, what happens when the user runs 
the drive out of space. Then you have the question about, what happens when 
a Application (MTA/AV in this case) runs the drive out of space. That is 
under the "Administrators" control.

In virtually all cases is fairly easy to recover and be back in operation 
in a few minutes. It really does not matter whether its Nix or Windows. I 
have seen cheap built Nix boxes suffer the same fate, they are better at 
warning of the Impending Doom.

On the Nix side you will get a complaint that a process is intruding into 
the "system reserved space." Depending on what you have assigned as "nice 
level" and the "configuration" the process will just suspend and show as 
suspended. A quick disk check will show the location of your /tmp to be 
full into the system space. You should have been able to identify the 
suspended process. Then is only a matter of KILL!.. Reduce the runlevel and 
do some quick cleanup.. Worst case is a reboot into a single user mode and 
do a quick disk check and cleanup, or really bad is corrupted inodes and 
the disk check. Check the logs, ren the queued file and then reboot.

On the Windows side reboot into the "safe mode".. It should start with the 
complaint about drive space. The simple dir command will show the disk is 
full. Go to the Temp (/tmp) dir and start cleanup, try to remove little 
files until you can see the name of the BIG File... Reboot and go to the logs..

Yes Nix is better at system cleanup.. Apps are not always as nice.

Side Note:
I do remember one intern that taking a class in DB Management (back in the 
mid 90's) wrote a program to create a 64k file (array) with "no" checks. It 
seems the unchecked recursive nature caused the file to fill memory, the 
Nix box was set to swap from memory to the swap partition. As the swap 
partition filled things came to a grinding halt. No Gigabytes, only poor 

Depending on the OS and the affected Application as to whether it uses the 
System Temp or a "User/Application" Temp folder. That is under the control 
of the Administrator. Hopefully Applications are set to use an area "other 
than" used by the OS. So what the Users are out of Space!

The best thing to do would create a system to play with and develop your 
own recovery plan. Until you have seen it, well you can only guess!


At 05:57 AM 2/5/2004 -0800, you wrote:
>jayjwa wrote:
> > > The bottom line: Take an extremely large file (100sGB) containing 
> only a single byte value (such as x00), compress it, and you end up with 
> a tiny file (~>64KB). That that file and used it as an email attachment, 
> part of a web page, etc., that when it is decompressed, will crash the 
> program that invoked the decompressor.
> >
> > lol...
> > Not that I doubt you... I'm just trying to picture who sits around
> > compressing 100gig+ files... my entire system sits on 3gig. That must be
> > one lonely individual.
>It's a vulnerability that could lead to a denial or service (or worse.)
>The person crafts the archive for the specific purpose of taking out the
>target's mail server.  And they most certainly don't need to actually
>create a 100GB file to create the archive.
>That kind of attitude is not how you run a secure system.  "Aww gee,
>this vulnerability sure would take a lot of effort to exploit... I mean
>what kind of loser is going to sit around and determine the stack
>location of some return Address?  Man, what kind of lonely nerd makes
>shellcode by hand?  Hehehe, he must have no life.  lol.  ...What do you
>mean my server's been 0wned and is now serving warez?"
>list mailing list
>list at dshield.org
>To change your subscription options (or unsubscribe), see: 

More information about the list mailing list