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
