[Dshield] Decompression Bombs
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.
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:
> > > 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