... y con ese primer párrafo se desencadena el apocalipsis criptográfico, como bien lo denomina Luciano en su blog.
La falla descubierta por Bello es crítica al extremo. Permite comprometer un sistema en cuestión de minutos u horas y afecta desde hace 2 años a miles de hosts en el mundo que corren Debian y sus derivados. Estamos hablando de que es posible vulnerar los controles de acceso a virtualmente cualquier host con un servicio openssh que esté utilizando claves públicas. Ya hay scripts como para entretenerse bajando servers por todos lados.
Como debianero/debianita (near fanatic) que soy, esto me preocupa, y mucho. Si bien la solución fue bastante trivial (yo ya hice lo debido en cada host), así como también lo es la falla original, creo que es momento de plantearse seriamente el proceso de aplicación de parches en el proyecto. Luciano lo deja más que claro en su blog: "... necesitamos un proceso de auditoría real en los parches específicos de Debian. Es difícil, pero necesario."
En la red ya hay un cúmulo de repartijas de responsabilidades, en ./ en inglés, en ./ en castellano. Lo que yo saco en limpio es más o menos lo siguiente:
- Muchos de nosotros como desarrolladores de software libre tenemos una parte de responsabilidad ya, por el mínimo hecho de no auditar código por nuestra propia seguridad (y me incluyo entre los que no lo han hecho). Obviamente en los casos donde uno pueda, ya que leer código no es para cualquiera y cada paquete tiene lo suyo.
- El responsable del paquete también tiene lo suyo por realizar la modificación sin interiorizarse un poco más en el algoritmo subyacente (sepa Ud. que aquí hablo por tener boca y con autoridad nula). Aunque su responsabilidad no es tanta como se le ha atribuído originalmente, pues...
- Los desarrolladores de openssl (a quien debo mis respetos) sí fueron consultados originalmente respecto del parche, pero la respuesta no fue lo suficientemente explícita. Muchos ya han expresado su opinión respecto de que quizá deberían documentar un poco más el código fuente.
- La transparencia en los procedimientos de publicación y tratamiento de la vulnerabilidad. Un fallo de estas características en un producto privativo podría implicar una pérdida importante para su empresa proveedora, que en su intento de minimizar el impacto podría optar por ocultar no sólo el fallo sino su reparación. Los más conspirativos pueden pensar, incluso, que esto ocurre constantemente en muchos productos de software. Debian, por las características del proyecto y por cómo es llevado a cabo tiene la clave en el punto 3 del contrato social: No ocultaremos los problemas. Sólo esto, para mí, es fantástico.
- La celeridad con que actuó la comunidad. Para calcular esto deberíamos saber con exactitud cuándo se contactó Luciano con la gente de security, pero el hecho es que al momento de la publicación de la falla ya estaba en los mirrors la version de openssl arreglada.
- Y el hecho de que haya sido un propio Debian Developer (y argentino para colmo, tras que no somos agrandados) el que lo haya detectado. De acá es donde viene el título del post, él hizo lo que muchos debemos hacer: mirar para adentro.
- Mis felicitaciones a Luciano por su primer DSA que ha sido impactante.
- Cayendo se vuelve a andar, así dicen...
- Ah, y aprovechen iptables que para algo está.
1 comentario:
Mauro, vos bien lo decis en tu ultimo punto, iptables, iptables, iptables.
Hoy en dia, por mas acceso cerrado a root, SSH v2, fail2ban, etc, etc, etc...
Quien tiene un SSHD abierto a la internet?
Publicar un comentario