[Mailman-Developers] [Mailman-Users] any info on this reportedexploit?

[Mark Sapiro]

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 at value.net>       The highway is for gamblers,
San Francisco Bay Area, California    better use your sense - B. Dylan