Fastly entre bastidores: una muestra de nuestro proceso de corrección de vulnerabilidades
No dejan de impresionarnos las formas en que los ingenieros usan nuestra plataforma para desarrollar cosas increíbles, diseñar servicios excepcionales e incluso comentarnos los errores que hemos cometido. Un ejemplo de esto último fue el informe que el investigador Emil Lerner envió a nuestro programa de divulgación de vulnerabilidades tras descubrir un error muy interesante.
Creemos que esta es la ocasión perfecta para revelarte algunos datos clave para que conozcas mejor nuestro proceso de corrección de vulnerabilidades y al equipo encargado de ello. A fin de cuentas, nadie mejor para contarte qué funciona —y por qué— que nosotros mismos, ¿verdad?
En este artículo, te contamos qué vulnerabilidad descubrió Emil Lerner, cómo desplegamos la corrección pertinente en tan solo siete días tras el triaje y cómo fuimos capaces de hacerlo tan rápido, frente al plazo medio de corrección que recomienda la Agencia de Ciberseguridad y Seguridad de Infraestructuras de los EE. UU., que es de 30 días.
Antes de entrar en detalle, nos gustaría subrayar que no tenemos pruebas ni razones para creer que nadie haya aprovechado esta vulnerabilidad para atacar a los clientes.
El equipo
Uno de los objetivos del equipo de corrección de vulnerabilidades, que forma parte de nuestro departamento de seguridad, es comprender las debilidades detectadas y ayudar a los equipos internos de ingeniería a solucionarlas. Colaboramos estrechamente con ellos y varios investigadores de seguridad para supervisar y corregir vulnerabilidades. Nos centramos en estudiar algunos aspectos que, por la metodología que manejamos, nos permiten trabajar con exhaustividad y rapidez.
En primer lugar, tratamos de mejorar constantemente nuestro proceso de triaje de vulnerabilidades, en el que intentamos comprender y reproducir los problemas notificados en un plazo de cinco días laborables, lo que supone la mitad del plazo de triaje medio.
En segundo lugar, nos aseguramos de que nuestro equipo de ingeniería tenga tanta información como sea posible para iniciar el proceso de depuración. Para ello, optimizamos la forma de comunicación del informe y, por ejemplo, damos al equipo un método para reproducir rápidamente el problema, a ser posible de forma automatizada.
Por último, procuramos contratar a las mentes más brillantes en el campo de la ingeniería (por cierto, ahora mismo tenemos vacantes). En consecuencia, contamos con un equipo excelente, con amplia experiencia en programación de sistemas y en protocolos de red. Los procesos y flujos de trabajo que usan les permiten revisar el informe y tomar medidas rápidamente, tal y como sucedió con esta vulnerabilidad en particular.
La vulnerabilidad
La vulnerabilidad, notificada el 23 de noviembre de 2021, está relacionada con la implementación de HTTP/3 desde el servidor en H2O/QUIC, servidor HTTP optimizado que es compatible con los protocolos HTTP/1, HTTP/2 y HTTP/3. De hecho, somos colaboradores clave en QUIC, proyecto de código abierto que se ejecuta con HTTP/3. Se descubrió que, si el servidor H2O recibe un conjunto de marcos QUIC en un orden determinado, se puede engañar a H2O para que trate la memoria no inicializada como marcos HTTP/3 recibidos.
Si, en esas circunstancias, se utiliza H2O como proxy inverso, un atacante puede aprovechar esta vulnerabilidad para hacer que el proxy inverso envíe el estado interno de H2O a los servidores backend controlados por el atacante o un tercero, como se detalla en el diagrama a continuación. El atacante no controla lo que vuelca exactamente el servidor H2O; pueden ser las peticiones de otros usuarios, las respuestas a estas o cualquier otro elemento presente en la memoria previamente liberada de H2O.
Esta vulnerabilidad, que se conoce como «CVE-2021-43848», solo habría podido afectar a usuarios que hubieran habilitado HTTP/3 en Fastly (y solo a servicios que se ejecutaran con HTTP/3). Reiteramos que no tenemos pruebas ni razones para creer que esta vulnerabilidad haya sido aprovechada para atacar a ninguno de esos clientes.
El proceso de corrección
Nuestro equipo de triaje inicial recibió y aceptó el informe, y lo reenvió a nuestro equipo de triaje de vulnerabilidades para someterlo a una revisión técnica más detallada.
Tras revisar el informe y reproducir el error, nuestros ingenieros identificaron el problema, crearon la corrección y la desplegaron en un entorno de pruebas en un día. Descubrimos que, cuando se actualiza el búfer de recepción del protocolo HTTP/3 de H2O a través de h2o_http3_update_recvbuf en lib/http3/common.c, la memoria que está en uso para el búfer no se borra antes de ser reutilizada si el tamaño de este es inferior al nuevo.
El equipo de triaje de vulnerabilidades volvió a realizar pruebas y confirmó que el problema se corregía con los cambios de código. Una vez confirmada la corrección, se inició y completó el proceso de despliegue. Puedes consultar la línea cronológica completa a continuación.
23 de noviembre de 2021: un investigador notifica el problema.
24 de noviembre de 2021: el equipo encargado del triaje inicial recibe la notificación.
29 de noviembre de 2021: el equipo de triaje de vulnerabilidades completa el estudio de la notificación y confirma que el problema se puede reproducir.
1 de diciembre de 2021: el equipo de ingeniería crea una corrección y un entorno de pruebas, y el equipo de triaje de vulnerabilidades realiza nuevas pruebas para revisar la corrección. El equipo de triaje de vulnerabilidades se comunica con el investigador para que este confirme que la modificación de código propuesta corrige la vulnerabilidad.
8 de diciembre de 2021: finaliza el despliegue de la corrección.
Conclusión
Al final, el informe mereció una recompensa y, como puede verse en la cronología anterior, todo el proceso duró apenas dos semanas. Es un plazo del que estamos muy orgullosos y que fue posible gracias al excelente trabajo realizado por este equipo. Tenemos que agradecer a Emil Lerner que nos enviara ese informe. Aquí nos lo cuenta él mismo.
