Cómo provoqué un desbordamiento de heap en Curl

• Un artículo sobre CVE-2023-38545, un problema de seguridad importante descubierto en curl 8.4.0, considerado el problema de seguridad más grave en curl en mucho tiempo
• El problema es un desbordamiento de heap, causado por un defecto en la función que se conecta a un proxy SOCKS5
• Este problema se introdujo a principios de 2020, cuando la función se convirtió de llamadas bloqueantes a una máquina de estados no bloqueante, cambio realizado para mejorar el rendimiento de grandes transferencias paralelas a través de SOCKS5
• El defecto está en el estado INIT de la máquina de estados, donde se configura una variable local y curl decide si resolverá el host o si pasará el nombre al proxy. Si el nombre del host es demasiado largo, el código cambia al modo de resolución local, lo que puede provocar un desbordamiento de memoria si el nombre del host es más largo que el búfer de destino
• El desbordamiento puede ocurrir si el tamaño del búfer se configura por debajo de 65541 bytes y el nombre del host es más largo que el tamaño del búfer. Esto requiere que un actor malicioso introduzca un nombre de host gigantesco en la fórmula para detonar el defecto
• Un atacante que controle un servidor HTTPS al que acceden clientes que usan libcurl a través de un proxy SOCKS5 puede provocar un desbordamiento de búfer en el heap devolviendo a la aplicación una redirección manipulada mediante una respuesta HTTP 30x
• Este problema fue corregido en curl 8.4.0 haciendo que curl devuelva un error cuando el nombre del host es demasiado largo, en lugar de cambiar de resolución remota a resolución local. También se agregó un caso de prueba dedicado para este escenario
• El autor reconoce que este defecto no habría ocurrido si curl hubiera sido escrito en un lenguaje con seguridad de memoria en lugar de C, pero aclara que por ahora no hay planes de portar curl a otro lenguaje
• El autor propone que una vía viable es permitir, usar y dar soporte a más dependencias escritas en lenguajes con seguridad de memoria, e incluso reemplazar gradualmente algunas partes de curl
• El autor reconoce el error y se disculpa, señalando que este defecto podría haberse detectado con un mejor conjunto de pruebas. También menciona a los analizadores estáticos de código que no lograron encontrar el problema en esta función
• El autor concluye que entregar un desbordamiento de heap en código instalado en más de 20 mil millones de instancias no es una experiencia recomendable

[GN⁺]

Comentarios en Hacker News

• Un artículo sobre un problema de desbordamiento de heap en la biblioteca Curl, que se usa en muchos dispositivos y en su mayor parte fue escrita por una sola persona.
• Daniel, el autor de Curl, se disculpa por un error causado por un defecto que no fue encontrado en el código durante 1315 días.
• El artículo sugiere que los problemas de seguridad de memoria podrían haberse evitado si Curl hubiera sido escrito en un lenguaje con seguridad de memoria en lugar de C.
• El autor considera la posibilidad de reemplazar gradualmente partes de Curl con un lenguaje más seguro en memoria, pero reconoce el lento ritmo de ese desarrollo.
• El autor afirma que el 41% de las vulnerabilidades de seguridad de Curl podrían haberse evitado con un lenguaje con seguridad de memoria.
• Se reconoce que el artículo está escrito de forma clara y honesta al explicar la lógica y la perspectiva detrás del problema.
• Algunos comentarios cuestionan la gravedad del problema, argumentando que el vector de ataque es muy pequeño y que se requieren condiciones muy específicas para explotarlo.
• Un comentario critica la parte del código que puede filtrar la identidad del usuario a través de DNS para quienes usan herramientas anticensura.
• Otro comentario señala que el autor ignoró las restricciones de nombres de host DNS especificadas en RFC1123, y que eso pudo haber contribuido al problema.
• Se menciona que la actualización de seguridad más reciente de Windows 10 no incluía una versión nueva de Curl.