search

Azure / aksArc

# Welcome to the Azure Kubernetes Service enabled by Azure Arc (AKS Arc) repo This is where the AKS Arc team will track features and issues with AKS Arc. We will monitor this repo in order to engage with our community and discuss questions, customer scenarios, or feature requests. Checkout our projects tab to see the roadmap for AKS Arc!
MIT License
112 stars 45 forks source link

CVE-2021-25741: Symlink Exchange Can Allow Host Filesystem Access #129

Open scooley opened 3 years ago

scooley commented 3 years ago

A security issue was discovered in Kubernetes where a user may be able to create a container with subpath volume mounts to access files & directories outside of the volume, including on the host filesystem. This issue has been rated High (CVSS:3.0/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H), and assigned CVE-2021-25741.

Affected Components and Configurations

This bug affects kubelet.

Environments where cluster administrators have restricted the ability to create hostPath mounts are the most seriously affected. Exploitation allows hostPath-like access without use of the hostPath feature, thus bypassing the restriction.

In a default Kubernetes environment, exploitation could be used to obscure misuse of already-granted privileges.

Affected Versions

• v1.22.0 - v1.22.1 • v1.21.0 - v1.21.4 • v1.20.0 - v1.20.10 • <= v1.19.14

Fixed Versions

This issue is fixed in the following versions: • v1.22.2 • v1.21.5 • v1.20.11 • v1.19.15

Mitigation

To mitigate this vulnerability without upgrading kubelet, you can disable the VolumeSubpath feature gate on kubelet and kube-apiserver, and remove any existing Pods making use of the feature.

You can also use admission control to prevent less-trusted users from running containers as root to reduce the impact of successful exploitation.

Detection

If you find evidence that this vulnerability has been exploited, please contact security@kubernetes.io For additional details, see Kubernetes Issue #104980.

AKS-HCI Information:

Please upgrade to the August AKS-HCI release – it contains the patched kubelet version needed to fix this vulnerability.

<3 AKS-HCI team

shapeofarchitect commented 3 years ago

@scooley This is a bit confusing , azure documents doesn't show us the upgrade path but each of our nodepools shows the update image (VM OS). My question would be for "fix versions" you showed there. These are not the one azure is looking to upgrade to for control plane.

How do we establish the upgrade to exact these versions and we get rid of vulnerability ?

framigni commented 3 years ago

@scooley There seems to be a problem here: our AKS cluster is on 1.21.2, there seems to be no upgrade available for 1.21.5 and the next available is 1.22. 1, which is still in preview Is it possible to upgrade to 1.21.5 and how ?

cdhunt commented 3 years ago

If you run the upgrade command with the --node-image-only flag it will upgrade to the latest image. This is independent of the cluster version. Basically it just redeploys all of the nodes and they boot up with the latest image.

shapeofarchitect commented 3 years ago

That’s what i did and learned that only solution to this is to delete the existing nodes and new one will come up with the upgraded image . So in its current state version thing is misguided . I think it’s mostly to deal with the upgrade workflow where you just slide the change to image and wrap it around the upgrade idea and sell it to customer but ideally it’s not an upgrade of kube version at all. So this Issue and content doesn’t really depict that .

framigni commented 3 years ago

Ok, I see. So if I refer to https://github.com/Azure/AKS/releases I don't see there any reference to CVE-2021-25741. So that's totally unrelated and it'd be nice to know the Ubuntu release that fixes that vulnerability. As said by shapeofarchitec, this issue is misleading and I spent 2 hours of my life to work this out.