New submission from mike bayer <[email protected]>:
So I'm pretty sure this is "not a bug" but it's a bit of a problem and I have a
user suggesting the "security vulnerability" bell on this one, and to be honest
I don't even know what any library would do to "prevent" this.
Basically, the datetime() object limits based on a numerical year of MINYEAR,
rather than limiting based on an actual logical date.
So I can create an "impossible" date as follows:
d = datetime.strptime("Mon Jan 1 00:00:00 0001 +01:00", "%c %z")
or like this:
d = datetime(year=1, month=1, day=1, tzinfo=timezone(timedelta(hours=1)))
and....you can see where this is going - it can't be converted to a timezone
that pushes the year to zero:
>>> from datetime import datetime, timezone, timedelta
>>> d = datetime(year=1, month=1, day=1, tzinfo=timezone(timedelta(hours=1)))
>>> d.astimezone(timezone.utc)
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
OverflowError: date value out of range
this because, after all, astimezone() is just subraction or addition and if it
overflows past the artificial boundary, well you're out of luck.
Why's this a security problem? ish? because PostgreSQL has a data type
"TIMESTAMP WITH TIMEZONE" and if you take said date and INSERT it into your
database, then SELECT it back using any Python DBAPI that returns datetime()
objects like psycopg2, if your server is in a timezone with zero or negative
offset compared to the given date, you get an error. So the mischievous user
can create that datetime for some reason and now they've broken your website
which can't SELECT that table anymore without crashing.
So, suppose you maintain the database library that helps people send data in
and out of psycopg2. We have, the end user's application, we have the
database abstraction library, we have the psycopg2 driver, we have Python's
datetime() object with MIN_YEAR, and finally we have PostgreSQL with the
TIMEZONE WITH TIMESTAMP datatype that I've never liked.
Of those five roles, whose bug is this? I'd like to say it's the end user
for letting untrusted input that can put unusual timezones and timestamps in
their system. But at the same time it's a little weird Python is letting me
create this date that lacks the ability to convert into UTC. thanks for
reading!
----------
components: Library (Lib)
messages: 388585
nosy: zzzeek
priority: normal
severity: normal
status: open
title: we can create valid datetime objects that become invalid if the timezone
is changed
versions: Python 3.10, Python 3.6, Python 3.7, Python 3.8, Python 3.9
_______________________________________
Python tracker <[email protected]>
<https://bugs.python.org/issue43484>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
