CVE-2023-29453 in Zabbix
Summary
by MITRE • 10/25/2023
Templates do not properly consider backticks (`) as Javascript string delimiters, and do not escape them as expected. Backticks are used, since ES6, for JS template literals. If a template contains a Go template action within a Javascript template literal, the contents of the action can be used to terminate the literal, injecting arbitrary Javascript code into the Go template. As ES6 template literals are rather complex, and themselves can do string interpolation, the decision was made to simply disallow Go template actions from being used inside of them (e.g., "var a = {{.}}"), since there is no obviously safe way to allow this behavior. This takes the same approach as github.com/google/safehtml. With fix, Template. Parse returns an Error when it encounters templates like this, with an ErrorCode of value 12. This ErrorCode is currently unexported but will be exported in the release of Go 1.21. Users who rely on the previous behavior can re-enable it using the GODEBUG flag jstmpllitinterp=1, with the caveat that backticks will now be escaped. This should be used with caution.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 10/25/2023
The vulnerability described in CVE-2023-29453 represents a critical security issue within Go's template processing system that stems from improper handling of JavaScript template literals. This flaw specifically affects the Go template engine's ability to distinguish between Go template actions and JavaScript template literals, creating a potential code injection vector. The vulnerability arises because backticks serve as JavaScript template literal delimiters since ES6, and when Go templates contain JavaScript code within these literals, the template parser fails to properly escape or isolate the Go template actions that might be present. This misconfiguration allows attackers to inject arbitrary JavaScript code by exploiting the interaction between Go template syntax and JavaScript template literal syntax.
The technical implementation of this vulnerability occurs when a Go template contains a JavaScript template literal that includes a Go template action such as {{.}}. The Go template parser does not adequately account for the complex nature of ES6 template literals, which support string interpolation and can contain nested expressions. When processing such templates, the parser may interpret the contents of a Go template action as terminating the JavaScript template literal, thereby allowing malicious code injection. This behavior creates a fundamental security gap where the template engine cannot safely distinguish between template processing contexts and JavaScript execution contexts. The vulnerability directly maps to CWE-94, which describes "Improper Control of Generation of Code ('Code Injection')" and aligns with ATT&CK technique T1203, "Exploitation for Client Execution" as it enables arbitrary code execution through template processing.
The operational impact of this vulnerability is significant as it can lead to arbitrary code execution within applications that rely on Go templates for rendering dynamic content. Attackers could exploit this weakness in web applications that process user input through Go templates, potentially leading to complete system compromise. The fix implemented by the Go team addresses this by introducing a validation mechanism that returns an error when encountering problematic template patterns, specifically using an ErrorCode value of 12. This error code is currently unexported but will be made available in Go 1.21, indicating the severity and intentional nature of the security fix. The approach taken mirrors that of google/safehtml, which demonstrates industry-recognized best practices for handling template literal security concerns.
Organizations using Go templates must carefully evaluate their applications for potential exposure to this vulnerability, particularly those that process user-provided data or allow dynamic template generation. The recommended mitigation strategy involves updating to the patched version of Go and ensuring that existing templates do not contain problematic patterns that would trigger the error condition. For legacy applications that require the previous behavior, the GODEBUG flag jstmpllitinterp=1 provides a temporary workaround, though this approach carries inherent risks as it re-enables potentially dangerous template literal interpretation. Security teams should conduct thorough code reviews to identify any templates that might be vulnerable and implement proper input validation and sanitization measures. The vulnerability highlights the importance of maintaining security-conscious design principles in template engines, particularly when dealing with multiple programming languages and their respective syntax rules, as the interaction between different template systems can create unexpected security implications that require careful consideration and robust mitigation strategies.