Sign (or encrypt) pickle cache traffic to protect against remote code execution through cache takeover

[Sebastian Pipping]

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?

[Tim Graham]

Hello again Sebastian,

I think the historic consensus has been that if the machine your cache runs on is compromised, signing/encrypting the data will not help much, and since a cache is supposed to be very fast, the performance overhead isn't acceptable.

To propose a new feature like this, the proper channel is the ​Django Internals section of Django forum (which reaches a wider audience than.this ticket tracker).

If there is consensus to make a change, we'll reopen and accept this ticket. Thanks!