FW: Re: dw_sta.zip

[Q G Campbell]

I guess some of you will have been following on the
UK-SECURITY at JISCMAIL.AC.UK list the thread about the security
implications of "Zip od Death" file expansions. For those who have not I
include a message below.

In essence it is saying that in order to prevent file/swap space filling
up and bringing a machine to a halt, a number of sites use software that
limits the size to which a file can expand. This may be a relative
measure expressed as a multiple of the size of the source file or it may
be an absolute limit.

Could Mailscanner provide a configurable option that would limit the
size to which an attachment can expand? This would be an addition to the
timeout controls.

Quentin
---
PHONE: +44 191 222 8209    Computing Service, University of Newcastle
FAX:   +44 191 222 8765    Newcastle upon Tyne, United Kingdom, NE1 7RU.
------------------------------------------------------------------------
"Any opinion expressed above is mine. The University can get its own."


-----Original Message-----
From: Dennis Davis [mailto:D.H.Davis at BATH.AC.UK] 
Sent: 02 October 2001 16:43
To: UK-SECURITY at JISCMAIL.AC.UK
Subject: Re: dw_sta.zip


>Date:         Tue, 2 Oct 2001 15:54:30 +0100
>Sender:       UK Security <UK-SECURITY at jiscmail.ac.uk>
>From:         Simon Baker <s.baker at ukerna.ac.uk>
>Subject:      Re: dw_sta.zip
>To:           UK-SECURITY at jiscmail.ac.uk
>
>At 15:32 02/10/01 +0100, you wrote:
>>The other thing to watch for are "zip of death" files that either 
>>unpack ad infinitum (to many 100's of terabytes if allowed), or that 
>>loop while producing no output.
>
>Yeah, dd if=/dev/zero of=myhugefile can create these.... gzip -9'ing 
>them gets them down to a *v* small size, using a block sorting 
>algorithm compressor such as bzip2 can provide amazing results...
>
>e.g.
>c0ke# dd if=/dev/zero of=112M bs=512 count=229500
>229500+0 records in
>229500+0 records out
>117504000 bytes transferred in 49 secs (2398040 bytes/sec) c0ke# bzip2 
>112M
>bzip2: --repetitive-best is redundant in versions 0.9.5 and above
>   112M:
>     block 1: crc = 0x e09e2df, combined CRC = 0x e09e2df, size =
899985
>     too repetitive; using fallback sorting algorithm
>     block 2: crc = 0x e09e2df, combined CRC = 0x121a2761, size =
899985
>     too repetitive; using fallback sorting algorithm
>     block 3: crc = 0x8796ae9b, combined CRC = 0xa3a2e059, size =
504030
>     too repetitive; using fallback sorting algorithm
>     final combined CRC = 0xa3a2e059
>    1068218.182:1,  0.000 bits/byte, 100.00% saved, 117504000 in, 110 
>out. c0ke# ll 112M.bz2
>-rw-r--r--  1 root  wheel  110 Oct  2 15:48 112M.bz2
>
>
>So, 110bytes isn't too bad... is it?!?!?!

Quite.  An ex-colleague, Mark Hindess, and I were discussing this
problems about a year or more ago.  The example that Mark came up with
was:

dd if=/dev/zero bs=1048576 count=1024|bzip2 >1gigunpacked.bz2

This produces a compressed file of just some 785 bytes which expands to
a gigabyte of zeroes on disc.

Chaos can result if a devious mutant throws such a file at a mail server
which attempts to exand all email and scan it for viruses. You can
almost hear the solids hitting the air-conditioning :-(

Fortunately help is at hand.  Dan Bernstein has a nifty little program,
softlimit, which is part of his daemontools package.  Just run your file
expansion under the control of softlimit.  And set the output file size
limit to a suitable multiple of the input file size.  A multiplier of 50
or so should be more than generous for "normal" files.

The above may, of course, let through a few carefully contrived or
pathological examples.  And then possibly blow up an unfortunate user.
But that's preferable to blowing up a much-prized mail server...

====
UK-Security is a closed mailing list for the discussion of issues
relating to computer security. A related list, uk-security-announce,
receives only the announcements sent to this list by JANET-CERT, and not
the discussion.

Subscribers may unsubscribe from the uk-security list by sending mail to
JISCMAIL at JISCMAIL.AC.UK with leave uk-security as the *body* of the
message.

Questions about list policies should be sent to
UK-SECURITY-REQUEST at JISCMAIL.AC.UK, NOT to the list address. ====