Descubierta vulnerabilidad que afecta al cifrado de sistemas Linux

lubuntu-luks

Se ha descubierto una vulnerabilidad en Cryptsetup, una utilidad usada en sistemas Linux para el cifrado de disco, siguiendo el estandar LUKS (Linux Unified Key Setup).

Es un fallo que no afecta a la integridad de las particiones encriptadas o el protocolo utilizado, sino al script de Cryptsetup utilizado para descifrarlas y por tanto desbloquear su acceso.

Lo llamativo de esta vulnerabilidad clasificada como CVE-2016-4484 es lo sencillo que sería su explotación: bastaría presionar durante unos 70 segundos la tecla intro para obtener una shell con privilegios de root (hace uso de initframfs o dracut, que se activan de forma temporal como sistema de archivos RAM al inicio).

Como resultado nos da acceso a las particiones del sistema, entre ellas la partición /boot que es la que se encarga del arranque del sistema y que generalmente no se suele cifrar.

Lo de los 70 segundos no es algo casual, está relacionado con un fallo en cryptsetup a la hora de manejar el número máximo de intentos permitidos para adivinar la contraseña que monta las particiones. El año pasado un problema similar que afectaba a Grub2 fue descubierto por los mismos desarrolladores (Hector Marco e Ismael Ripoll), aunque en aquella ocasión la tecla mágica era la de retroceso.

Como resultado de esto tenemos acceso a todos los discos del sistema, pudiendo borrar su contenido ,introducir código en aquellas partes que no están cifradas (propiciando una escalada de privilegios), o bien copiar a un dispositivo externo las que si lo estén, para su posterior análisis e intento de acceso mediante técnicas de fuerza bruta.

Esta vulnerabilidad podrá ser especialmente seria en dispositivos de acceso público como: cajeros automáticos, bibliotecas, laboratorios, máquinas presentes en aeropuertos, etc. Aunque en un principio parece necesario el acceso físico a la máquina, según comentan sus descubridores también sería posible su explotación de forma remota en ambientes cloud.

El fallo se ha comprobado que existe en sistemas Debian y derivados como Ubuntu, así como en las últimas versiones de Fedora.

En mi caso he intentado reproducir el fallo un par de veces en un equipo con Manjaro y cifrado LUKS, con resultados negativos, posiblemente tenga algo que ver que utilizo una versión reciente de Cryptseupt ( 1.7.3.1) liberada hace unos días.

A la espera de que Cryptsetup se actualice en las diferentes distribuciones GNU/Linux para solucionar este problema, ya se ha propuesto una solución provisional para aquellos que no quieran esperar, que implica editar el sistema de arranque.

Tenéis más información sobre esa solución y una descripción completa de la vulnerabilidad en esta página.

13 thoughts on “Descubierta vulnerabilidad que afecta al cifrado de sistemas Linux”

  1. Solrak Rainbowarrior says:

    Los que hemos cifrado un disco hace más de un año con LUKS, aunque se actualice el paquete, somos vulnerables?

    1. Aereon says:

      Cuando a tualicez el paquete deberias estar ok

      1. Solrak Rainbowarrior says:

        Gracias, por las respuesta!
        Aunque aunque si el cifrado ya está hecho, ¿qué es lo que cambia?

        1. Tesla says:

          Hola, como bien dice nuestro amigo el replicante:

          “Es un fallo que no afecta a la integridad de las particiones encriptadas o el protocolo utilizado, sino al script de Cryptsetup utilizado para descifrarlas y por tanto desbloquear su acceso.”

          Por tanto, deduzco que si actualizas el paquete en cuestión. El proceso de descifrado de tus particiones volvería a ser seguro.

          Que alguien me corrija si me equivoco.
          Un saludo!

        2. Tesla says:

          Disculpa, el último párrafo debería ser:

          “Por tanto, deduzco que, si actualizas el paquete en cuestión., el proceso de descifrado de tus particiones volvería a ser seguro.”

          1. Solrak Rainbowarrior says:

            Pues desencriptarlo no debería ponerlo en peligro, creo que es un error de diseño o de concepto.

          2. tannhausser says:

            Esto no afecta al proceso de cifrado, ni es un bug que permita descifrar una partición con LUKS, se trata más bien de ganar algunos privilegios a costa de una configuración errónea de cryptsetup.

            Al principio pensaba que el motivo era un error en la configuración por parte de la gente de Debian mas que de cryptsetup en si, pero que también se de en Fedora me hace dudar un poco.

            También he leído en el foro de Arch –y no se que fiabilidad darle–, de un usuario que quiso reproducir la vulnerabilidad y después era incapaz de arrancar el sistema.

            https://bbs.archlinux.org/viewtopic.php?id=219599

            En mi caso con Manjaro no tuve problemas, pero lo más recomendable es esperar la actualización correspondiente.

          3. Solrak Rainbowarrior says:

            Gracias por la aclaración Replicante!

  2. Jámin Fernandez (@JaminSamuel) says:

    “entre ellas la partición /boot que es la que se encarga del arranque del sistema y que generalmente no se suele cifrar.”

    Generalmente no, nunca se cifra el /boot

  3. Anónimo says:

    Me «alegro» que afecte a Fedora también. A ver si así los talibanes de ésta dejan de ser tan talibanes con el resto de distribuciones. Que parece que Fedora sea la perfección en todo.

    1. carlosky77 says:

      Existen otros talibanes y usan Debian. No discuto su estabilidad pero en seguridad deja mucho que desear. Creen porque es estable es también seguro. Últimamente han salido muchas vulnerabilidades y han sido solucionadas en versiones posteriores del kernel pero debian estable mantiene estas vulnerabilidades porque no dan soporte a otras versiones del kernel. Por algo Kali Linux (distro especialista en herramientas de seguridad y forenses) prefiere basarse en Debian testing.

      1. Tesla says:

        Pues creo que te equivocas completamente en tu comentario.

        El ejemplo más reciente de una vulnerabilidad en el Kernel, el llamado dirtyCow (CVE-2016-5195) del que se habló en este mismo blog [1], fue parcheada en Debian al día siguiente a su publicación [2] y publicada en el repositorio de Debian Security [3] bajo el nombre de 3.16.36-1+deb8u2.

        Por otra parte, el equipo de Debian sí que da soporte a otras versiones del Kernel. En el mismo enlace anterior [3], en el panel de “Versions”, puedes ver como el repositorio “Jessie Backports” dispone de la versión del kernel 4.7.8 anotado en ese panel como: stable-bpo: 4.7.8-1~bpo8+1.

        De lo que podemos concluir que tu comentario no es cierto, ya que:

        – Debian si que libera mejoras de seguridad para sus paquetes.
        – Debian si que soporta versiones mas nuevas del kernel.

        Hay que tener mas cuidado con lo que se dice, ya que la gente que no conoce Debian puede leer eso y hacerse una idea equivocada de la distribución.

        Un saludo!

        Enlaces:

        [1]: http://lamiradadelreplicante.com/2016/10/21/dirty-cow-vulnerabilidad-en-linux-que-permite-escalada-de-privilegios/

        [2]: https://www.debian.org/security/2016/dsa-3696

        [3]: https://tracker.debian.org/pkg/linux

        1. carlosky77 says:

          Mira este artículo:

          https://lamiradadelreplicante.com/2016/02/03/linux-tiene-un-problema-con-la-seguridad-de-webkit/

          en el siguiente párrafo:

          “Las distribuciones GNU/Linux tienen un problema con la seguridad de WebKit, debido principalmente a la negligente política de actualizaciones que siguen la mayoría de distros respecto de este software, tal como nos comenta Michael Catanzaro, desarrollador de GNOME y Webkit en su blog”

          y este:

          “En Debian directamente se desentienden del asunto y aconsejan el uso de navegadores como Iceweasel o Chromium, en vez de aquellos construidos sobre motores web webkit, qtwebkit and khtml, especialmente si se visitan páginas que no son de confianza.”

          Y eso porque??? Por que cambiar de QtWebKit en lugar de QTWebEngine significa modificar muchos paquetes. Esa es la política de seguridad en debian.

Deja un comentario