Calificación:
  • 0 voto(s) - 0 Media
  • 1
  • 2
  • 3
  • 4
  • 5
ArchLinux vulnerabilidad con OpenSSL
#1
ArchLinux vulnerabilidad con OpenSSL

  •  las últimas novedades llegan de los proyectos de Software Libre casi directamente a la distro en cuanto son publicadas –cosa que siempre atrae a los usuarios de sistemas de escritorio–,
  •  simplifica en buena medida el mantenimiento de los paquetes porque la distribución de los mismos se transforma sencillamente en un “traslado” de upstream a los repositorios sin que haga falta mantener código específico a la distribución y,
  •  por tanto, permite eliminar buena parte de las pruebas de la distribución, bajo la suposición razonable de que cada proyecto prueba sus versiones estables.


Pues bien, la última vulnerabilidad, bastante grave, de OpenSSL ha dejado el modelo de lanzamiento continuo de archlinux y, de paso, a todas sus derivadas, absolutamente fuera de juego en la gestión de la actualización. 



Vamos a hacer la crónica de los hechos. El martes 1º de marzo se descubrió una vulnerabilidad en OpenSSL que se conoce como HTTP DROWN El ataque es relativamente complejo, porque se aprovecha de una vulnerabilidad en el prehistórico protocolo SSLv2 para conseguir los datos de la clave maestra utilizada por la conexión segura y descifrar así el tráfico TLS (el protocolo utilizado en HTTPS actualmente) hacia o desde un servidor debido a que todo el mundo utilizamos el mismo certificado público tanto para TLS y SSL. Lo increíble de esta vulnerabilidad es que ni siquiera exige que SSLv2 esté activo en el servidor como protocolo disponible para ser utilizado en HTTPS, sino simplemente que el servidor tenga OpenSSL configurado para permitir el uso de la API de SSLv2, lo cual, dicho sea de paso, es la configuración predeterminada. Por tanto, la solución implica desactivar el acceso a las funciones de SSLv2, pero aún hoy hay ciertos servicios que insisten en usarlo por mucho que el protocolo SSLv2 fuera declarado obsoleto en 2011 (es más, ¡SSLv3 fue declarado obsoleto en 2015!); dichos servicios no tendrán más remedio que ser reescritos para que no utilicen un protocolo que puede ser aprovechado para atacar un sistema que utilice OpenSSL.* 

Una vulnerabilidad así, obviamente, requiere acción inmediata. Y así lo hicieron las distribuciones de lanzamiento periódico en cuyas manos suele descansar la tranquilidad de millones de servidores repartidos por todo el mundo: Debian, RHEL, Ubuntu, etc. Estas distribuciones, como es bien sabido, adaptan y aplican parches de seguridad a versiones que no necesariamente son la última, por lo que, por ejemplo, en el caso de Debian, la versión de la biblioteca actualizada con el parche para DROWN es la 1.0.1k-3+deb8u4, aunque en upstream la versión actualizada sea la 1.0.2g. En cambio, una rolling release que depende de upstream para sus actualizaciones, aunque podría, en ocasiones, aplicar un parche de seguridad mientras espera poder actualizar con la última versión publicada por el proyecto. En tal modelo, se aplica opcionalmente un parche de seguridad que se aplica a una versión anterior del código que luego es “sobreescrito” con la última versión publicada por el proyecto, la cual incluye el parche ya por sí misma. 



Ahora bien, el modelo de archlinux ha fallado con OpenSSL. Al momento que se de escribir esta entrada aún no tenemos actualización de OpenSSL porque, según se ha explicado en la lista de correo, la nueva versión de OpenSSL implica un cambio de ABI (Interfaz Binaria de Aplicación) y tal cosa implica recompilar absolutamente todos los paquetes que dependan de OpenSSL. El cambio, aunque no he encontrado información clara al respecto, parece no proceder del parche de seguridad de DROWN (porque los parches aplicados en Debian no han cambiado la ABI), sino de otra sección de la biblioteca, aunque se especula que quizás sea un fallo como ya ocurrió alguna vez en el pasado. La ABI es, para explicarlo de una forma sencilla, la “convención” que exige un binario (normalmente una biblioteca) para poder comunicarse con otro binario y, si esta cambia, pero los programas que dependen de dicha biblioteca no son recompilados para que vuelvan a “entenderse” con aquella, simplemente dejarán de funcionar correctamente. Y como OpenSSL es utilizado por infinidad de proyectos, este es un riesgo que no se puede correr. 

Así las cosas, en archlinux aun hay que esperar “pacientemente” que se acaben de recompilar todos los paquetes que dependen de OpenSSL para que, en los próximos días, después de comprobarse que está todo correctamente recompilado, estos paquetes se pasen en bloque a los repositorios estables y se actualicen. archlinux utiliza métodos semiautomáticos para este tipo de procedimientos, pero en KaOS, que está exactamente en la misma situación, Anke “Demm” Boersma está forzando, en el repositorio de pruebas, una recompilación de todos los paquetes afectados de una forma que, al menos por lo que se ve en Github, es manual. Dicho de otro modo, las distribuciones a las cuales se les suele achacar rapidez en actualización por definición están siendo más lentas en resolver un gravísimo problema de seguridad que las distribuciones de lanzamiento periódico. 



Es cierto que la vulnerabilidad afecta solo a servidores y que, sinceramente, utilizar en un servidor archlinux o KaOS o cualquier distribución de lanzamiento continuo es una absoluta locura, pero ese no es el punto. Lo que estamos viviendo en estos momentos es el clásico “bloqueo” que se suele producir en Debian “testing” cuando se acumulan actualizaciones, con la diferencia de que Debian “testing” es absolutamente clara sobre qué es lo que es: una beta. De hecho, se ha dado una especie de orden en archlinux de detener las actualizaciones regulares de los paquetes que dependen de OpenSSL hasta que no sean recompilados, cosa paradójica en una distribución de lanzamiento continuo. Este bloqueo no es el primero que sucede por un cambio de ABI, pero es la primera vez que el bloqueo está vinculado a una actualización de seguridad; la vez anterior se debió a una actualización regular de la Biblioteca Estándar de C de GNU (GLibc) que conllevó, como es natural con una biblioteca omnipresente como esa, actualizar medio sistema operativo. Tal bloqueo era entendible y tolerable, pero es absolutamente intolerable en el caso de una actualización de seguridad, porque sienta un mal precedente: simplemente hemos tenido suerte de que archlinux sea una distribución mayoritariamente utilizada en ordenadores personales y no en servidores y que la vulnerabilidad sea grave para servidores, ¿pero qué habría sucedido si el fallo de seguridad hubiese afectado a sistemas personales? 

¿Cuál era el camino a seguir? Desconozco por qué no se intentó la ruta del parche de seguridad al estilo Debian, como se ha hecho en contadas ocasiones en archlinux; esa parece ser la solución más sencilla prima facie, pero KaOS tampoco la llevó a cabo, así que supongo que hay algún impedimento técnico que evita sea posible. Dado que nos encontramos con una limitación técnica del modelo de lanzamiento continuo, esto es, que para hacerse bien el lanzamiento continuo muchas veces se bloquea porque se ha producido un cambio no lineal en alguna actualización, la solución, en mi muy humilde opinión, tenía que ser “social”: lanzar un anuncio oficial que explique la situación y cómo desactivar por completo SSLv2 en la versión actual de OpenSSL en archlinux en vez de que lo haga notar Pedro López Valencia, un usuario muy activo de la comunidad, pero que no es ni TU ni desarrollador, en una lista de distribución. Estas son cosas que son responsabilidad de la distribución como tal, según mi parecer. 

[Imagen: 11966411?v=3&s=400]


Espero que se aprenda la lección, pero así como muchas veces he elogiado la excelente labor de archlinux, esta vez debo criticar lo que está siendo una gestión poco clara de una vulnerabilidad grave. Sinceramente, a mí me deja un mal sabor de boca aun sabiendo que DROWN no afectará a mi sistema personal (el servidor de este blog funciona con Debian, ¡cómo no!, y está perfectamente actualizado). Por eso, insisto una vez más en uno de mis mantras, el de la responsabilidad que engendra la libertad: si Linux Mint tuvo el problema que tuvo hace unos días, archlinux está atragantado con esta actualización de OpenSSL y ambas son distribuciones reputadas y con un buen historial, se demuestra una vez más que mantener una distribución Linux es un asunto muy, pero muy serio. 


Posibles temas similares...
Tema Autor Respuestas Vistas Último mensaje
  Noticia Urgente de última hora Tor y Firefox [VULNERABILIDAD] yuma2009 1 306 02-12-2016, 06:18 AM
Último mensaje: shek
  Aparece Vulnerabilidad en flash que afecta a google Chorme. shackur 0 504 30-06-2013, 04:06 PM
Último mensaje: shackur



Usuarios navegando en este tema: 1 invitado(s)