Análisis profundo: Cómo encontrar y corregir vulnerabilidades críticas en libcurl/curl

Hace poco tiempo, las comunidades de seguridad y desarrollo fueron alertadas por un aviso del desarrollador principal del proyecto curl, Daniel Stenberg, quien dio a conocer la desafortunada noticia de que se lanzó una nueva versión de curl, distribuida el 11 de octubre, para solucionar dos vulnerabilidades de seguridad de alto impacto, una de las cuales describe como "probablemente el peor fallo de seguridad de curl en mucho tiempo".

Un análisis post mortem en el blog de Stenberg señaló que las versiones afectadas de la biblioteca curl son susceptibles a una vulnerabilidad de desbordamiento de búfer basada en el montón, relacionada con un problema heredado del protocolo de proxy SOCKS5 en uso desde 2002.

Con su uso como herramienta de línea de comandos desde 1998, curl es ampliamente considerado un pilar fundamental de Internet. Con una historia tan dilatada y un uso tan extendido, es una dependencia que, si resulta ser vulnerable, podría tener implicaciones continuas para la ciberseguridad general.

Este incidente comparte similitudes con el devastador ataque Log4Shell en Log4j, otra dependencia vulnerable que sigue siendo explotada casi dos años después.
‍
>>> ¡Pon a prueba tus conocimientos ahora mismo con nuestra misión sobre curl!‍

La vulnerabilidad: Desbordamiento de búfer

El exploit se detalla bajo el identificador CVE-2023-38545, y afecta a las versiones de curl desde la 7.69.0 hasta la 8.3.0 inclusive. El error principal es una vulnerabilidad de desbordamiento de búfer basada en el montón, y los informes iniciales señalan que una explotación exitosa podría conducir a un ataque de ejecución remota de código (RCE) más devastador. Aunque este es un flujo de trabajo posible para un actor de amenazas, es un caso de uso poco común más que algo garantizado.

Quizás el único punto a favor para mitigar algunos de los riesgos es que la comunicación maliciosa debe pasar por un proxy SOCKS5, lo cual es una implementación relativamente poco común.

De manera similar al exploit de curl, echemos un vistazo a esta explicación sobre el desbordamiento de búfer:

Cuando se le indica a curl que utilice un proxy SOCKS5, este transmitirá el nombre de host y hará que el proxy lo resuelva. Sin embargo, si el nombre de host supera el límite de 255 bytes, curl resolverá el nombre de host localmente (como se ve en el fragmento de código a continuación: fuente).

En caso de que haya un protocolo de enlace lento entre el cliente y el proxy, es posible que el nombre de host largo se copie en el búfer de memoria en lugar de la dirección resuelta (más corta). La porción de memoria asignada solo permite un valor de 255 bytes, por lo que si recibe un valor que supera este límite, los datos desbordarán los límites del búfer de memoria.

>>> ¡Pruébalo tú mismo en esta misión interactiva!

El desbordamiento de búfer es un vector de ataque potente, y puede ser frecuente en muchos lenguajes de programación heredados. En este caso particular, la explotación dio paso a un ataque más grave y dañino en forma de RCE en algunos contextos, aunque esta vía sigue siendo poco común e improbable.

¿Cómo puedes mitigar el riesgo de desbordamiento de búfer?

En esta etapa, la prioridad de remediación más alta es aplicar los parches a todas las instancias vulnerables, recordando que el uso de curl está tan extendido que puede no ser obvio o evidente que los componentes de tu sistema incluyan la dependencia en uso. En ese caso, se requiere una auditoría y la posterior aplicación de parches.

En general, los fallos de desbordamiento de búfer pueden mitigarse utilizando un lenguaje de memoria segura como Rust; sin embargo, como ocurre con un proyecto tan extenso como curl, no es práctico migrar a otro lenguaje o reescribirlo de la noche a la mañana. Como señala Stenberg al discutir la posibilidad de usar y respaldar más dependencias escritas en lenguajes de memoria segura —o la alternativa de reemplazar gradualmente partes de curl poco a poco—: "... el desarrollo... actualmente ocurre a una velocidad casi glacial y muestra con dolorosa claridad los desafíos involucrados. curl seguirá escrito en C en el futuro previsible". No es una tarea pequeña, y las implicaciones de seguridad son inmensas.

Los errores de seguridad pueden ocurrir y ocurrirán, y no siempre es posible confiar en escáneres y pruebas para detectar todos los vectores de ataque posibles. Por lo tanto, nuestra mayor arma en la lucha contra estos errores es el compromiso con la concienciación continua sobre la seguridad y el desarrollo de habilidades.
‍

¿Quieres aprender más sobre cómo escribir código seguro y mitigar riesgos?

Prueba nuestro desafío de desbordamiento de búfer (Heap Overflow) gratis.

Si te interesa recibir más guías de programación gratuitas, echa un vistazo a Secure Code Coach para mantenerte al día con las mejores prácticas de programación segura.