[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[minion-cvs] Add comment suggesting a solution for zlib bombing
Update of /home/minion/cvsroot/doc
In directory moria.mit.edu:/tmp/cvs-serv3639
Modified Files:
E2E-spec.txt
Log Message:
Add comment suggesting a solution for zlib bombing
Index: E2E-spec.txt
===================================================================
RCS file: /home/minion/cvsroot/doc/E2E-spec.txt,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -d -r1.1 -r1.2
--- E2E-spec.txt 11 Dec 2002 03:16:29 -0000 1.1
+++ E2E-spec.txt 20 Dec 2002 23:52:40 -0000 1.2
@@ -183,6 +183,18 @@
decompression as described in RFCs 1950 and 1951. Note that not
DECOMPRESS is not defined for every sequence of bytes.
+[XXXX Allowing message compression creates a DOS opportunity: with
+ highly repetitive messages, zlib can give up to 1000-fold
+ compression. This could allow an attacker to use a 28KB payload as
+ a mailbomb that uncompressed to 28MB.
+
+ The current code takes the following approach: when delivering a
+ message, if the uncompressed size is over 20K, and the compression
+ ratio is >20, we do not uncompress the message, but instead deliver
+ it as-is, with a warning that it may be a zlib bomb.
+
+ Does that sound reasonable? How about the parameters? -NM]
+
BUILDING BLOCK: ERASURE CORRECTING ENCODING
We define a primitive, FRAGMENT, that breaks a K-packet message into