GHSA-5p39-cfhj-2xmp: Pip/anyio vulnerability
Impact AnyIO starts process-pool workers with stderr connected to a pipe but never drains that pipe. The worker redirects stdin and stdout to /dev/null to protect its protocol, but does not redirect stderr even though the documentation says all three standard streams are redirected. Worker code that writes enough attacker-influenced data to stderr can fill the pipe, block before returning the stdout protocol response, and wedge the awaiting process-pool call.
Anyone who runs untrusted or faulty code that writes too much to stderr is at risk.
Patches This vulnerability will be patched in v4.14.2.
Workarounds Closing sys.stderr in the target function should at least prevent the deadlock.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
pip/anyioto a version that resolves this vulnerability.Fixed in 4.14.2 - Upgrade
Upgrade to a fixed release to a version that resolves this vulnerability.
Fixed in 4.14.2 - Configuration
As a workaround, close `sys.stderr` in the target function so the worker’s pipe connected to `stderr` is not left to fill and deadlock.
AnyIO process-pool worker stderr handling = Close sys.stderr in the target function (or otherwise redirect/drain stderr to prevent pipe filling) - Configuration
Update the worker so `stderr` is also redirected (the worker currently redirects `stdin` and `stdout` to `/dev/null` but not `stderr`, despite documentation stating all three standard streams are redirected).
AnyIO process-pool worker stderr redirection = Redirect stderr to /dev/null (like stdin and stdout)
Event History
Frequently Asked Questions
Who is most likely to be affected?
Applications that use AnyIO process-pool workers to run untrusted or faulty code are at risk when that code can write a large amount of attacker-influenced data to stderr.
What must happen for exploitation or failure to occur?
Code running in a process-pool worker must write enough data to stderr to fill the worker's undrained stderr pipe. The worker then blocks before sending its stdout protocol response, causing the awaiting process-pool call to wedge.
Is there a mitigation if updating is not immediately possible?
Closing sys.stderr in the target function should at least prevent the deadlock. The issue is planned to be patched in v4.14.2.