safety problem

[MuslimBeibytuly]

docker image:
python:3.9.5-slim
apache-airflow==2.1.0

[taylorwilsdon]

Watching this as well, it's not really an issue with flask-caching directly but rather it's use of Pickle for serialization (it's the usage of Pickle that creates the vulnerability) - the CVE is https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-33026 and for whatever its worth, there are many (many!) other libraries that share the same "vulnerability" and many have disputed that, Flask-Caching has not.

[MuslimBeibytuly]

@tbarrettwilsdon is there a opportunity to change default serialization format to xml/json(using ujson/orjson), but saving an option to keep current pickle serialization?

[maxim-smirnov]

Watching this as well, it's not really an issue with flask-caching directly but rather it's use of Pickle for serialization (it's the usage of Pickle that creates the vulnerability) - the CVE is https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-33026 and for whatever its worth, there are many (many!) other libraries that share the same "vulnerability" and many have disputed that, Flask-Caching has not.

@tbarrettwilsdon
Other libraries have stated, that pickle is not used with untrusted data. In this case (flask-caching) Redis, Memcached or other caching backend can be used, so malicious payload can be injected.

[ndouchin]

There is an open merge request for this issue: #209

Thanks to this MR, we would be able to choose which serializer we want to use with Flask-Caching.

[swiftace]

Is this likely to be fixed or the MR above merged soon? This is causing me problems with an upstream component requiring Flask-Caching as a dependency.

[ThiefMaster]

IMHO the CVE is bogus. If someone has write access to your cache's storage, you are most likely already compromised. So it's perfectly fine and safe to use this extension (or a component using it) as long as your environment is properly configured and secured (ie don't expose your redis/memcached to untrusted users or the internet, and don't let untrusted users write arbitrary files on your server if you use file-based storage)

[long76]

+1
Dependabot alerts

[torotil]

If someone has write access to your cache's storage, you are most likely already compromised.

I agree mostly, but there is the odd chance that an attacker can somehow manipulate cached values without having already enough privileges to execute arbitrary Python code (as the flask app user). Essentially this turns any cache poisoning attack into an arbitrary code execution attack.

[ThiefMaster]

AFAIK cache poisoning usually means caching user-controlled data through some vulnerability (e.g. in order to serve bad data to other users), but not being able to write raw data to the cache backend through other means..

[torotil]

Ok, I might have used the word “cache poisoning“ wrongly. The thought still applies. Write access to the cache backend doesn’t imply the ability to execute arbitrary code (or even access as a local user). So this could be used for privilege escalation.

[northernSage]

Means of avoiding pickle by using custom serialization strategies have being added to cachelib in pallets-eco/cachelib#63 which will soon be integrated with flask-caching. See #308 and #209 for more information.