Re: [Mailman-Developers] [Mailman-Users] any info on this reported exploit?
Tokio Kikuchi wrote:
http://www.securityfocus.com/bid/16248/discuss GNU Mailman Large Date Data Denial Of Service Vulnerability GNU Mailman is prone to a denial of service attack. This issue affects the email date parsing functionality of Mailman. (snip) 06.3.18 CVE: CVE-2005-4153 (snip)
Mailman-2.1.7 is not vulnerable to this issue.
We may have to patch against this email package parsedate bug. I've just uploaded a patch on SF tracker. Please someone review this before I commit in the CVS (this weekend, maybe). https://sourceforge.net/tracker/?func=add&group_id=103&atid=300103
Cheers,
Tokio Kikuchi, tkikuchi@ is.kochi-u.ac.jp http://weather.is.kochi-u.ac.jp/
Tokio Kikuchi wrote:
We may have to patch against this email package parsedate bug. I've just uploaded a patch on SF tracker. Please someone review this before I commit in the CVS (this weekend, maybe). https://sourceforge.net/tracker/?func=add&group_id=103&atid=300103
Above URI is not correct :-(
See <https://sourceforge.net/tracker/index.php?func=detail&aid=1419490&group_id=103&atid=300103>
-- Mark Sapiro <msapiro@value.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
Mark Sapiro wrote:
Tokio Kikuchi wrote:
We may have to patch against this email package parsedate bug. I've just uploaded a patch on SF tracker. Please someone review this before I commit in the CVS (this weekend, maybe). https://sourceforge.net/tracker/?func=add&group_id=103&atid=300103
Above URI is not correct :-(
See <https://sourceforge.net/tracker/index.php?func=detail&aid=1419490&group_id=103&atid=300103>
Oops, sorry! :-P
-- Tokio Kikuchi, tkikuchi@ is.kochi-u.ac.jp http://weather.is.kochi-u.ac.jp/
Tokio Kikuchi wrote:
We may have to patch against this email package parsedate bug. I've just uploaded a patch on SF tracker. Please someone review this before I commit in the CVS (this weekend, maybe).
I have looked at the patch in the tracker.
Caveat: I haven't tested anything - this is just based on my reading.
I think the patch is good. The issue I see is that Scrubber.py may not currently be doing the right thing if parsedate() returns None.
Consider the attached patch for Scrubber.py in addition to the patch in the tracker.
-- Mark Sapiro <msapiro@value.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
Mark Sapiro wrote:
Tokio Kikuchi wrote:
We may have to patch against this email package parsedate bug. I've just uploaded a patch on SF tracker. Please someone review this before I commit in the CVS (this weekend, maybe).
I have looked at the patch in the tracker.
Caveat: I haven't tested anything - this is just based on my reading.
I think the patch is good. The issue I see is that Scrubber.py may not currently be doing the right thing if parsedate() returns None.
Consider the attached patch for Scrubber.py in addition to the patch in the tracker.
Well, the logic may be unclear but calculate_attachment_dir() tries again to guess the real date of message arrival because it may be called from bin/arch. I think the code should be cleaned up but since we are now dealing with the email parsedate bug and it should be safe to limit our patch to this purpose.
-- Tokio Kikuchi, tkikuchi@ is.kochi-u.ac.jp http://weather.is.kochi-u.ac.jp/
Tokio Kikuchi wrote:
Well, the logic may be unclear but calculate_attachment_dir() tries again to guess the real date of message arrival because it may be called from bin/arch. I think the code should be cleaned up but since we are now dealing with the email parsedate bug and it should be safe to limit our patch to this purpose.
I ran into a problem with this while testing something else. I posted a message using bin/inject and also had scrub_nondigest true. The message got shunted in Scrubber's calculate_attachments_dir because parts = msg.get_unixfrom().split() threw an exception because msg.get_unixfrom() was None.
Anyway, I wasn't concerned about that per se, but rather about how the process had gotten that far. It turns out that email.Utils.parsedate() returns a 9-tuple with tm_yday = 0 which is not acceptable to time.strftime() in Python 2.4, but it is OK for time.mktime().
When safe_strftime() returns None, we get to datestr = msgdata.get('X-List-Received-Date') if datestr: datedir = safe_strftime(fmt, datestr)
This is a problem too - first, X-List-Received-Date is a message header, not message metadata and second it is a formatted date which is not the right argument for strftime so safe_strftime() returns None again and we fall back to unixfrom.
Perhaps the workaround patch for parsedate should be something like
+def parsedate(data):
- if not data:
return None- t = _parsedate(data) ++ if not t[7]: ++ t = t[:7] + (1,) +t[8:]
- try:
time.mktime(t)- except OverflowError:
return None- return t
and similarly for parsedate_tz
-- Mark Sapiro <msapiro@value.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
Mark Sapiro wrote:
++ if not t[7]: ++ t = t[:7] + (1,) +t[8:]
On second thought, that should be
if t and not t[7]
t = t[:7] + (1,) +t[8:]-- Mark Sapiro <msapiro@value.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
Mark Sapiro wrote:
++ if not t[7]: ++ t = t[:7] + (1,) +t[8:]
On second thought, that should be
if t and not t[7] t = t[:7] + (1,) +t[8:]
I seem to be having a lot of trouble with this. Make that
if t and not t[7]:
t = t[:7] + (1,) +t[8:]-- Mark Sapiro <msapiro@value.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
Mark Sapiro wrote:
Mark Sapiro wrote:
++ if not t[7]: ++ t = t[:7] + (1,) +t[8:]
On second thought, that should be
if t and not t[7] t = t[:7] + (1,) +t[8:]
I seem to be having a lot of trouble with this. Make that
if t and not t[7]: t = t[:7] + (1,) +t[8:]
I changed the patch including this one. Please check it again. https://sourceforge.net/tracker/index.php?func=detail&aid=1419490&group_id=103&atid=300103
-- Tokio Kikuchi, tkikuchi@ is.kochi-u.ac.jp http://weather.is.kochi-u.ac.jp/
Tokio Kikuchi wrote:
I changed the patch including this one. Please check it again. https://sourceforge.net/tracker/index.php?func=detail&aid=1419490&group_id=103&atid=300103
I've applied the revised patch and I'm testing. So far it looks good.
-- Mark Sapiro <msapiro@value.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
On Tue, 2006-01-31 at 19:26 -0800, Mark Sapiro wrote:
I seem to be having a lot of trouble with this. Make that
if t and not t[7]: t = t[:7] + (1,) +t[8:]
If you look at email 3.0, the 7th item returned from parsedate() and parsedate_tz() is always 1, obviously so that the value is acceptable to time.mktime() and time.strftime(), or None of course.
I think the right thing to do is to fix email 2.5 to behave the same way. This is safe because that time is documented as not being meaningful, so we might as well make it safe <wink>.
I'd rather do that than apply the current SF patch to Mailman. One thing I don't like about the patch is that it calls time.strftime() to try to catch errors and return None. I don't think that's necessary if we change the email package as described above.
So let's fix and release an email 2.5.7 for Mailman 2.1.8. Even though there are more things I'd like to fix in the email 2.5 package, I'd rather get this out in time to integrate in Mailman 2.1.8. I can do that pretty quickly.
Thoughts? -Barry
participants (3)
-
Barry Warsaw -
Mark Sapiro -
Tokio Kikuchi