cURL es un proyecto de software consistente en una biblioteca y un intérprete de comandos orientado a la transferencia de archivos.

Daniel Stenberg (autor del proyecto cURL) dio a conocer hace poco mediante una publicación de blog, información sobre una vulnerabilidad que fue detectada en la utilidad para recibir y enviar datos a través de la red curl y la biblioteca libcurl.

Se menciona que la vulnerabilidad (ya catalogada bajo CVE-2023-38545) se debe a un error en el código de resolución del nombre de host antes de acceder al proxy SOCKS5.

SOCKS5 es un protocolo proxy. Es un protocolo bastante simple para configurar la comunicación de red a través de un «intermediario» dedicado. Por ejemplo, el protocolo se utiliza normalmente al configurar la comunicación a través de Tor, pero también para acceder a Internet desde organizaciones y empresas.

SOCKS5 tiene dos modos diferentes de resolución de nombres de host. O el cliente resuelve el nombre de host localmente y pasa el destino como una dirección resuelta, o el cliente pasa el nombre de host completo al proxy y permite que el proxy resuelva el host de forma remota .

Como tal el fallo puede provocar un desbordamiento del búfer y potencialmente la ejecución de código de un atacante en el lado del cliente cuando se accede mediante la utilidad curl o una aplicación que utiliza libcurl, a un servidor HTTPS controlado por el atacante. Pero el problema solo está presente si el acceso a través de un proxy SOCKS5 está habilitado en curl. Al acceder directamente sin proxy la vulnerabilidad no aparece.

Se describe que el propietario de un sitio al que accede curl a través de un proxy SOCKS5 puede:

Desencadenar un desbordamiento del búfer del lado del cliente devolviendo un código de redireccionamiento de solicitud (HTTP 30x) y configurando el encabezado «Location:» en una URL con un nombre de host cuyo tamaño oscila entre 16 hasta 64 KB (16 KB es el tamaño mínimo requerido para desbordar el búfer asignado y 65 KB es la longitud máxima permitida del nombre de host en una URL).

Si la redirección de solicitudes está habilitada en la configuración de libcurl y el proxy SOCKS5 utilizado es lo suficientemente lento, entonces el nombre de host largo se escribirá en un búfer pequeño, obviamente de menor tamaño.

En su publicación de blog, Daniel Stenberg, mencionó que la vulnerabilidad permaneció sin ser detectada durante 1315 días. También dice que el 41% de las vulnerabilidades previamente identificadas en curl probablemente se podrían haber evitado si curl se hubiera escrito en un lenguaje seguro para la memoria, pero no hay planes para reescribir curl en otro idioma en el futuro previsible.

La vulnerabilidad afecta principalmente a las aplicaciones basadas en libcurl y aparece en la utilidad curl solo cuando se usa la opción «–limit-rate» con un valor inferior a 65541, ya que libcurl asigna un búfer de 16 KB de forma predeterminada y 100 KB en curl, pero este tamaño cambia según el valor del parámetro «–limit-rate».

Se menciona que si el nombre del host tiene hasta 256 caracteres, curl pasa inmediatamente el nombre al proxy SOCKS5 para su resolución, y si el nombre tiene más de 255 caracteres, cambia al solucionador local y pasa la dirección ya definida a SOCKS5.  Debido a un error en el código, el indicador que indica la necesidad de resolución local podría establecerse en un valor incorrecto durante la negociación lenta de una conexión a través de SOCKS5, lo que llevó a la grabación de un nombre de host largo en un búfer asignado con la expectativa de almacenar la dirección IP o el nombre, sin exceder los 255 caracteres.

Finalmente, se menciona que la vulnerabilidad se solucionó en la versión curl 8.4.0 y como medidas para mejorar la seguridad del código base, se propone ampliar las herramientas para probar el código y utilizar más activamente dependencias escritas en lenguajes de programación que garanticen un funcionamiento seguro con la memoria. También está considerando reemplazar gradualmente partes de curl con opciones escritas en lenguajes seguros, como el backend experimental Hyper HTTP implementado en Rust.

Si estás interesado en poder conocer más al respecto, puedes consultar los detalles en el siguiente enlace.