[ python-Bugs-847019 ] datetime.datetime initialization needs more strict checking

[SourceForge.net]

Bugs item #847019, was opened at 2003-11-21 21:19
Message generated for change (Comment added) made by tim_one
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=847019&group_id=5470

Category: Python Library
Group: Python 2.3
Status: Open
Resolution: None
Priority: 7
Submitted By: Michael Dubner (dubnerm)
>Assigned to: Guido van Rossum (gvanrossum)
Summary: datetime.datetime initialization needs more strict checking

Initial Comment:
Friend of mine wrote following program:
---------------------------------
import datetime
t=datetime.datetime('1995-03-25')
print t.ctime()
---------------------------------
This is obviously wrong code, but instead of reporting
this at second line python crashes on third line (with
ctime).

Info:
Using Python 2.3.2 on Windows 2000


----------------------------------------------------------------------

>Comment By: Tim Peters (tim_one)
Date: 2004-03-21 15:53

Message:
Logged In: YES 
user_id=31435

Guido, it was assigned to you for (as the comment said) your 
amusement -- we asked each other the odds of anyone 
passing a string here when the backdoor was invented, and 
both thought "na".

What kind of superficial check did you have in mind here?  
The datetime object constructed is insane in 4 of its 7 fields, 
and I have no idea exactly which of those crashes MS's 
library:

>>> import datetime
>>> datetime.datetime('1995-03-25')
datetime.datetime(12601, 57, 53, 45, 48, 51, 2961973)
>>>

Oddly enough, it doesn't appear that the out-of-range year, 
day or microseconds are the problem; forcing the month alone 
into range stops the crash on Windows:

>>> datetime.datetime('19\x0c5-03-25')
datetime.datetime(12601, 12, 53, 45, 48, 51, 2961973)
>>> _.ctime()
'Fri Dec 53 45:48:51 12601'
>>>

So, ya, I could check the month alone, and that would 
prevent this particular crash under MSVC 6.  But there's 
simply no guessing whether other platforms can tolerate the 
insanity remaining, whether this is the only case Windows 
can't tolerate, or whether the kind of crazy datetime object 
constructed just above (which would pass a months-only 
check) could still be used to crash the interpreter after it's 
constructed (the datetime code assumes objects aren't 
insane).


dubnerm:  It's too late to add "dummy fields".  If we did, 
datetime pickles wouldn't be readable across Python releases.

It's unlikely that any by-hand typed string would have a valid 
pickle code for a month in the third byte, so I guess I'll settle 
for that.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2004-03-20 17:52

Message:
Logged In: YES 
user_id=6380

Not sure why this is assigned to me.

One suggestion: we could do a superficial check that would
catch the above honest mistake without claiming to prevent
all malicious attacks -- malicious pickles aren't something
we try to defend against in general (alas).

----------------------------------------------------------------------

Comment By: Michael Dubner (dubnerm)
Date: 2003-11-24 20:17

Message:
Logged In: YES 
user_id=39274

Can we add dummy fields to change size of backdoor string so
it will not be same as commonly used formats?

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2003-11-24 18:50

Message:
Logged In: YES 
user_id=31435

Na, it's not that simple.  Blazing-fast pickling and unpickling 
was a design goal for datetime.  "Sanity checks" require two-
tailed comparisons on 7 distinct fields, and checking of the 
day field requires month-specific comparison, and may even 
require determing whether it's a leap year.  Doing all that 
would make sucking datetimes out of pickles enormously 
slower than it is now (it's merely a 10-byte string copy now).

If we were willing to do all the checks we do on things coming 
through the front door, we wouldn't call it a back door <wink>.

OTOH, we shouldn't allow a hostile user the ability to crash 
the system via constructing a damaged datetime pickle 
either, so maybe the whole "fast back door" idea is impossible 
to rehabilitate.

----------------------------------------------------------------------

Comment By: Michael Dubner (dubnerm)
Date: 2003-11-23 20:36

Message:
Logged In: YES 
user_id=39274

Of cause i've seen that backdoor, but from my point of view
constructor is not so time-critical that insertion of sanity
chechs will slow down in most (sane) scenarios.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2003-11-21 22:16

Message:
Logged In: YES 
user_id=31435

LOL!  Assigned to Guido for his amusement.  One string 
argument of exactly size 10 triggers the "secret" backdoor to 
construct a datetime.datetime from a pickle.  The datetime 
constructed here is insane, and provokes Microsoft's library 
into crashing.  In a debug build, it triggers an assertion error 
in the datetime module:

>>> import datetime
[16122 refs]
>>> datetime.datetime('1995-03-25')
datetime.datetime(12601, 57, 53, 45, 48, 51, 2961973)
[16124 refs]
>>> _.ctime()
Assertion failed: month <= 12, file 
C:\Code\python\Modules\datetimemodule.c, line 189

Boosted priority since it's a way to crash the interpreter on 
Windows.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=847019&group_id=5470