Hace unos días nos llegó la noticia de la propia Adobe: Flash se acaba en 2020. Listo. Fin de una era. Aunque en su nota de prensa no mencionan ni de pasada las 1033 vulnerabilidades de seguridad (casi todas de máxima gravedad) que salen en una búsqueda rápida, Adobe alega únicamente un cambio de rumbo en la tecnología hacia estándares más abiertos, tales como HTML5 y WebGL.
Lo de Flash era una muerte anunciada. No podía ser de otro modo. Arrinconado por las vulnerabilidades, autentica puerta de entrada de toda clase de malware, y denostado por los buscadores, Flash fue reduciendo su masa de usuarios, desarrolladores y navegadores que lo soportan. Es incontable la cantidad de exploits que usan Flash como vector de explotación (junto con Adobe PDF Reader o Java, el tridente de la inseguridad). Es tal el ritmo de aparición de CVE sobre Flash que hasta dejaron de ser noticia.
Aunque Adobe fija su fin en 2020, todavía nos quedarán los rescoldos de una larga batalla por la expulsión de Flash del campo de juego del navegador. Engaños a usuarios desprevenidos (“pinche aquí amigo, instálese la última versión de Flash”, “Ah, ¿pero no había desaparecido?”, “pinche aquí amigo”, “vale, vale, pincho”) o navegadores sin actualizar. Sorprende que incluso con la política de actualizaciones automáticas todavía hay usuarios que no reinician el navegador para aplicarlas. Eso nos deja una pequeña rendija abierta en la ventana de exposición.
Flash no se queda solo. Los lectores de PDF incrustados en el navegador van siendo desplazados por el propio lector hecho en Javascript (no es broma, hecho en puro Javascript). Esto permite cerrar la vía a esos auténticos monstruos salidos de la mente de un escritor pasado de absenta que son los complementos nativos, auténticos quebraderos de cabeza de la navegación segura.
Otro que va borrando su mala impronta es Java. Hace tiempo que fue noticia su práctico baneo por los principales navegadores, y su uso generalista se ve marginado a ciertas aplicaciones obsoletas y sin mantenimiento, por ejemplo, algunas webs gubernamentales en las que te exigen “INTERNET EXPLORER 5.5 o superior / Java RunTime Environment Sun Versión 1.4.2. o superior” (la cita es textual, de la página de un Ministerio). Quién ha instalado una máquina virtual con un Windows 2000 y Java 1.4 obsoletos para firmar digitalmente sabe de qué se está hablando. Ahora esa misma firma electrónica se efectúa en, sorpresa, Javascript.
¿Nos quedamos aquí?
Para nada. Si miramos las propias implementaciones de Javascript (o el propio Java) vemos otros de los grandes culpables de hacer saltar por los aires a los navegadores: C y C++. Estos lenguajes de programación fueron diseñados hace décadas, cuando la gente ni sospechaba de lejos la fiesta que podía armarte un simple memcpy con un inocente búfer y una cadena de entrada procedente de usuario. Eso y la falta (necesaria) de un recolector de basura, hacía que la gestión de memoria fuera un desastre en manos de gente sin experiencia, con prisas o con las dos mencionadas condiciones a la vez.
C++ es un lenguaje complejo, muy complejo. Tanto que los propios expertos reconocen que es imposible aprender completamente cada una de sus características, o que es casi imposible crear un intérprete (parser) de la gramática completa (ver pag. 147). Aunque las nuevas versiones del estándar han reducido enormemente la capacidad de crear errores en la gestión de memoria, gracias a los punteros “inteligentes” (shared_ptr, unique_ptr, (ojo, no auto_ptr)), el daño ya está hecho. Además, incluso con estas mejoras, es complicado encontrar desarrolladores con un buen nivel en este lenguaje.
Vemos un comienzo en la evolución en este campo: nuevos lenguajes de programación, adaptados a los requisitos de seguridad y amigables para atraer nuevos programadores. Desde la propia Mozilla, han diseñado un lenguaje que permite obtener buenos tiempos de ejecución sin necesidad de gestión manual de la memoria: Rust. Este lenguaje les ha permitido reemplazar componentes de Firefox que anteriormente estaban hechos en C++ a otros en Rust, como por ejemplo Servo o Quantum. Es previsible que de manera progresiva se vayan adaptando más partes a este nuevo lenguaje si les acompañan los buenos resultados en rendimiento y desarrollo.
Como vemos, no hay nada escrito en piedra. Poco a poco se vencen antiguos paradigmas, modelos obsoletos y se cierran viejas heridas. Naturalmente, no vamos a dejar de ver exploits. Tan pronto como las antiguas técnicas dejen de ser efectivas se investigarán otras que den resultados similares. Además, y lo más importante, aunque reduzcamos la superficie de ataque, cerremos la ventana de exposición y creemos nuevos lenguajes más seguros, jamás podremos eliminar el componente más vulnerable de todo el sistema: el usuario.
David García
dgarcia@hispasec.com
Más información:
flash & the future of interactive content
Navegadores inseguros
Deja una respuesta