A weakness in the Go language that allows some servers to interpret certain malformed HTTP headers as valid has had some trickle-down effects, specifically for Kubernetes users who have an authentication proxy in front of their API server.
The problem is a result of the way that Go handles HTTP headers that have whitespace between the field-name and colon. The whitespace is not allowed in the HTTP/1.1 specification, but in some cases the net/http library in Go will interpret those headers the same way it does valid ones. This can cause serious problems in configurations where there is a reverse proxy sitting in front of a Kubernetes API server.
“This seemingly innocent problem becomes dangerous when a Go server relying on the library is used in combination with a reverse proxy that filters request headers. The proxy may ignore invalid headers, but forward them to the Go server, which would interpret these headers as valid,” Ariel Zelivanky and Aviv Sasson of Palo Alto Networks said in a post analyzing the vulnerability.
“For example, if a reverse proxy server is used for authentication, attackers could exploit this bug to authenticate as any user by crafting an invalid header that would go through to the server. This scenario is not at all hypothetical. The Kubernetes API server can be configured to work with an Authenticating Proxy and identify users through request headers. Such a proxy may be used to allow users to authenticate to the API server using an existing SSO scheme, or other access control configurations.”
Kubernetes has released new builds that fix the vulnerability and there are new versions of Go that patch the bug, as well.
In the attack scenario described by the researchers, an attacker could use this vulnerability to pass an invalid X-Remote-User header through a reverse proxy to a Kubernetes server.
“If the proxy is designed to filter X-Remote-User headers but doesn’t recognize the header because it’s invalid and forwards it to the Kubernetes API server, the attacker would successfully pass the API request with the roles of the ‘admin’ user,” Zelivanky and Sasson said.
“In this case, the proxy is highly naive. It both accepts anonymous connections and forwards invalid headers. The attacker sends a malicious request with an invalid header with including a whitespace. The API server accepts this header and performs the attacker’s requests with Bob’s roles. Of course, the details of an actual exploit would rely on the implementation of the proxy server.”