Severity: 🟡 medium • Category: doc-mismatch
Location: SECURITY.md : 1-25
What's wrong
The shared backend deserializes cached values and keys from an mmap'd file using pickle.loads as a fallback for any non-primitive type (shared_store.rs:286, deserialize_value). The backing files live in world-accessible locations (/dev/shm on Linux, $TMPDIR/warp_cache/ on macOS) and are created with default OpenOptions (no explicit mode, region.rs:54-69), so their permissions are governed only by the process umask. Any local user/process able to write to that file can inject a malicious pickle payload that executes arbitrary code in every process that reads the cache (classic pickle RCE). SECURITY.md says nothing about this trust model, the pickle risk, or file-permission hardening. For a library shipping a cross-process pickle-over-shared-memory feature, this is a material disclosure gap.
Trigger
A local attacker (or a compromised co-located process) writes a crafted pickle payload into the warp_cache .data file under /dev/shm or $TMPDIR/warp_cache; the next process to read that key executes the payload. Not disclosed anywhere in SECURITY.md.
Suggested fix
Add a 'Security considerations' section to SECURITY.md (and ideally a warning in usage.md's shared-backend section) stating that the shared backend uses pickle for non-primitive values, that its mmap files are only as secure as their filesystem permissions/umask, and that the shared backend must only be used in a single trust domain. Consider restricting file mode (e.g., 0600) as a hardening measure.
Adversarial verification note
All factual claims verified against the real code. (1) Pickle fallback confirmed at src/shared_store.rs:284-287 (deserialize_value calls self.pickle_loads.bind(py).call1((payload,))), with TAG_PICKLE handling in src/serde.rs:9,32-54. (2) File creation at src/shm/region.rs:54-69 uses fs::OpenOptions with .read/.write/.create/.truncate and no .mode()/permission restriction; grep over src/shm/ finds no mode/chmod/set_permissions/0o600/umask, so permissions are governed solely by umask. (3) Backing files live in world-accessible directories: src/shm/region.rs:16-20 returns /dev/shm on Linux and $TMPDIR/warp_cache otherwise. (4) SECURITY.md (lines 1-25) contains only reporting instructions; it says nothing about pickle, shared memory, or file permissions. docs/usage.md and README mention pickle only as a serialization/perf detail, never as a security/trust concern. So the disclosure gap is real and the cited mechanism (pickle deserialization from an mmap file whose write permissions follow umask) is an accurate description of a classic pickle-RCE trust boundary. However, the finding is a doc-mismatch/hardening recommendation, not a code defect: the code is not malfunctioning, and exploitation requires same-user access or a permissive umask / shared multi-user /dev/shm (default umask 022 yields 0644 = world-readable but owner-only-writable, so an arbitrary unprivileged user cannot inject payloads under default config). Pickle's deserialization risk is also broadly known to Python developers and the shared backend is opt-in. Therefore the bug is real but 'high' overstates it; medium is appropriate for a legitimate but conditional, documentation-level disclosure gap.
Verifier correction: The finding is valid but mis-severified. It is a documentation/hardening gap (the code works as designed), and the RCE attack is conditioned on same-user access or a misconfigured/permissive umask or a shared multi-user shm directory, not trivially exploitable by any local user under default umask (022 -> 0644, world-readable but only owner-writable). Severity is medium, not high.
Filed from a multi-agent code review (finder → adversarial verification → synthesis). Confirmed real after a skeptic re-read the code.
Severity: 🟡 medium • Category: doc-mismatch
Location:
SECURITY.md: 1-25What's wrong
The shared backend deserializes cached values and keys from an mmap'd file using pickle.loads as a fallback for any non-primitive type (shared_store.rs:286, deserialize_value). The backing files live in world-accessible locations (/dev/shm on Linux, $TMPDIR/warp_cache/ on macOS) and are created with default OpenOptions (no explicit mode, region.rs:54-69), so their permissions are governed only by the process umask. Any local user/process able to write to that file can inject a malicious pickle payload that executes arbitrary code in every process that reads the cache (classic pickle RCE). SECURITY.md says nothing about this trust model, the pickle risk, or file-permission hardening. For a library shipping a cross-process pickle-over-shared-memory feature, this is a material disclosure gap.
Trigger
A local attacker (or a compromised co-located process) writes a crafted pickle payload into the warp_cache .data file under /dev/shm or $TMPDIR/warp_cache; the next process to read that key executes the payload. Not disclosed anywhere in SECURITY.md.
Suggested fix
Add a 'Security considerations' section to SECURITY.md (and ideally a warning in usage.md's shared-backend section) stating that the shared backend uses pickle for non-primitive values, that its mmap files are only as secure as their filesystem permissions/umask, and that the shared backend must only be used in a single trust domain. Consider restricting file mode (e.g., 0600) as a hardening measure.
Adversarial verification note
All factual claims verified against the real code. (1) Pickle fallback confirmed at src/shared_store.rs:284-287 (deserialize_value calls self.pickle_loads.bind(py).call1((payload,))), with TAG_PICKLE handling in src/serde.rs:9,32-54. (2) File creation at src/shm/region.rs:54-69 uses fs::OpenOptions with .read/.write/.create/.truncate and no .mode()/permission restriction; grep over src/shm/ finds no mode/chmod/set_permissions/0o600/umask, so permissions are governed solely by umask. (3) Backing files live in world-accessible directories: src/shm/region.rs:16-20 returns /dev/shm on Linux and $TMPDIR/warp_cache otherwise. (4) SECURITY.md (lines 1-25) contains only reporting instructions; it says nothing about pickle, shared memory, or file permissions. docs/usage.md and README mention pickle only as a serialization/perf detail, never as a security/trust concern. So the disclosure gap is real and the cited mechanism (pickle deserialization from an mmap file whose write permissions follow umask) is an accurate description of a classic pickle-RCE trust boundary. However, the finding is a doc-mismatch/hardening recommendation, not a code defect: the code is not malfunctioning, and exploitation requires same-user access or a permissive umask / shared multi-user /dev/shm (default umask 022 yields 0644 = world-readable but owner-only-writable, so an arbitrary unprivileged user cannot inject payloads under default config). Pickle's deserialization risk is also broadly known to Python developers and the shared backend is opt-in. Therefore the bug is real but 'high' overstates it; medium is appropriate for a legitimate but conditional, documentation-level disclosure gap.
Filed from a multi-agent code review (finder → adversarial verification → synthesis). Confirmed real after a skeptic re-read the code.