Canonical corrige un fallo de gravedad máxima en LXD y MicroCloud

Para explotarlo se necesita acceso a la API HTTPS de administración y el certificado público del cliente objetivo. En MicroCloud existe otro escenario: el atacante intercepta el certificado público de un nodo mientras este se une a un clúster y después se hace pasar por él.

El problema fue señalado a Canonical por los desarrolladores de Incus, una bifurcación abierta de LXD. El certificado del propio servidor puede obtenerse en una conexión TLS; añadirlo a la cadena da acceso a la puerta de enlace de la base de datos, y el de otro nodo concede acceso interno al clúster. Incus lo corrigió en la versión 7.6.0, y las anteriores se consideran vulnerables. Según CodeScoring, el error existía en Incus desde la primera versión, y el mismo rodeo permitía renovar o eliminar entradas ajenas del almacén de certificados.

Qué deben hacer los administradores

Por defecto, LXD funciona mediante un socket Unix local y no acepta conexiones de red. El acceso por red se activa con el parámetro core.https_address, de modo que lo primero es comprobar si la interfaz de administración es accesible desde una red no confiable.

Las compilaciones snap corregidas son del 29 de octubre: 6.10.1, 5.21.9, 5.0.11 y 4.0.15 para LXD, y 3.4.1 y 2.1.5 para MicroCloud. Canonical recomienda ejecutar sudo snap refresh lxd y sudo snap refresh microcloud. Como el despliegue es escalonado, conviene comparar la versión obtenida con la lista de su canal.

Hasta aplicar el parche, el acceso a la API debe limitarse a hosts de confianza. Los desarrolladores de Incus advierten de que no hay ningún ajuste que elimine el fallo sin actualizar. LXD, MicroCloud e Incus también deben figurar en el inventario de software de infraestructura de los hosts con contenedores y máquinas virtuales.