RCE Bypass in Picklescan via Operator Module Primitives

Picklescan is a static analysis tool designed to inspect Python Pickle streams for malicious content without executing them. It operates by parsing the Pickle opcodes and comparing referenced globals (modules and functions) against a predefined list of unsafe signatures. The goal is to allow safe deserialization of data while blocking attempts to execute arbitrary code, a common vector in Python applications processing untrusted serialized data.

The vulnerability, identified as GHSA-955R-X9J8-7RHH, resides in the incompleteness of the scanner's denylist. While Picklescan correctly flagged direct references to obvious execution primitives like os.system, eval, and exec, it failed to account for the standard library's operator and _operator modules. These modules contain higher-order functions that can be used to invoke methods or access attributes on objects indirectly.

By leveraging these overlooked primitives, an attacker can construct a valid Pickle stream that performs the equivalent of os.system(...) but appears benign to the scanner's logic. This results in a complete bypass of the security control, allowing arbitrary code execution on the system performing the scan or deserialization.

The root cause of this vulnerability is a Protection Mechanism Failure (CWE-693) specifically due to an Incomplete List of Disallowed Elements (CWE-184). Picklescan's security model relies on identifying dangerous GLOBAL opcodes. In the Python Pickle protocol, the GLOBAL opcode (or c in protocol 0) instructs the unpickler to import a module and retrieve an attribute.

The scanner maintains a dictionary _unsafe_globals in src/picklescan/scanner.py, which maps module names to sets of dangerous attribute names. Prior to version 0.0.34, this dictionary did not include entries for the operator or _operator modules.

The specific functions methodcaller, attrgetter, and itemgetter in these modules are particularly dangerous in a serialization context because they return callable objects that operate on their arguments. For example, operator.methodcaller('system', 'command') returns a callable that, when applied to the os module, executes os.system('command'). Because the scanner did not recognize operator.methodcaller as a threat, it permitted the creation of this callable, enabling the exploit chain.

The vulnerability existed in the configuration of the _unsafe_globals dictionary. The fix involved explicitly adding the dangerous operator functions to this denylist. The patch ensures that any Pickle stream attempting to import these functions is flagged as malicious.

Below is the relevant change in src/picklescan/scanner.py from commit f2dea43e0c838e09ace1e62994143254b51de927:

# src/picklescan/scanner.py
 
_unsafe_globals = {
    "__builtin__": { ... },  # Existing unsafe builtins
    "builtins": { ... },     # Existing unsafe builtins
    
    # NEWLY ADDED BLOCK: explicit denylist for operator module
    "_operator": {
        "attrgetter",  # Can be used to access dangerous attributes
        "itemgetter",  
        "methodcaller", # Can be used to call dangerous methods
    },
    "operator": {
        "attrgetter",
        "itemgetter",
        "methodcaller",
    },
    # ... existing entries ...
}

The inclusion of both _operator (C implementation) and operator (Python interface) ensures that variations in how the module is imported are covered. Specifically, methodcaller is the most direct vector for RCE, as it allows invoking a method by name with pre-supplied arguments.

To exploit this vulnerability, an attacker constructs a Pickle payload that chains valid, allowed operations to achieve a malicious outcome. The standard approach involves importing a target module (like os) and using operator.methodcaller to invoke a function on it.

The following Pickle assembly (Protocol 0) demonstrates the Proof-of-Concept:

cbuiltins
__import__
(Vos
tRp0                        # Import 'os' and store in memo 0
0c_operator
methodcaller
(Vsystem
Vecho "pwned"               # Create callable: methodcaller('system', 'echo "pwned"')
tR(g0                       # Apply the callable to the 'os' module stored in memo 0
tR.

Step-by-Step Execution Flow:

1. Import: The payload uses builtins.__import__ to load the os module. Picklescan might allow this if strict restrictions aren't placed on __import__, or if the attacker uses other techniques to get a handle on os.
2. Preparation: It invokes _operator.methodcaller with the arguments 'system' and the command string. This creates a "delayed" execution object.
3. Trigger: The payload applies this methodcaller object to the os module instance. Internally, Python executes getattr(os, 'system')('echo "pwned"').
4. Bypass: Since _operator.methodcaller was not in the denylist, Picklescan validates the stream as safe, and the unpickling process executes the command.

The impact of this vulnerability is critical for any system relying on Picklescan as a security boundary for untrusted data. By bypassing the scanner, an attacker gains the ability to execute arbitrary code with the privileges of the process deserializing the data.

• Security Control Bypass: The primary function of the tool—preventing malicious Pickle execution—is completely negated.
• Remote Code Execution (RCE): Successful exploitation leads to full system compromise.
• Confidentiality, Integrity, Availability: All compromised. An attacker can read sensitive data, modify system files, or disrupt services.

While the vulnerability requires the attacker to be able to submit a Pickle file to the target, this is the exact scenario Picklescan is designed to handle. Therefore, the exposure is high for any deployment of the tool.

Users of picklescan must upgrade to version 0.0.34 or later immediately. This version includes the updated denylist that blocks the operator module primitives.

Remediation Steps:

1. Update Package: Run pip install --upgrade picklescan.
2. Verify Version: Ensure the installed version is >= 0.0.34.
3. Rescan Data: If you have stored Pickle files that were previously scanned and deemed "safe" by an older version of Picklescan, treat them as potentially compromised and rescan them with the updated version.

Defense in Depth:

It is widely acknowledged that the Python Pickle format is inherently insecure. Security scanners like Picklescan provide a layer of defense but should not be the sole control for untrusted data. Where possible, switch to safer serialization formats like JSON. If Pickle must be used, ensure cryptographic signing (HMAC) is validated before any deserialization or scanning attempts.