initstring/lxd_rootEscalada de privilegios en Linux mediante LXD
Los miembros del grupo local lxd en sistemas Linux tienen numerosas vías para escalar sus privilegios a root. Este repositorio contiene ejemplos de exploits locales totalmente automatizados. Puedes encontrar una explicación detallada de la vulnerabilidad y un recorrido por el exploit en mi blog aquí.
Los exploits que aparecen a continuación no son fugas de contenedores, sino exploits locales de root que aprovechan los contenedores y tienen como objetivo el sistema operativo anfitrión. Para que la explotación tenga éxito, se requiere acceso con privilegios bajos al entorno del host.
Creo que mi estrategia con la versión 2 del exploit es única y fue lo bastante interesante (al menos para mí) como para escribir una explicación detallada en el blog enlazado arriba.
lxd_rootv1.sh monta el sistema de archivos / del host en un contenedor, donde el usuario con privilegios bajos del host tiene acceso root. Este acceso root se asigna de vuelta al host, lo que permite añadir al usuario actual al archivo /etc/sudoers. Otros ya han explotado esto antes que yo.lxd_rootv2.py monta el socket privado de UNIX de systemd del host en un contenedor y luego lo devuelve al host mediante dispositivos proxy de LXD. Estos dispositivos proxy tienen privilegios de root y pasan sus credenciales durante las comunicaciones por socket, a diferencia de las credenciales del usuario con privilegios bajos que inicia la comunicación. Esto se aprovecha para crear un servicio temporal de systemd que añade al usuario actual al archivo /etc/sudoers.Ambos exploits requieren un contenedor, así que crea uno primero. Luego, ejecuta el exploit desde el sistema operativo del host con el nombre del contenedor como primer argumento.
# Explotar con v1
$ bash lxd_rootv1.sh <nombre del contenedor>
# Explotar con v2
$ python3 lxd_rootv2.py <nombre del contenedor>
Antes de que me encontrara con estos problemas, no existía nada en la documentación oficial de LXD que advirtiera a los usuarios de que el grupo lxd era peligroso. Cualquiera que siguiera las pautas oficiales para configurar LXD habría añadido su cuenta a este grupo antes de desplegar su primer contenedor. Abrí un informe de error con Canonical para expresar mis preocupaciones; puedes leer el hilo completo aquí. El equipo de LXD realizó rápidamente ajustes en la documentación, que ahora indica claramente que este grupo solo debe otorgarse a quienes se les confía el acceso root.
Como siempre, interactuar con la gente de Canonical a través de su rastreador de errores fue una experiencia realmente agradable. Me gustaría agradecerles su tiempo y la consideración que dieron a mis ideas. Recomiendo encarecidamente a otros investigadores de seguridad que les presenten los problemas directamente de esta manera.
No soy la primera persona que explota LXD. Esto se ha planteado como una preocupación en varios tickets de GitHub desde 2016:
Ese primer enlace es la primera persona (simpoir) que identificó este riesgo, hasta donde puedo ver.
@reboare escribió un buen blog sobre la explotación de LXD utilizando el mismo método que mi exploit v1, mucho antes que yo:
Gracias a la gente de LXD por crear una herramienta tan interesante. Personalmente uso LXD y me gusta mucho. No creo que esto sea un factor decisivo en contra del uso de LXD; creo que es simplemente muy importante entender el riesgo potencial al añadir usuarios al grupo lxd.
No existe una solución oficial para ninguna de estas vulnerabilidades. Cualquier persona que use LXD debe ser consciente de que añadir usuarios al grupo lxd es, en esencia, convertirlos en root.
Si usas LXD en un host de un solo usuario, como un escritorio, puede ser mejor no usar el grupo lxd en absoluto y ejecutar sudo cuando necesites hablar con la API.
Para entornos compartidos con varias personas trabajando con contenedores, puede ser mejor crear entornos anidados. Cada usuario individual del grupo LXD podrá explotar su propio entorno, pero luego tendrá que trabajar más para salir de ese contenedor y explotar los demás.