CVE-2024-34155

What it actually does

A vulnerability exists in Go's standard library parser functions where processing source code with deeply nested literals can lead to excessive recursion. This consumes the entire call stack, causing a stack exhaustion panic that abruptly terminates the application process, resulting in a denial of service.

Why it matters to the business

An attacker can crash any service that parses untrusted Go source code, leading to service unavailability. This can disrupt development pipelines, code analysis tools, security scanners, or any user-facing application that processes Go code snippets. The operational impact is service downtime and potential disruption of dependent processes until the service is restarted.

How an attack unfolds

An attacker crafts a piece of Go source code containing an abnormally deep nesting of literal expressions (e.g., nested structs or arrays). They submit this malicious code to a target application or service that uses Go's native parser functions. When the vulnerable application attempts to parse the input, the recursive nature of the parser rapidly consumes the call stack, triggering a stack overflow. This results in a runtime panic, which crashes the entire process, causing a denial of service.

How to fix it

To remediate this vulnerability, update the Go toolchain to a patched version and recompile the affected applications. For third-party software, upgrade to a version that has been built with a non-vulnerable Go compiler. For example, users of 'github.com/answerdev/answer' should upgrade to version 1.0.6 or later.

How to confirm the fix worked

To validate the fix, verify that the application is running a version confirmed to be patched by the vendor. You can also check the Go version used to build the binary by running 'go version <binary_name>'. Additionally, a non-production instance of the application can be tested by submitting a proof-of-concept file with deeply nested literals to confirm it no longer crashes.

Typical attack path

1. The attacker identifies a service that accepts Go source code as input (e.g., a code linter, an online IDE, or a documentation generator).
2. The attacker crafts a malicious Go file with deeply nested literal structures designed to trigger a stack overflow.
3. The attacker submits the malicious code to the target application via an API endpoint, file upload, or web form.
4. The application's Go parser attempts to process the input, leading to stack exhaustion.
5. The application process panics and crashes, causing a denial of service.

How to detect it

Monitor application logs for Go runtime panic messages indicating stack exhaustion or stack overflow. These events would likely occur immediately after the application attempts to process a new input. Correlate application crash logs with upstream service logs (e.g., load balancer or reverse proxy logs) that may show 5xx error codes indicating the backend service became unresponsive.

• panic: runtime error: stack overflow
• fatal error: stack exhaustion

What your security team should do

• Identify and prioritize patching for any internet-facing applications that parse untrusted Go source code.
• Scan your software inventory to find all applications built with vulnerable versions of Go and create a plan to recompile them using a patched toolchain.
• For affected third-party Go applications like 'github.com/answerdev/answer', upgrade to the vendor-supplied patched version (1.0.6 or newer) immediately.