Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

CVE-2020-8559: Privilege escalation from compromised node to cluster #1732

Closed
palma21 opened this issue Jul 17, 2020 · 6 comments
Closed

CVE-2020-8559: Privilege escalation from compromised node to cluster #1732

palma21 opened this issue Jul 17, 2020 · 6 comments

Comments

@palma21
Copy link
Member

palma21 commented Jul 17, 2020

From kubernetes/kubernetes#92914:

If an attacker is able to intercept certain requests to the Kubelet, they can send a redirect response that may be followed by a client using the credentials from the original request. This can lead to compromise of other nodes.

If multiple clusters share the same certificate authority trusted by the client, and the same authentication credentials, this vulnerability may allow an attacker to redirect the client to another cluster. In this configuration, this vulnerability should be considered High severity.

Am I vulnerable?

You are only affected by this vulnerability if you treat the node as a security boundary, since clusters in AKS do not share certificate authorities and authentication credentials.

Note that this vulnerability requires an attacker to first compromise a node through separate means.

Affected ** Upstream ** Versions

  • kube-apiserver v1.18.0-1.18.5
  • kube-apiserver v1.17.0-1.17.8
  • kube-apiserver v1.16.0-1.16.12
  • all kube-apiserver versions prior to v1.16.0

Affected ** AKS ** Versions

AKS patches all GA kubernetes versions control plane components automatically.

  • kube-apiserver <v1.18.6
  • kube-apiserver <v1.17.7
  • kube-apiserver <v1.16.10
  • and all kube-apiserver versions prior to v1.15.11

How do I mitigate this vulnerability?

AKS will patch the control planes of its GA versions automatically. If you're on an AKS GA version no action is required.
If you're not in an AKS GA version please upgrade following:
https://docs.microsoft.com/en-us/azure/aks/upgrade-cluster

Fixed ** AKS ** Versions

  • kube-apiserver v1.18.6+
  • kube-apiserver v1.17.7+
  • kube-apiserver v1.16.10+

If you're not in an AKS GA version please upgrade following: https://docs.microsoft.com/en-us/azure/aks/upgrade-cluster

@msftbot
Copy link
Contributor

msftbot bot commented Aug 28, 2020

Action required from @Azure/aks-pm

@msftbot msftbot bot added the Needs Attention 👋 Issues needs attention/assignee/owner label Aug 28, 2020
@palma21 palma21 added announcement and removed Needs Attention 👋 Issues needs attention/assignee/owner action-required labels Aug 28, 2020
@tsubasaxZZZ
Copy link

I have two question. Could you tell me my concern?

Q1. Why AKS isn't affected v1.17.7?

My understand that affected versions is NOT included 1.17.7 in AKS.

Affected ** AKS ** Versions
kube-apiserver <v1.17.7

But upstream issue is explained that v1.17.7 is affected.
kubernetes/kubernetes#92914
image

Why AKS isn't affected v1.17.7?

Q2. How do I know that my cluster has been upgraded?

If upgrade automatically, Can I check do upgrade?
And if my cluster version is v1.17.6, which version is upgraded to v1.17.7 or v1.17.9 automatically?

@palma21
Copy link
Member Author

palma21 commented Sep 2, 2020

Q1:
At the time when this was published 1.17.7 was available in AKS (today it no longer is).
The reason why AKS v1.17.7 was not affected is that as a GA version AKS automatically patched the API server to include the fixes.

Q2:
There's nothing for you to check in this case as all fixes are done in the control plane side.
1.17.6 is vulnerable as it's not a GA version at the time so it was not patched. An upgrade to any GA version would make it support it and have that patch.

@tsubasaxZZZ
Copy link

Thank you @palma21.
I have additional question about your reply.

Q3:
My understanding is that AKS is applying its own patches to its version of Upstream. This means that even though it is the same v1.17.7, it is based on a different source code.
Is it correct?

Q4:
On that premise, since Upstream had already released a patch for this vulnerability at the time AKS v1.17.7 was released, AKS has incorporated that fix into v1.17.7. So Upstream v1.17.7 has this vulnerability, but AKS v1.17.7 doesn't have this vulnerability.
Is this understanding correct?

@palma21
Copy link
Member Author

palma21 commented Sep 2, 2020

Q3: It's cherry picking the upstream commit or using the fixed patch version depending on the situation. It's the same source code.
Q4: Yes

@tsubasaxZZZ
Copy link

Thank you for your quick reply. I understand very well.

@palma21 palma21 closed this as completed Sep 11, 2020
@msftbot msftbot bot locked as resolved and limited conversation to collaborators Oct 11, 2020
@qpetraroia qpetraroia unpinned this issue Nov 5, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

3 participants