[Mailman-Developers] [Mailman-Users] any info on this reportedexploit?
Mark Sapiro
msapiro at value.net
Wed Feb 1 03:57:33 CET 2006
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
More information about the Mailman-Developers
mailing list