https://bz.apache.org/SpamAssassin/show_bug.cgi?id=8491
Bug ID: 8491
Summary: spamd inflates a compressed request with no size limit
Product: Spamassassin
Version: SVN Trunk (Latest Devel Version)
Hardware: All
OS: All
Status: NEW
Severity: enhancement
Priority: P2
Component: spamc/spamd
Assignee: [email protected]
Reporter: [email protected]
Target Milestone: Undefined
Created attachment 6192
--> https://bz.apache.org/SpamAssassin/attachment.cgi?id=6192&action=edit
patch to inflate compressed requests in pieces, up to 256 MB
This is hardening of spamd, not a fix for a vulnerability. spamd relies on
being accessed only by trusted clients: --allowed-ips controls which hosts can
connect, and spamd takes what those clients send as given, including the
username, with no limit of its own on message size. Trusting clients is still
different from letting a small mistake in one of them take down a spamd child.
Without compression, what one request can cost spamd grows only with the size
of what is sent, which clients limit (spamc's -s option). With compression, a
few MB sent can become several GB in spamd, so a buggy client, or a misbehaving
program on an allowed host, can kill a child with a small request.
When a request has a "Compress: zlib" header, spamd's zlib_inflate_read reads
the body until the client closes the connection and then inflates all of it in
one call, with no limit on the output, so a large enough output gets the child
killed for running out of memory. The code dates from the addition of spamc -z
in 3.2.0, and its comments already mark the inflate at EOF as a TODO.
Reading to EOF also means a compressed request is not ended by its
Content-length. A client that sends the request and waits for the reply without
shutting down its side of the connection gets no reply until it closes the
connection. spamc shuts down its side after sending, so it is not affected.
The attached patch reads up to Content-length bytes, as spamd does for an
uncompressed body, and inflates them 1 KB at a time, each step producing at
most about 1 MB. Once the inflated message is larger than 256 MB, spamd returns
the existing "zlib:" service unavailable error. 256 MB is spamc's
SPAMC_MAX_MESSAGE_LEN (bug 4928), and spamc does not send larger messages, so
no message from spamc reaches the limit.
--
You are receiving this mail because:
You are the assignee for the bug.