One Article Review
| Source |  GoogleSec |
|---|---|
| Identifiant | 4593798 |
| Date de publication | 2021-12-02 15:00:00 (vue: 2022-05-13 21:47:30) |
| Titre | Exploring Container Security: A Storage Vulnerability Deep Dive |
| Texte | Posted by Fabricio Voznika and Mauricio Poppe, Google Cloud Kubernetes Security is constantly evolving - keeping pace with enhanced functionality, usability and flexibility while also balancing the security needs of a wide and diverse set of use-cases.Recently, the GKE Security team discovered a high severity vulnerability that allowed workloads to have access to parts of the host filesystem outside the mounted volumes boundaries. Although the vulnerability was patched back in September we thought it would be beneficial to write up a more in-depth analysis of the issue to share with the community.We assessed the impact of the vulnerability as described in vulnerability management in open-source Kubernetes and worked closely with the GKE Storage team and the Kubernetes Security Response Committee to find a fix. In this post we'll give some background on how the subpath storage system works, an overview of the vulnerability, the steps to find the root cause and the fix, and finally some recommendations for GKE and Anthos users.Kubernetes Filesystems: Intro to Volume SubpathThe vulnerability, CVE-2021-25741, was caused by a race condition during the creation of a subpath bind mount inside a container, and allowed an attacker to gain unauthorized access to the underlying node filesystem and its sensitive files. We'll describe how that system is supposed to work, and then talk about the vulnerability.The volume subpath feature in Kubernetes enables sharing a volume in multiple containers inside a pod. For example, we could create a Pod with an InitContainer that creates directories with pre-populated data in a mounted filesystem volume. These directories can then be used by containers in the same Pod by mounting the same volume and optionally specifying a subpath field to limit what's visible inside the container.While there are some great use cases for this feature, it's an area that has had vulnerabilities discovered in the past. The kubelet must be extra cautious when handling user-owned subpaths because it operates with privileges in the host. One vulnerability that has been previously discovered involved the creation of a malicious workload where an InitContainer would create a symlink pointing to any location in the host. For example, the InitContainer could mount a volume in /mnt and create a symlink /mnt/attack inside the container pointing to /etc. Later in the Pod lifecycle, another container would attempt to mount the same volume with subpath attack. While preparing the volumes for the container, the kubelet would end up following the symlink to the host's /etc instead of the container's /etc, unknowingly exposing the host filesystem to the container. A previous fix made sure that the subpath mount location is resolved and validated to point to a location inside the base volume and that it's not changeable by the user in between the time the path was validated and when the container runtime bind mounts it. This race condition is known as time of check to time of use (TOCTOU) where the subject being validated changes after it has been validated.These validations and others are summarized in the following container lifecycle sequence diagram. |
| Envoyé | Oui |
| Condensat | /etc /fd /mnt /mnt/attack /proc/ 2021 25741 25741the about above access across action after all allowed already also although analysis another anthos any are area assessed attack attacker attempt auto available back background balancing base because been before being beneficial between bind boundaries bounty bug bulletin bulletins can canonicalize cases cause caused cautious changeable changes channels check closely cloud kubernetes clusters command committee community condition constantly container containers continues could cover create creates creation customers cve data deep default depth dereference dereferencing describe described detailed diagram diagram:the difference directories directory discovered dive diverse doesn done during efforts enabled enables encourage end engine enhanced ensure ensuring every evolving example exchange expanded expectation explained exploring exposing extra fabricio feature field file files filesystem filesystems: finally find finding fix fixed flag flexibility follow following forwardgoogle found functionality gain give gives gke google great guidance had handling has have heavily high host how however immediately impact initcontainer inonce inside instead interested intro invest involved issue issues its just keeping known kubelet kubernetes later latest lifecycle limit link links linux location loop made magic making malicious manage management manually mauricio may mind more mount mounted mounting mounts moving multiple must needs new node nodes not once one open opened operates operations option optionally others out outcomethe outside overview owned pace part participate parts pass past patched patches path peace performing pid please pod point pointing poppe populated post posted pre preparing previous previously privileges problem procfs program provided quickly race recently recommend recommendations region release released releases remains remediate rename renameat resolved response revise rewards right root running runtime safely same security security: see sensitive september sequence set several severity share sharing similar solution some source specifying startupa static steps storage strongly subject subpath subpaths subpaththe subsequent summarized supposed sure swapped symlink system takes talk team teams then there these thought tight time timing toctou unauthorized unchanged under underlying understood undone unknowingly upgrade upgrades usability use used user users uses using utility utilize validated validation validations versions visible visualized volume volumes voznika vrp vulnerabilities vulnerability vulnerability: well what when where which who wide will work worked workload workloads works would write your |
| Tags | Vulnerability |
| Stories | Uber |
| Notes | |
| Move | 
|
L'article ne semble pas avoir été repris aprés sa publication.
L'article ne semble pas avoir été repris sur un précédent.