(Por Rubén Borlenghi, el Microsaurio) Parece que la cosa empieza con una pelea por la divulgación de fallas. Pero lo primero es lo primero: los usuarios del navegador Opera tienen que actualizar, si o si, a la versión 11.52, dado que el código necesario para atacar este navegador fue publicado hace quince días en Internet; ahora, vamos al chusmerío…

La semana pasada, el miércoles para más datos, los vikingos web (los desarrolladores de Opera) publicaron la versión 11.52. La nota que informaba sobre la actualización contenía dos lacónicos párrafos:

  • Se soluciona un tema de seguridad de Día Cero (0day, como dicen en el nortE)
  • Hubo una difusión irresponsable del código de ataque.

Y daban el link a un comentario sobre el tema en su blog de seguridad. Para allí me fui, y empezó a desarrollarse el culebrón.
También en ese texto había dos links; uno al post de los desarrolladores (referencias circulares no, muchachos…) y otro a su Base de Conocimientos, con la nota descriptiva de la falla, que mencionaba la posibilidad de meter código de ataque dentro de un archivo de imagen SVG.

Un problema con los scripts

Ahí a cosa se pone un poco más peliaguda, porque si se dan una vuelta por la página correspondiente de la güiquipedia, verán que SVG es un grupo de especificaciones para un formato de archivo basado en XML, que se usa para describir imágenes vectoriales que pueden contener script, entre otras cosas. No, no es una “inocente” imagen, es un archivo que puede reaccionar activamente cuando le pasás el mouse por encima, sin que hagas clic a nada… ¿me vas entendiendo?
Y los desarrolladores de Opera estaban bastante calentitos con un hacker, a quien no se nombra, porque había publicado el 10 de octubre en la web los detalles necesarios para aprovechar un error de programación, y ejecutar código en una máquina donde corriese Opera 11.51.
¿Razones de la calentura?:

  • El 30 de agosto por la noche la gente de Opera publicó la versión 11.51, que tenía la falla comentada, y nadie les dijo nada.
  • El 10 de octubre el hacker español José Vázquez publicó en su blog el código de ataque para una falla de Opera, con una frase burlona: “…este es una tema que he descubierto hace 362 días y he informado en ese momento a Opera, pero han decidido no solucionarlo…”

La empresa afirma que hace seis meses un cierto equipo de investigaciones de seguridad, en nombre de un investigador cuya identidad no les fue informada, los contactó para mencionarles varias fallas de seguridad del navegador. Que los solucionaron en Opera 11.11 (entregado al público el 18 de mayo) Sobre otras fallas, que no lograron reproducir, consultaron pidiendo más detalles, pero no tuvieron respuesta del innominado “grupo de investigaciones de seguridad”.
Y que seis meses después, un señor que ellos no conocen y que Tal Vez sería el mismo investigador original, logró aprovechar una de las fallas no emparchadas en mayo para generar este nuevo método de ataque.

El hacker posteó en Cierto Lugar el código, escrito en Ruby, y ahí pude leer que había agregado estas fechas: “…descubierto el 13 de octubre de 2010 (…) programado el 14 de octubre de 2010 (…) última revisión el 8 de octubre de 2011…” y también anotó que había adaptado ese código para que se pudiera atacar a usuarios del futuro Opera 12.x, cuando sea publicado. Lo cual (preparar una ataque contra un producto futuro) debe haber dejado felicísimos a los desarrolladores de Opera, imagínense…

La larga lista de “comments” debajo de la amarga nota de los desarrolladores muestra un debate que tiene defensores apasionados en cada lado: el tema de la divulgación pública de vulnerabilidades, o como la llaman allÁ arribA, “full disclosure”. Que se resume en “descubro una falla de seguridad en software, y la publico inmediatamente, así el fabricante se ve obligado a solucionarla rápidamente”.
Lo cual tiene su costado peligroso: durante cierto tiempo, cualquiera puede aprovechar el código de ataque para arruinar una PC. La tuya, por ejemplo.

Publicar o no publicar… ¿de cuánto estamos hablando?

Existen prácticas de “divulgación responsable” de las fallas de seguridad, al estilo de la RFPolicy de Rain Forest Puppy: se descubre una falla de seguridad, se avisa al desarrollador o proveedor, se le dan cinco días para solucionarlo; si el desarrollador contesta, se lo ayuda con información para que solucione el problema y no se publica nada hasta que el tema esté emparchado. Si no le contestan, el hacker publica la falla… y ahí hay un “problemita”. Junto con la falla hay que publicar la “prueba de concepto”: el código necesario para explotar esa falla exitosamente, cosa que los desgraciados de siempre harán al toque.
Así que ahí está expuesto el problema: publicar o no publicar. Y con un costadito sabroso.
“Tengo esta falla de tu software… ¿me pagás y te la informo sólo a vos, o no me pagás y la publico a los cuatro vientos?”
Dicen las malas lenguas que por la plata baila el hacker. Yo opino que no; no todos, bah. El debate queda ahí, sobre la mesa. Seguiremos contando más entretelones de la full disclosure, no te creas; para amenizarte el desayuno, basta con la pelea entre el hacker español y los vikingos web.


Warning: Uninitialized string offset 21 in /www/tecnozona.com/htdocs/wp-includes/functions.php on line 291

Warning: Uninitialized string offset 21 in /www/tecnozona.com/htdocs/wp-includes/functions.php on line 291

Por Ricardog

Periodista científico especializado en tecnología. Médico en retiro efectivo.

Deja una respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

Este sitio usa Akismet para reducir el spam. Aprende cómo se procesan los datos de tus comentarios.