심층 분석: 심각도가 높은 libcurl/curl 취약성 발견 및 수정

Hace poco tiempo, las comunidades de seguridad y desarrollo fueron puestas sobre aviso con un aviso del desarrollador principal del proyecto curl, Daniel Stenberg, que dejó caer la desafortunada misiva de que una nueva versión de curl -distribuida el 11 de octubre- se lanzaba para solucionar dos vulnerabilidades de seguridad de gran impacto, una de las cuales describe como "probablemente el peor fallo de seguridad de curl en mucho tiempo".

Un postmortem 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 Heap, relacionada con un problema heredado con el protocolo proxy SOCKS5 en uso desde 2002.

Con su uso como una herramienta de línea de comandos que se remonta a 1998, curl es ampliamente considerado como un pilar fundamental de Internet. Con una historia tan larga y un uso tan extendido, es una dependencia que, si se descubre que es vulnerable, podría tener implicaciones para la ciberseguridad en 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 curl!‍

La vulnerabilidad: Desbordamiento del búfer

El exploit se detalla bajo CVE-2023-38545, y afecta a las versiones de curl 7.69.0 hasta 8.3.0 inclusive. El error principal es una vulnerabilidad de desbordamiento de búfer basada en Heap, 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. Si bien este es un posible flujo de trabajo para un actor de amenaza, es un caso de uso raro en lugar de un hecho.

Tal vez la única salvación para mitigar algunos de los riesgos es que la comunicación maliciosa debe pasar a través de un proxy SOCKS5, que es un despliegue relativamente infrecuente.

Comparable al exploit curl, echemos un vistazo a este Buffer Overflow explainer:

Cuando se le dice a curl que use un proxy SOCKS5, pasará 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 siguiente: fuente).

En caso de que se produzca un intercambio 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 sólo permite un valor de 255 bytes, por lo que si recibe un valor que exceda este límite, los datos desbordarán los límites del buffer de memoria.

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

El desbordamiento del búfer es un poderoso vector de ataque, que puede ser frecuente en muchos lenguajes de programación heredados. En este caso concreto, 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 y poco probable.

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

En esta etapa, la remediación de mayor prioridad es aplicar los parches a todas las instancias vulnerables, con un recordatorio de que el uso de curl está tan extendido, que puede no ser necesariamente obvio o anunciado que los componentes de su sistema incluyen la dependencia en uso. En ese caso, se requiere auditoría y posterior aplicación de parches. 

En general, los fallos de desbordamiento de búfer pueden mitigarse utilizando un lenguaje seguro para la memoria como Rust, sin embargo, como es el caso de un proyecto tan extenso como curl, no es práctico portarlo a otro lenguaje o reescribirlo por capricho. Como Stenberg señala mientras discute el potencial para usar y soportar más dependencias escritas en lenguajes seguros para la memoria - o la alternativa de reemplazar gradualmente partes de curl poco a poco - "... el desarrollo está... ocurriendo actualmente a una velocidad casi glacial y muestra con dolorosa claridad los desafíos involucrados. curl permanecerá escrito en C en el futuro previsible". No es una empresa 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 que los escáneres y las pruebas detecten todos los vectores de ataque posibles. Por lo tanto, nuestra mejor arma en la lucha contra estos fallos es el compromiso con la concienciación y la capacitación continuas en materia de seguridad.
‍

¿Quiere saber más sobre cómo escribir código seguro y mitigar los riesgos?

Pruebe nuestro Heap Overflow gratis.

Si está interesado en obtener más directrices de codificación gratuitas, consulte Entrenador de código seguro que le ayudará a mantenerse al día de las mejores prácticas de codificación segura.