CVE-2022-3162: Unauthorized read of Custom Resources

[tallclair]

CVSS Rating: CVSS:3.0/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N

A security issue was discovered in Kubernetes where users authorized to list or watch one type of namespaced custom resource cluster-wide can read custom resources of a different type in the same API group without authorization.

Am I vulnerable?

Clusters are impacted by this vulnerability if all of the following are true:

• There are 2+ CustomResourceDefinitions sharing the same API group
• Users have cluster-wide list or watch authorization on one of those custom resources.
• The same users are not authorized to read another custom resource in the same API group.

Affected Versions

• Kubernetes kube-apiserver <= v1.25.3
• Kubernetes kube-apiserver <= v1.24.7
• Kubernetes kube-apiserver <= v1.23.13
• Kubernetes kube-apiserver <= v1.22.15

How do I mitigate this vulnerability?

Upgrading the kube-apiserver to a fixed version mitigates this vulnerability.

Prior to upgrading, this vulnerability can be mitigated by avoiding granting cluster-wide list and watch permissions.

Fixed Versions

• Kubernetes kube-apiserver v1.25.4
• Kubernetes kube-apiserver v1.24.8
• Kubernetes kube-apiserver v1.23.14
• Kubernetes kube-apiserver v1.22.16

Detection

Requests containing .. in the request path are a likely indicator of exploitation. Request paths may be captured in API audit logs, or in kube-apiserver HTTP logs.

If you find evidence that this vulnerability has been exploited, please contact security@kubernetes.io

Acknowledgements

This vulnerability was reported by Richard Turnbull of NCC Group as part of the Kubernetes Audit.

/area security
/kind bug
/committee security-response
/label official-cve-feed
/sig api-machinery
/area apiserver

[tallclair]

Fix PRs:

• master: Fix etcd path construction #113696
• v1.25: Fix etcd path construction #113684
• v1.24: Fix etcd path construction #113685
• v1.23: Fix etcd path construction #113686
• v1.22: Fix etcd path construction #113687

[NissesSenap]

Do I understand it correctly that it's only get/list that can be done?
No create, update, delete operation is possible with the CVE?

[tallclair]

@NissesSenap correct, as far as we can tell, the exploit is read-only. However, I think it only works for list & watch requests, not get.

[HeYuqiu]

Does this CVE exist in version 1.20.x ?

[pparshin]

Hi,

What steps are to reproduce this CVE?

I have two namespaced CRDs a and b in the same API group cluster.x-k8s.io. There is a ClusterRole to access only resource a.

My user sends a request to list objects b and I get access error as expected:

> kubectl --insecure-skip-tls-verify get --raw /apis/cluster.x-k8s.io/v1beta1/a/../b?limit=500

Error from server (Forbidden): a.cluster.x-k8s.io ".." is forbidden: User "cve-2022-3162" cannot get resource "a/b" in API group "cluster.x-k8s.io" at the cluster scope

[mrintern]

@pparshin I am also having trouble trying to reproduce this bug. Did you ever figure it out?

[pparshin]

@mrintern not yet, unfortunately. I've tried a lot of request variations but without success

[yy158775]

My user has permissions to both two types,but I still can't successfully list the crd objects using '..' .

kubectl get --raw /apis/sample.k8s.io/v1alpha1/namespaces/default/goos/../foos

Error from server (NotFound): goos.samplecontroller.k8s.io ".." not found

I guess this bug can't be exploited beacuse the url parameters is parsed correctly and the '../' or '/..' can't be included in the 'key'.

kubernetes/staging/src/k8s.io/apiserver/pkg/storage/etcd3/store.go

Lines 568 to 572 in 7061704

	func (s *store) GetList(ctx context.Context, key string, opts storage.ListOptions, listObj runtime.Object) error {
	preparedKey, err := s.prepareKey(key)
	if err != nil {
	return err
	}

prepareKey method is used to address the problem.

kubernetes/staging/src/k8s.io/apiserver/pkg/storage/etcd3/store.go

Lines 964 to 986 in 7061704

	func (s *store) prepareKey(key string) (string, error) {
	if key == ".." ||
	strings.HasPrefix(key, "../") ||
	strings.HasSuffix(key, "/..") ||
	strings.Contains(key, "/../") {
	return "", fmt.Errorf("invalid key: %q", key)
	}
	if key == "." ||
	strings.HasPrefix(key, "./") ||
	strings.HasSuffix(key, "/.") ||
	strings.Contains(key, "/./") {
	return "", fmt.Errorf("invalid key: %q", key)
	}
	if key == "" || key == "/" {
	return "", fmt.Errorf("empty key: %q", key)
	}
	// We ensured that pathPrefix ends in '/' in construction, so skip any leading '/' in the key now.
	startIndex := 0
	if key[0] == '/' {
	startIndex = 1
	}
	return s.pathPrefix + key[startIndex:], nil
	}

@tallclair @mrintern @pparshin

[yy158775]

In the following parts,we can find the URL parts after subresource aren't interpreted.So we use '/../' in the URL it won't work.

kubernetes/staging/src/k8s.io/apiserver/pkg/endpoints/request/requestinfo.go

Lines 197 to 207 in 7061704

	// parts look like: resource/resourceName/subresource/other/stuff/we/don't/interpret
	switch {
	case len(requestInfo.Parts) >= 3 && !specialVerbsNoSubresources.Has(requestInfo.Verb):
	requestInfo.Subresource = requestInfo.Parts[2]
	fallthrough
	case len(requestInfo.Parts) >= 2:
	requestInfo.Name = requestInfo.Parts[1]
	fallthrough
	case len(requestInfo.Parts) >= 1:
	requestInfo.Resource = requestInfo.Parts[0]
	}

kubernetes/staging/src/k8s.io/apimachinery/pkg/api/validation/path/name.go

Line 25 in 7061704

var NameMayNotBe = []string{".", ".."}

[singvey999]

Dear All,
Does this CVE exist in version 1.17.11? Thanks.

[singvey999]

Dear All,
How to reproduce this issue and how to verify this issue with the detailed steps?
Thanks.

[mrintern]

@yy158775 I think your confused, the code you are referencing is from after this bug was patched in this commit: f1693a0

in this commit, prepareKey() was added. Yet, everyone seems to be having difficulty exploiting the bug in the vulnerable versions anyways, so who knows.

[yy158775]

I referenced the code in the commit f1693a0 to verify that the prepareKey() is used to address the problem of '/../' in the path.
But according to other parts of Kubernetes,the path parts can't contain '/../'. So I think this bug can't be exploited and this commit maybe useless.Even if the prepareKey() method isn't used,the bug can't be exploited.
@mrintern

[mrintern]

Thanks for the clarification

On Wed, Nov 30, 2022 at 1:54 PM yangyong ***@***.***> wrote: I referenced the code in the commit f1693a0 <f1693a0> to verify that the prepareKey() is used to address the problem of '/../' in the path. But according to other parts of Kubernetes,the path parts can't contain '/../'. So I think this bug can't be exploited and this commit maybe useless.Even if the prepareKey() method isn't used,the bug can't be exploited. @mrintern <https://github.com/mrintern> — Reply to this email directly, view it on GitHub <#113756 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AF2TYNG2MPAQ64JAA6WNLV3WK5MATANCNFSM6AAAAAAR2YTM3E> . You are receiving this because you were mentioned.Message ID: ***@***.***>

-- Nick

[tallclair]

@HeYuqiu @singvey999 Yes, all versions of Kubernetes prior to the patched versions are affected, meaning all versions <= v1.21

[tallclair]

@yy158775 This is a real issue. We were able to reproduce it before the patch, and confirmed that all known exploits are mitigated by this patch. The Security Response Committee does not usually provide full reproduction steps for vulnerabilities, but I'll follow up with the committee to see whether we want to provide more details in this case.

[singvey999]

@tallclair Thanks for your help. Could you please share the detailed steps to reproduce this issue ? As we only have the jump server to connect to k8s cluster with tls certs and that is the admin user account which has the cluster admin role . By the way, will this issue point to the k8s service account also , or only to the k8s user accounts with tls cert ?