CVE-2022-1962

What it actually does

A flaw in the Go language's standard library parser (`go/parser`) allows for uncontrolled recursion when parsing source code with deeply nested types or declarations. An attacker can supply a specially crafted Go source file that causes the parser to exhaust the call stack, triggering a panic that crashes the application. This vulnerability affects any program that uses the vulnerable parser functions to process untrusted Go source code.

Why it matters to the business

Applications built with vulnerable Go versions that parse Go source code are susceptible to a Denial of Service (DoS). This includes common development tools like linters, IDEs, code analysis platforms, and security scanners. If these services are publicly exposed, an attacker can repeatedly crash them, leading to service unavailability, disruption of development and security workflows, and potential reputational damage.

How an attack unfolds

An attacker identifies a target service that ingests Go source code for processing, such as a code quality checker or an online development environment. The attacker crafts a simple but malicious Go source file containing a deeply nested type declaration (e.g., `type T [100000]T`). They then submit this file to the target service. The service, using a vulnerable version of Go's `go/parser` library, attempts to parse the file. The parser's recursive logic for handling type definitions is not properly bounded, causing it to recurse to an excessive depth. This exhausts the program's call stack, leading to a stack overflow. The Go runtime detects this condition and triggers a panic, which terminates the entire application process, resulting in a successful denial of service.

How to fix it

To remediate this vulnerability, update the Go toolchain to a patched version and recompile any affected applications. The issue is resolved in Go versions 1.17.12 and 1.18.4, and all subsequent releases. Ensure that all build environments and developer machines are updated to use a non-vulnerable version of Go.

How to confirm the fix worked

To confirm remediation, verify the Go version used to build your applications. You can check this by running `go version` in the build environment. For a compiled binary, you can often check its build information using `go version -m /path/to/binary`. The Go version reported should be 1.17.12+, 1.18.4+, or a newer major version. Additionally, you can perform a safe test in a non-production environment by attempting to parse a known-bad file designed to trigger the vulnerability; a patched application should handle it gracefully by returning a parse error instead of crashing.

Typical attack path

1. Attacker identifies a target application that uses a vulnerable version of the Go compiler (before 1.17.12 or 1.18.4) to parse untrusted Go source code.
2. Attacker crafts a malicious Go source file containing deeply nested declarations or type definitions.
3. Attacker submits the malicious file to the target application, for example, through a file upload feature or an API endpoint.
4. The application's parser attempts to process the malicious code, triggering an uncontrolled recursion.
5. The recursion exhausts the call stack, causing a stack overflow.
6. The Go runtime panics and terminates the application, resulting in a denial of service.

How to detect it

To detect potential exploitation, review application logs for Go panic messages indicating a stack overflow. A typical indicator is a log entry containing `panic: runtime error: stack overflow`. The stack trace associated with the panic will likely show deep recursion within functions from the `go/parser` package. Correlate the timestamps of these crashes with logs of input data to identify if a specific source file submission caused the event. Monitor for abnormal crash/restart cycles in services known to parse Go code.

• panic: runtime error: stack overflow

What your security team should do

• Identify all applications and build systems within your organization that use the Go programming language.
• Prioritize systems that parse or process untrusted Go source code, as they are directly exposed to this vulnerability.
• Update all Go development and build environments to version 1.17.12, 1.18.4, or a more recent stable release.
• Rebuild and redeploy all Go applications using the patched toolchain to ensure they are no longer vulnerable.