
Informe de CVE-2017-1002101 con ejemplo de "exploit"/escape
Después de conocer el problema y seguir esta guía, quise explorar un poco más. Este repositorio contiene un par de despliegues de pods y scripts auxiliares de shell que demuestran el mecanismo de ataque de la manera más simple posible, para que los administradores y operadores de Kubernetes puedan comprender completamente la gravedad y los riesgos potenciales. Debes ser un usuario autenticado o capaz de controlar el spec/template de un pod en su creación, por lo que este escape no será anónimo a menos que se combine con otros ataques como este.
Cuando el Kubelet monta un volume/secret/configmap, etc., sigue incorrectamente los enlaces simbólicos dentro del volumen hacia ubicaciones fuera del ámbito donde debería. Debido a que el Kubelet se ejecuta como root, esto significa que puede ser engañado para montar partes privilegiadas del sistema de archivos del host dentro del contenedor de un pod no privilegiado.
Mi enfoque fue usar un solo pod con dos contenedores "normales". Un contenedor crea el enlace simbólico a / o y el otro crashloops hasta que eso tenga éxito (forzando a que el volumen se remonte y siga esa ruta de enlace simbólico), permitiendo al usuario ejecutar exec en el segundo contenedor y acceder al punto de montaje.
/home/ubuntuNota: Estos ejemplos funcionan sin modificación contra un host Ubuntu 16.04, pero pueden ajustarse fácilmente para otras configuraciones.
./run-as-root.sh si tu clúster es bastante "estándar"../run-as-root-no-chroot.sh o ./run-as-user-1000.sh para otras variaciones.Es realmente una situación de "parche obligatorio". Desafortunadamente, las soluciones alternativas enumeradas aquí no son muy prácticas para la mayoría de las personas. Casi todas las versiones anteriores son vulnerables.