[Django] #35905: Please start signing (or encrypting) pickle cache traffic to protect against remote code execution through cache takeover, by default

[Django]

#35905: Please start signing (or encrypting) pickle cache traffic to protect
against remote code execution through cache takeover, by default
-------------------------------------+-------------------------------------
Reporter: Sebastian Pipping | Type: Bug
Status: new | Component: Core
| (Cache system)
Version: dev | Severity: Normal
Keywords: cache security | Triage Stage:
| Unreviewed
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
Hi!

Multiple of the Django cache backends at `django/core/cache/backends/*.py`
seem to make use of pickle:

{{{
# git --no-pager grep -ilF pickle django/core/cache/backends/
django/core/cache/backends/db.py
django/core/cache/backends/filebased.py
django/core/cache/backends/locmem.py
django/core/cache/backends/memcached.py
django/core/cache/backends/redis.py
}}}

From what I can see, none of them sign or encrypt what goes into and out
of the cache, despite available tools in `django/core/signing.py`. For
local process memory, that may be alright, and for file system based
caches it's probably understood that using a directory that is writable to
attackers is trouble anyway. The most interesting I believe are
`memcached.py` and `redis.py` because now if an attacker obtains write
access to the instance of memcached or Redis that is used for a Django
cache backend, they gain arbitrary code execution in Django. That's
probably known for years (and explained at e.g.
https://www.blackduck.com/blog/python-pickling.html or
https://davidhamann.de/2020/04/05/exploiting-python-pickle/), yet neither
of these two backends have started signing (and validating the signature)
or encrypting (and decrypting) the cache traffic yet. There is some
performance penalty to be expected but a new boolean cache option `SIGN`
could turn its default back from "sign, validate and be secure" to
"insecure and faster" for users that have a threat model where owning the
cache was game over already and they sign up for the risk.

Recent case
https://github.com/climateconnect/climateconnect/pull/1331#issuecomment-2397881433
is an example of a setup where use of a pickling cache lead to potential
remote code execution, which is one reason I'm bringing this up here.

I can help with one or more pull requests on the topic, provided that
there is agreement on its importance, its value and general direction.

What do you think?
--
Ticket URL: <https://code.djangoproject.com/ticket/35905>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.