Opened 4 years ago

Closed 4 years ago

Last modified 4 years ago

#31895 closed Bug (fixed)

Decoding an invalid session data crashes.

Reported by: Matt Hegarty Owned by: Mariusz Felisiak
Component: contrib.sessions Version: 3.1
Severity: Release blocker Keywords: incorrect padding, badsignature
Cc: Claude Paroz Triage Stage: Accepted
Has patch: yes Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: no UI/UX: no

Description (last modified by Matt Hegarty)

Hi
I recently upgraded my staging server to 3.1. I think that there was an old session which was still active.
On browsing to any URL, I get the crash below. It looks similar to this issue.

I cannot login at all with Chrome - each attempt to access the site results in a crash. Login with Firefox works fine.

This is only happening on my Staging site, which is running Gunicorn behind nginx proxy.

Internal Server Error: /overview/
Traceback (most recent call last):
File "/usr/local/lib/python3.8/site-packages/django/contrib/sessions/backends/base.py", line 215, in _get_session
return self._session_cache
AttributeError: 'SessionStore' object has no attribute '_session_cache'
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "/usr/local/lib/python3.8/site-packages/django/contrib/sessions/backends/base.py", line 118, in decode
return signing.loads(session_data, salt=self.key_salt, serializer=self.serializer)
File "/usr/local/lib/python3.8/site-packages/django/core/signing.py", line 135, in loads
base64d = TimestampSigner(key, salt=salt).unsign(s, max_age=max_age).encode()
File "/usr/local/lib/python3.8/site-packages/django/core/signing.py", line 201, in unsign
result = super().unsign(value)
File "/usr/local/lib/python3.8/site-packages/django/core/signing.py", line 184, in unsign
raise BadSignature('Signature "%s" does not match' % sig)
django.core.signing.BadSignature: Signature "xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx" does not match
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "/usr/local/lib/python3.8/site-packages/django/core/handlers/exception.py", line 47, in inner
response = get_response(request)
File "/usr/local/lib/python3.8/site-packages/django/core/handlers/base.py", line 179, in _get_response
response = wrapped_callback(request, *callback_args, **callback_kwargs)
File "/usr/local/lib/python3.8/site-packages/django/views/generic/base.py", line 73, in view
return self.dispatch(request, *args, **kwargs)
File "/usr/local/lib/python3.8/site-packages/django/contrib/auth/mixins.py", line 50, in dispatch
if not request.user.is_authenticated:
File "/usr/local/lib/python3.8/site-packages/django/utils/functional.py", line 240, in inner
self._setup()
File "/usr/local/lib/python3.8/site-packages/django/utils/functional.py", line 376, in _setup
self._wrapped = self._setupfunc()
File "/usr/local/lib/python3.8/site-packages/django_otp/middleware.py", line 38, in _verify_user
user.otp_device = None
File "/usr/local/lib/python3.8/site-packages/django/utils/functional.py", line 270, in __setattr__
self._setup()
File "/usr/local/lib/python3.8/site-packages/django/utils/functional.py", line 376, in _setup
self._wrapped = self._setupfunc()
File "/usr/local/lib/python3.8/site-packages/django/contrib/auth/middleware.py", line 23, in <lambda>
request.user = SimpleLazyObject(lambda: get_user(request))
File "/usr/local/lib/python3.8/site-packages/django/contrib/auth/middleware.py", line 11, in get_user
request._cached_user = auth.get_user(request)
File "/usr/local/lib/python3.8/site-packages/django/contrib/auth/__init__.py", line 174, in get_user
user_id = _get_user_session_key(request)
File "/usr/local/lib/python3.8/site-packages/django/contrib/auth/__init__.py", line 58, in _get_user_session_key
return get_user_model()._meta.pk.to_python(request.session[SESSION_KEY])
File "/usr/local/lib/python3.8/site-packages/django/contrib/sessions/backends/base.py", line 65, in __getitem__
return self._session[key]
File "/usr/local/lib/python3.8/site-packages/django/contrib/sessions/backends/base.py", line 220, in _get_session
self._session_cache = self.load()
File "/usr/local/lib/python3.8/site-packages/django/contrib/sessions/backends/db.py", line 44, in load
return self.decode(s.session_data) if s else {}
File "/usr/local/lib/python3.8/site-packages/django/contrib/sessions/backends/base.py", line 122, in decode
return self._legacy_decode(session_data)
File "/usr/local/lib/python3.8/site-packages/django/contrib/sessions/backends/base.py", line 126, in _legacy_decode
encoded_data = base64.b64decode(session_data.encode('ascii'))
File "/usr/local/lib/python3.8/base64.py", line 87, in b64decode
return binascii.a2b_base64(s)
binascii.Error: Incorrect padding

Attachments (1)

31895 (1.9 KB ) - added by Torsten Bronger 4 years ago.
Traceback with 3.0.8

Download all attachments as: .zip

Change History (15)

comment:1 by Matt Hegarty, 4 years ago

Description: modified (diff)

comment:2 by Matt Hegarty, 4 years ago

I tried to run clearsessions, but that didn't help. The only workaround was to delete all rows in the django_session table.

comment:3 by Mariusz Felisiak, 4 years ago

Component: UncategorizedCore (Other)
Resolution: needsinfo
Status: newclosed
Summary: process crash after upgrade to 3.1: Incorrect paddingProcess crash after upgrade to 3.1: Incorrect padding

Thanks for this report, however I cannot reproduce this issue. Can you provide a sample project?

Support for user sessions created by older versions of Django remains until Django 4.0. See similar tickets #31864, #31592, and #31274, this can be a duplicate of one of them.

comment:4 by Matt Hegarty, 4 years ago

Thanks for the response. It does look similar to the other issues you posted. I don't have a reproducible instance at present. The only way I can think to reproduce would be to start up a 3.0 site, login, wait for the session to expire, then upgrade to 3.1. These are the steps that would have happened on the environment where I encountered the issue.

comment:5 by Mariusz Felisiak, 4 years ago

Component: Core (Other)contrib.sessions
Severity: NormalRelease blocker
Summary: Process crash after upgrade to 3.1: Incorrect paddingDecoding an invalid session data crashes.
Triage Stage: UnreviewedAccepted
Type: UncategorizedBug

Thanks I was able to reproduce this issue with an invalid session data.

Version 0, edited 4 years ago by Mariusz Felisiak (next)

comment:6 by Mariusz Felisiak, 4 years ago

Resolution: needsinfo
Status: closednew

comment:7 by Mariusz Felisiak, 4 years ago

Owner: changed from nobody to Mariusz Felisiak
Status: newassigned

comment:8 by Mariusz Felisiak, 4 years ago

Cc: Claude Paroz added
Has patch: set

comment:9 by GitHub <noreply@…>, 4 years ago

Resolution: fixed
Status: assignedclosed

In 4376c2c7:

Fixed #31895 -- Fixed crash when decoding invalid session data.

Thanks Matt Hegarty for the report.
Regression in d4fff711d4c97356bd6ba1273d2a5e349326eb5f.

comment:10 by Mariusz Felisiak <felisiak.mariusz@…>, 4 years ago

In 7eaa277:

[3.1.x] Fixed #31895 -- Fixed crash when decoding invalid session data.

Thanks Matt Hegarty for the report.
Regression in d4fff711d4c97356bd6ba1273d2a5e349326eb5f.
Backport of 4376c2c7f8cd9c7604a7d053b3c4022dd5ac2795 from master

comment:11 by Torsten Bronger, 4 years ago

Django 3.0.9 is also affected, and according to the release notes, 3.0.10 probably too.

in reply to:  11 comment:12 by Mariusz Felisiak, 4 years ago

Replying to Torsten Bronger:

Django 3.0.9 is also affected, and according to the release notes, 3.0.10 probably too.

This is a fix for a regression in Django 3.1, so Django 3.0 cannot be affected.

by Torsten Bronger, 4 years ago

Attachment: 31895 added

Traceback with 3.0.8

comment:13 by Torsten Bronger, 4 years ago

I attached the traceback we see with 3.0.8. It is not the same but very similar, and the point in time since we observe this also matches with this bug. Furthermore, the master branch solves this problem for us.

Do you still think it is a different problem? If so, I file a new report.

comment:14 by Mariusz Felisiak, 4 years ago

This can be a duplicate of #31592 (downgrade is not supported).

Moreover, Django 3.0 is in extended support so it doesn't receive bugfixes anymore (except security fixes). Therefore even if you hit a different (but similar) issue in Django 3.0 (without any sessions created in Django 3.1+) it will not qualify for a backport based on our supported versions policy.

Note: See TracTickets for help on using tickets.
Back to Top