On Monday 24 February 2003 13:07, ned+ietf-822(_at_)mrochek(_dot_)com wrote:
<snip>
7. Security Considerations
The deflate algorithm is complex and hence prone to implementation
errors. In particular, certain inflate implementations are known
to not perform sufficient checking of their input stream and hence
may be vulnerable to certain forms of attack. Aside from this, the
new content-transfer-encodings specified in this document are believe
not to raise any security considerations not already present in MIME
itself.
<snip>
Huuu.... ;-)
I'm currently hacking up experimental support for this for KMail and
I've came across the fact that I can't give a maximum decoded size for
a given encoded size, although the following experiments suggest that
the decoded size converges to about ( 1000 * encoded size ) as encoded
size tends to infinity:
$ perl -e 'print "a" x 10;'|gzip -9 |wc -c
23
$ perl -e 'print "a" x 100;'|gzip -9 |wc -c
24
$ perl -e 'print "a" x 1000;'|gzip -9 |wc -c
29
$ perl -e 'print "a" x 10000;'|gzip -9 |wc -c
46
$ perl -e 'print "a" x 100000;'|gzip -9 |wc -c
133
$ perl -e 'print "a" x 1000000;'|gzip -9 |wc -c
1004
$ perl -e 'print "a" x 10000000;'|gzip -9 |wc -c
9738
$ perl -e 'print "a" x 100000000;'|gzip -9 |wc -c
97072
$ perl -e 'for (1..10) { print "a" x 100000000;}'|gzip -9 |wc -c
970502
So there you have a nice DoS attack: send a 1M message with all "a"s and
deflate-8bit to someone you don't like and see his box grind to a halt
under the memory pressure of a 1G attachment....
Filtering on message size suddenly fails. Decoding *must* be done in
chunks even for seemingly small messages or implementations risk a DoS
vulnerability. Likewise, applications need an emergency break that
stops the decoding process if the decoded content gets too large.
Granted, the problem of overly large attachments already exists in the
normal MIME CTEs, but there, you still have the guarantee that the
encoded and decoded size is of the same order of magnitude. The new
thing here is that the maximum decoded size is three orders of
magnitude greater than for any other CTE. I'd think that many DoS
protections in current MUAs are built with the same-order assumption
implicitly used all over the place...
To summarize: The security considerations section should warn about this
fact and if there is a guaranteed upper limit on the decoded size as a
function of encoded size, that function should be included in the
document. Usage of the rfc2183 Content-Disposition with a size
parameter should be made a SHOULD, even though that parameter can be
most easily faked, of course (I'm a bit disappointed that rfc2183
doesn't mention that one shouldn't rely on the size parameter and
probably stop processing if the decoding starts producing more than
double the size announced...)
Marc
--
'When you see the ping of death, duck and cover.'
-- Bruce Schneier, Crypto-Gram Oct 2002
pgpAtdlSnZryv.pgp
Description: signature