[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [minion-cvs] Add comment suggesting a solution for zlib bombing
- To: mixminion-dev@freehaven.net
- Subject: Re: [minion-cvs] Add comment suggesting a solution for zlib bombing
- From: Zooko <zooko@zooko.com>
- Date: Mon, 23 Dec 2002 15:07:11 -0500
- Delivered-to: archiver@seul.org
- Delivered-to: mixminion-dev-outgoing@seul.org
- Delivered-to: mixminion-dev@seul.org
- Delivery-date: Mon, 23 Dec 2002 15:11:44 -0500
- In-reply-to: Message from nickm@seul.org (Nick Mathewson) of "Fri, 20 Dec 2002 18:52:42 EST." <20021220235242.8314F33C68@moria.seul.org>
- References: <20021220235242.8314F33C68@moria.seul.org>
- Reply-to: mixminion-dev@freehaven.net
- Sender: owner-mixminion-dev@freehaven.net
(From mixminion-cvs.)
> Add comment suggesting a solution for zlib bombing
> + 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]
This means that if I use mixminion programmatically as a transport layer, I have
to check that my messages wouldn't trigger this defense, and if they do I send
them uncompressed, right?
What is the attack aimed at -- filling up the user's mailbox? Too bad all MUA's
don't compress mailboxes. :-)
By the way, I use this Python module to zlib-uncompress while constraining the
memory used during decompression as well as the size of the result:
http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/pyutil/pyutil_new/pyutil/zlibutil.py?rev=HEAD&content-type=text/vnd.viewcvs-markup
Regards,
Zooko