Una nueva vulnerabilidad en el tiempo de ejecución del contenedor CRI-O utilizado por muchas instalaciones de Kubernetes permite que un usuario malintencionado obtenga acceso de root al host. La vulnerabilidad fue descubierta por investigadores de CrowdStrike y reparada poco después por el proyecto CRI-O.
Esta vulnerabilidad fue descubierta e informada por investigadores de CrowdStrike, quienes la divulgaron a CRI-O. El proyecto CRI-O corrigió la vulnerabilidad en un parche . Apodado “cr8escape”, el error tiene una puntuación de 8,8 en el Sistema de Puntuación de Vulnerabilidad Común (CVSS).
Según el informe de CVE :
Este problema permite que cualquier persona con derechos implemente un pod en un clúster de Kubernetes que usa el tiempo de ejecución de CRI-O para lograr un escape de contenedor y la ejecución de código arbitrario como root en el nodo del clúster, donde se implementó el pod malicioso.
CRI-O es una implementación de contenedor de código abierto de la interfaz de tiempo de ejecución de contenedor (CRI) de Kubernetes. Fue aceptado en la incubadora CNCF en 2019 y se utiliza como alternativa a Docker en algunas instalaciones de Kubernetes. Los proveedores de Kubernetes administrados que usan CRI-O como tiempo de ejecución incluyen OpenShift de Red Hat y Cloud Native Environment de Oracle. Los servicios administrados más conocidos, como AWS EKS, GKE y Azure AKS, usan Dockershim o containerd .
Los contenedores pueden establecer parámetros del kernel que tienen espacios de nombres y, por lo tanto, pueden afectar solo a ese contenedor sin afectar a otros contenedores que se ejecutan en el mismo host. Esto es cierto ya sea que el contenedor se ejecute dentro de Kubernetes o en un tiempo de ejecución de contenedor independiente. “Kubernetes y los tiempos de ejecución de contenedores que maneja permiten que los pods actualicen estas configuraciones de kernel ‘seguras’ mientras bloquean el acceso a otros”, explican los investigadores de CrowdStrike en su artículo.
La versión 1.19 de CRI-O introdujo una vulnerabilidad que permite a un usuario malintencionado eludir estas medidas de seguridad y establecer parámetros de kernel arbitrarios en la máquina host. El parámetro “kernel.core_pattern” podría usarse para ejecutar comandos como root en el host. Debajo del capó, el proyecto CRI-O usa la utilidad “pinns” para configurar las opciones del kernel para un pod. Esto se hizo sin ninguna validación, lo que condujo a la ejecución de código arbitrario en el host.
Cabe señalar que un usuario debe tener derechos de implementación de pods en el tiempo de ejecución o en el clúster de Kubernetes para aprovechar esto. Christophe Tafani-Dereeper , investigador de seguridad de DataDog, señala que los clústeres de Kubernetes que no tienen habilitadas medidas de seguridad como Admisión de seguridad de pod o Políticas de seguridad de pod están en el mismo nivel de riesgo independientemente de esta vulnerabilidad. Sin embargo, las políticas de seguridad de pod están obsoletas desde Kubernetes 1.21.
Otra vulnerabilidad en la herramienta Runc CLI que apareció en 2019 permitió el acceso de raíz al host subyacente a contenedores maliciosos. Kubernetes, la plataforma y las herramientas relacionadas, han tenido algunas vulnerabilidades informadas y corregidas en los últimos años, y ha habido un enfoque cada vez mayor en las guías de refuerzo .