2 ms·
Can we stop bringing up "pickles are not a safe way to deserialize data" for things that do not matter, like caching on local machine? Yes, pickle can be explo
by theamk 3y ago
Can we stop bringing up "pickles are not a safe way to deserialize data" for things that do not matter, like caching on local machine?
Yes, pickle can be exploited by someone with ~/ write access. But you know what else someone with that access do? Append to .bashrc, add to desktop startup script, create pth file in local python dist, create usercustomize, append code into any locally installed libraries, add code to config of many editors...
I've seen so much effort wasted because people rejected pickle for being insecure in contexts where it doesn't matter at all.
- westurner 3y agoIf there is a privilege escalation or just an OS exec() as the app process user in a container with no interactive shell, no desktop, root-owned site-packages configured at image build time, and/or a pex zipapp or similar with no ~/.local (`type -a python; python -m site`) then it can write() to the on disk files or a database with schema and field length limits that doesn't store code.
- theamk 3y agoI am having trouble parsing your reply, looks like some parts are missing. Can you rephrase? We were talking about jupyter notebooks, which are typically used for exploratory work, and thus are executed either on local desktop under default user account, or in containers with pretty open access controls. My point was that under those circumstances, it is OK to assume any cache data is trusted. Your reply somehow talks about secured containers and privilege escalation but I cannot figure out how is it connected to running Jupyter on local laptop, nor the threat model you are worried about.
- westurner 3y agoI replied to the stated security risks with specific controls. Should the app write additional .py files next to itself and exec those? That's what caching code blocks as pickles on disk would get you there.