T09 · Insecure Skill Coding Practices
- Location
scripts/auth.py:58- Finding
Unsafe Deserialization of Attacker-Controlled OAuth Token Files
- Content
View full analysis
Vulnerability Details
File Location:
scripts/auth.py:58-60,scripts/clean.py:49-51,scripts/deep_clean.py:39-41,scripts/organize.py:95-97,scripts/restore.py:53-55, andscripts/scan.py:29-31
Vulnerability Type: Unsafe Python pickle deserialization
Risk Level: HighVulnerable Code
The following pattern appears in every Gmail utility:
python with open(args.token, 'rb') as f: creds = pickle.load(f)The token path is supplied through a command-line argument. For example,
scripts/clean.pydefines it as follows:python parser.add_argument('--token', default=DEFAULT_TOKEN) with open(args.token, 'rb') as f: creds = pickle.load(f) if creds.expired and creds.refresh_token: creds.refresh(Request()) with open(args.token, 'wb') as f: pickle.dump(creds, f)Technical Analysis
Python pickle is an executable serialization format. During
pickle.load(), objects may define reduction operations that invoke arbitrary Python callables. Consequently, loading a pickle does not merely parse data: a malicious pickle can execute operating-system commands before the returned object is used.Each affected script accepts an arbitrary token-file path through
--tokenand passes that file directly topickle.load()without verifying its origin, ownership, permissions, type, or integrity. An attacker who can provide a token file, replace the default token, influence a wrapper command, or write to the token directory can therefore obtain code execution when the victim runs any affected utility.The issue is present at these locations:
scripts/auth.py:58-60scripts/clean.py:49-51scripts/deep_clean.py:39-41scripts/organize.py:95-97scripts/restore.py:53-55scripts/scan.py:29-31
Attack Path
- An attacker creates a malicious pickle whose reduction payload invokes a command, Python function, or executable.
- The att ...[truncated 1582 chars]
- Remediation
View remediation
Remediation Suggestions
- Replace pickle token storage with a non-executable format. Use Google credential JSON serialization or another strictly data-only representation.
- Parse only an explicit allowlist of credential fields and reject unknown or incorrectly typed values.
- Migrate existing trusted pickle tokens once, then delete the legacy pickle files. Do not automatically deserialize arbitrary legacy files during normal operation.
- Store token files in a fixed, application-controlled directory rather than accepting arbitrary paths by default.
- Enforce restrictive permissions:
- create directories with mode
0700; - create token files with mode
0600; - reject token files owned by another user;
- reject symbolic links and non-regular files.
- create directories with mode
- Use atomic writes with a securely created temporary file in the same protected directory.
- If legacy pickle loading is temporarily unavoidable, clearly require an explicit migration command and only accept an owner-controlled regular file from the protected token directory. This reduces exposure but does not make unpickling intrinsically safe.
- Revoke and regenerate tokens if an existing pickle file may have come from an untrusted source.
