[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