NCC-E003660-YVU: Incorrect Handling of Proxy Authentication Headers

[reylejano]

NCC-E003660-YVU: Incorrect Handling of Proxy Authentication Headers

This issue was reported in the Kubernetes 1.24 Security Audit Report

Impact If custom values have been set for the authentication proxy header names, an attacker can assert arbitrary group memberships to extension API servers, leading to privilege escalation opportunities.

Description The proxy authentication scheme supported by the Kubernetes API server adds custom HTTP headers to proxied requests to specify username, groups and extra values. These header names default to X-Remote-User, X-Remote-Group and X-Remote-Extra-xxxx, but can be changed using command line arguments. The implementation of proxy authentication used by the aggregation layer strips these headers out of incoming requests (to avoid the obvious header spoofing attack), but this code does not take account of the fact that the header names are configurable - instead, it assumes the default values. This means that if the header names have been changed, it will be possible for an attacker to add these headers to a request sent to the Kubernetes API server, and when it is proxied onwards (e.g. to an extension API server) they will not be stripped. The extension API server (assuming that it has been configured with the same header names, as would be expected) would then make security decisions based on these spoofed values: if following the guidance in the Kubernetes documentation, it would include the spoofed information in the SubjectAccessReview sent back to the main API server.

It may be the case that a spoofed username header would not be recognized by the destination server, as it is intended that only one of these headers should be present, and the legitimate header added by the aggregation layer may take precedence. However, by design there can be multiple remote group headers so spoofed values would be accepted (and this provides an obvious route for privilege escalation, by adding a group membership like system:masters).

Note that a prerequisite for this attack is to have permission to call the relevant paths on the extension API server - this will be verified by the main API server before the request is proxied onwards. The privilege escalation opportunity arises from spoofing the group memberships which are presented to the extension API server.

Recommendation Modify the SetAuthProxyHeaders method so that it also strips headers with the names configurable using the --requestheader-username-headers, --requestheader-groupheaders and --requestheader-extra-headers-prefix options.

Component kube-apiserver

Location Function SetAuthProxyHeaders() in file round_trippers.go:L124

Anything else we need to know? See umbrella issue #118980 for current status of all issues created from these findings. The vendor gave this issue an ID of NCC-E003660-YVU and it was finding 14 of the report under the kube-apiserver section. The vendor considers this issue Low Risk, Medium Impact, Low Exploitability To view the original finding, begin on page 39 of the Kubernetes 1.24 Security Audit Report

Test Environment Kubernetes 1.24.3

[reylejano]

/sig security

[k8s-ci-robot]

This issue is currently awaiting triage.

If a SIG or subproject determines this is a relevant issue, they will accept it by applying the triage/accepted label and provide further guidance.

The triage/accepted label can be added by org members by writing /triage accepted in a comment.

Instructions for interacting with me using PR comments are available [here](https://git.k8s.io/community/contributors/guide/pull-requests.md). If you have questions or suggestions related to my behavior, please file an issue against the [kubernetes/test-infra](https://github.com/kubernetes/test-infra/issues/new?title=Prow%20issue:) repository.

[carlory]

/assign

[liggitt]

fixed in https://github.com/kubernetes/kubernetes/pull/116785 and latest 1.24+ patch releases