PwnKit, o cómo un código de hace 12 años puede dar root a usuarios sin privilegios

Parece que los equipos informáticos no tienen tregua. Después de todos los problemas causados por log4j (y sus variantes), hay una nueva vulnerabilidad de alto perfil y alto riesgo dando vueltas. CVE-2021-4034, o PwnKit si te gustan los apodos extravagantes de CVE, es una vulnerabilidad de polkit que permite a usuarios sin privilegios obtener privilegios de root en básicamente cualquier sistema Linux que tenga polkit instalado.

El equipo de Soporte de Ciclo de Vida Extendido de TuxCare está preparando parches para todas las distribuciones soportadas, y pronto estarán disponibles para su despliegue. Este post se actualizará para reflejar la disponibilidad real para cada distribución a medida que suceda.

[NOTA: Ya hay parches disponibles para Centos6, Oracle6, CL6, Ubuntu16 y Centos8.4. Habrá más próximamente. Puede realizar un seguimiento del soporte real de la distribución a través del panel de CVE aquí: https://cve.tuxcare.com/cve/CVE-2021-4034.]

Esta vulnerabilidad fue identificada porlos investigadores de Qualysy revelada a los proveedores de distribución a finales del año pasado, pero no se hizo pública hasta el 25 de enero de 2022.

Es extremadamente fácil de explotar, y aunque el anuncio inicial mencionaba que era probable que apareciera un exploit en los próximos días, en realidad sólo pasaron unas 3 horas hasta que se descubrió el código del exploit disponible públicamente y se confirmó que funcionaba. Afecta a las principales distribuciones de Linux como Ubuntu, RHEL, CentOS y sus derivados. Dado que el código afectado formaba parte del commit de código inicial de polkit, realizado en 2009, es muy probable que cualquier distribución que ejecute polkit se muestre vulnerable.

¿Qué es polkit (y pkexec)?

Polkit es un paquete que proporciona control de privilegios para gestionar la comunicación entre procesos cuando éstos tienen diferentes niveles de privilegio. A través de pkexec (un componente de polkit), esto permite a un usuario ejecutar comandos con privilegios superiores a los normales. Por ejemplo, dar acceso a un usuario específico para realizar una tarea en todo el sistema sin pasar realmente el acceso root completo a ese usuario.

Una mirada más profunda a la vulnerabilidad

Pkexec acepta argumentos que se le pasan en la línea de comandos y que controlan su comportamiento (qué ejecutar, qué ámbito, etc.). Lo que los investigadores encontraron fue que era posible pasar un parámetro nulo y hacer que el código que valida el parámetro falle de tal manera que la memoria se corrompe con un valor controlado por el atacante escrito en el entorno de ejecución de pkexec. Esto puede extenderse a pkexec ejecutando cualquier comando como root, y esto es trivialmente explotable para proporcionar acceso root completo a un usuario sin privilegios.

El análisis real del código está presente en el anuncio inicial de Qualys, enlazado más arriba.

Mitigación antes de que esté disponible un parche

Es posible mitigar el riesgo eliminando SUID-bit de pkexec con el comando:

Tenga en cuenta que esto interferirá con el funcionamiento normal de pkexec, así que asegúrese de probar a fondo este cambio en un entorno de pruebas antes de la adopción a gran escala en su infraestructura, ya que puede dar lugar a efectos secundarios no deseados. Parchear sigue siendo la mejor opción.

Observaciones finales

Esta vulnerabilidad requiere acceso a un sistema para ser explotada, ya que no tiene un vector de ataque remoto conocido. Aún así, puede ser utilizada por un atacante que obtenga acceso a un sistema para luego escalar sus privilegios. La prevalencia de polkit hace que esta sea una amenaza de seguridad muy seria que debería ser parcheada lo antes posible para evitar sorpresas indeseadas.

Esta vulnerabilidad es un ejemplo más de un problema que viene de lejos en el software de código abierto: que el código sea abierto no significa que la gente adecuada esté mirando. El fallo estaba presente en un código de hace 12 años, y nadie lo detectó en ese periodo de tiempo; al menos, nadie lo anunció públicamente. Los proyectos fundamentales tienden a carecer de recursos (e incentivos) para auditar y asegurar adecuadamente su código, pero en ellos confían desproporcionadamente otros innumerables proyectos y distribuciones. Para ponerlo en perspectiva, un problema de seguridad en un código de hace 12 años ni siquiera es el fallo "más antiguo"encontrado en los últimos meses. A medida que se audite más código, es probable que se encuentren más fallos, lo que aboga por un ritmo más rápido en la aplicación de parches a las nuevas vulnerabilidades que vayan surgiendo.

Los parches para todas las distribuciones cubiertas por el servicio TuxCare Extended Lifecycle Support se están preparando y estarán disponibles en breve. Vuelva a consultar esta página para estar al tanto de las actualizaciones, ya que esta entrada reflejará la disponibilidad de los parches para las distintas distribuciones a medida que estén listos para su despliegue.