Ningún sistema operativo está libre de tener fallos de seguridad que a veces pueden terminar por comprometerlo gravemente. Ese es el caso de la edición para servidores de Ubuntu 20.04, cuyo instalador, Subiquity, ha estado registrando las contraseñas establecidas para los volúmenes cifrados LUKS.
Profundizando en los detalles, Canonical lleva años intentando distanciarse de la tecnología de Debian. Para ello la compañía dirigida por Mark Shuttleworth ha desarrollado un instalador para la edición Server de Ubuntu llamado Subiquity, el cual ha sustituido al instalador clásico de Debian. Sin embargo, en lo que respecta a Ubuntu 20.04 LTS, se ha publicado recientemente una vulnerabilidad ya resuelta en la que se exponía que Subiquity registraba las contraseñas establecidas para los volúmenes cifrados LUKS.
El fallo de seguridad, que ha sido identificado como CVE-2020-11932, consistía en que Subiquity registraba las contraseñas asignadas a los volúmenes de LUKS a través del registro de la instalación y a su vez las copiaba en el disco donde se instalaba Ubuntu Server, y no necesariamente dentro de uno de los volúmenes cifrados. Como consecuencia, se abría la puerta a poder filtrar con facilidad las contraseñas y neutralizar la protección ofrecida por LUKS, si bien era necesario acceder físicamente a la máquina.
 |
 |
| Establecer una contraseña para los volúmenes LUKS en Ubuntu 20.04 Server | Actualizar el instalador Subiquity en Ubuntu 20.04 Server |
El fallo de seguridad parece haber sido reportado de forma privada a Canonical y expuesto al público tras ser resuelto. Por suerte los usuarios no tendrán que hacer gran cosa, ya que Subiquity es ofrecido en formato Snap, así que tras iniciar la sesión en vivo se da la opción al usuario de actualizar la aplicación, aunque esto obviamente requiere de una conexión a Internet.
Que la contraseña dedicada a proteger los datos de las particiones cifradas del disco acabe expuesta no es algo que haga gracia a nadie, sobre todo porque la protección que se busca obtener queda totalmente invalidada. Afortunadamente Canonical ha reaccionado con suma rapidez, o al menos eso deja entrever la línea del tiempo que se puede trazar viendo el reporte del fallo en Launchpad.
Fuente: muylinux
