Red Hat Bugzilla – Bug 118669
CAN-2004-0182 DoS: qrunner fails if no Subject field in message header
Last modified: 2007-11-30 17:06:54 EST
From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040211 Firefox/0.8 Description of problem: When attempting to parse a message with no Subject header, qrunner fails and logs the following error in /var/log/mailman/error. This failure allows a maliciously or accidentally malformed message to initiate a DoS attack, as the queue backs up until the offending message is removed. Mar 18 13:02:00 2004 qrunner(16106): Traceback (innermost last): Mar 18 13:02:00 2004 qrunner(16106): File "/var/mailman/cron/qrunner", line 283, in ? Mar 18 13:02:00 2004 qrunner(16106): kids = main(lock) Mar 18 13:02:00 2004 qrunner(16106): File "/var/mailman/cron/qrunner", line 253, in main Mar 18 13:02:00 2004 qrunner(16106): keepqueued = dispose_message(mlist, msg, msgdata) Mar 18 13:02:00 2004 qrunner(16106): File "/var/mailman/cron/qrunner", line 157, in dispose_message Mar 18 13:02:00 2004 qrunner(16106): mlist.ParseMailCommands(msg) Mar 18 13:02:00 2004 qrunner(16106): File "/var/mailman/Mailman/MailCommandHandler.py", line 163, in ParseMailCommands Mar 18 13:02:00 2004 qrunner(16106): splitsubj = string.split(subject) Mar 18 13:02:00 2004 qrunner(16106): TypeError : argument 1: expected read-only character buffer, None found Version-Release number of selected component (if applicable): mailman-2.0.13-5 How reproducible: Always Steps to Reproduce: 1. Submit a message with no Subject header to a mailing list. 2. tail -f /var/log/mailman/error. 3. Watch the fireworks. Actual Results: qrunner fails to handle the broken message and any that follow it. Expected Results: qrunner should ignore the broken header and process the message Additional info: I made the following change to /var/mailman/Mailman/MailCommandHandler.py, which at least allows qrunner to run without failing. It looks like the offending messages are simply dropped, though, and not passed to their intended lists. [mjs@www Mailman]$ diff MailCommandHandler.py MailCommandHandler.py.bak 163c163 < splitsubj = string.split(subject) --- > splitsubj = string.split(subject)
this has already been fixed in the following errata RHSA-2004:019-04
*** This bug has been marked as a duplicate of 113472 ***
This probably is a dup of 113472, but I don't think that patch quite fixes the problem. Note that *this* bug is filed against mailman-2.0.13-5, the errata package referred to in 113472. So I'm seeing the behavior with the errata patch in place. In fact, my patch patches that patch. I'm reopening this because I can't reopen that one.
Thank you Matthew I did not realize this was being filed against the errata fix, my appologies. Just a nit, but your patch confused me a little at first because it looks like you removed one level of indendation when one level of indendation should have been added, then I realized the order of files given to diff was backwards, right? I'll make the fix and issue a new errata, thank you for catching this.
Sorry about the confusion--I'm not used to submitting patches. Yes, the indentation on that line is increased one level. Thanks.
errata RHSA-2004:156-02 created for mailman-2.0.13-6. Thank you Matthew.
Reopening as modified until such point as the errata is pushed.
Allocating CAN-2004-0182 for this issue
An errata has been issued which should help the problem described in this bug report. This report is therefore being closed with a resolution of ERRATA. For more information on the solution and/or where to find the updated files, please follow the link below. You may reopen this bug report if the solution does not work for you. http://rhn.redhat.com/errata/RHSA-2004-156.html