Puede que no hayas oído hablar de Curl (o como se escribe correctamente: curl), pero es uno de esos conjuntos de herramientas de código abierto que casi seguro has utilizado, probablemente muy a menudo, sin saberlo.
El mundo del código abierto ofrece numerosas herramientas de este tipo, omnipresentes, ampliamente utilizadas en proyectos de software de todo el mundo, pero a menudo invisibles o escondidas bajo las sabanas, y por lo tanto quizás no tan bien apreciadas como deberían.
SQLite, OpenSSL, zlib, FFmpeg, Minix, etc., la lista de componentes de la cadena de suministro que están incorporados en el hardware y el software que utilizas todo el tiempo, a menudo con nombres completamente diferentes, es larga.
Curl es una de esas herramientas y, como explica su propia web, es una “herramienta de línea de comandos y una biblioteca para transferir datos con URL (desde 1998)”.
Forma parte de casi todas las distribuciones de Linux del planeta, incluidos muchos, si no la mayoría, de los dispositivos IoT integrados, que lo utilizan para programar cosas como actualizaciones y cargas de datos; se incluye en macOS de Apple y en Windows 10 y 11.
También puedes construir y utilizar curl como una biblioteca compartida (busca los archivos llamados libcurl.*.so o CURL*.DLL), para poder llamar al código de curl sin ejecutar un proceso separado y recoger la salida, pero eso también cuenta como “usar curl”.
Última actualización
El proyecto acaba de lanzar su última actualización, corrigiendo seis errores de nivel medio con número CVE, y llevando curl a la versión 7.83.1.
Puedes comprobar qué versión tienes con el comando curl –version, así:
$ curl --version curl 7.83.1 (x86_64-pc-linux-gnu) libcurl/7.83.1 OpenSSL/1.1.1o zlib/1.2.12 brotli/1.0.9 zstd/1.5.2 c-ares/1.18.1 libidn2/2.3.2 libpsl/0.21.1 (+libidn2/2.3.0) libssh2/1.10.0 nghttp2/1.47.0 OpenLDAP/2.6.2 Release-Date: 2022-05-11 Protocols: dict file ftp ftps gopher gophers http https imap imaps ldap ldaps mqtt pop3 pop3s rtsp scp sftp smb smbs smtp smtps telnet tftp Features: alt-svc AsynchDNS brotli GSS-API HSTS HTTP2 HTTPS-proxy IDN IPv6 Kerberos Largefile libz NTLM NTLM_WB PSL SPNEGO SSL TLS-SRP UnixSockets zstd $ # Details in your build may vary depending on what was compiled in
Los errores fueron:
- CVE-2022-30115. Evasión de HSTS a través del punto final. HSTS es la abreviatura de HTTP Strict Transport Security. Se trata de un sistema similar a las cookies mediante el cual un sitio web que visitas utilizando HTTPS puede decirte a ti y al software que utilizas: “¡Haz siempre esto en el futuro! No vuelvas a usar el viejo HTTP, aunque el usuario tenga un viejo enlace http:// enterrado en una página web o en un script en algún lugar y siga usándolo”. La idea es que al redirigir tu servidor HTTP a las páginas HTTPS equivalentes, los visitantes que utilicen HTTP por error sólo lo harán una vez. Después de la primera redirección, su navegador recordará la bandera HSTS establecida por la página a la que fueron redirigidos, y comenzará con HTTPS en el futuro. Desafortunadamente, dado que los nombres de los servidores pueden escribirse con o sin un punto al final (estrictamente hablando, el dominio ejemplo PUNTO com es en realidad ejemplo PUNTO com PUNTO), curl podría ser engañado para que tratara las dos variantes como si fueran sitios web diferentes, dando potencialmente a los atacantes una forma de atraer a curl para que utilice inesperadamente una conexión insegura que podría por tanto ser redirigida, espiada o modificada en tránsito. El código actualizado reconoce ahora estos “pares de nombres” como referidos al mismo servidor.
- CVE-2022-27782. Reutilización demasiado ansiosa de las conexiones TLS y SSH. Curl intenta mantener abiertas las conexiones web existentes para su reutilización, dado que es muy común hacer peticiones repetidas al mismo sitio, e incluso al mismo directorio, cuando se descargan montones de archivos nuevos como actualizaciones, galerías de imágenes, etc. En general, no hay problemas de seguridad al hacer esto, siempre y cuando las conexiones reutilizadas impliquen conectarse exactamente de la misma manera al mismo sitio. Pero curl no siempre comprueba que todas las configuraciones de conexión sean las mismas, por lo que algunos detalles de seguridad podrían haber sido intercambiados en el ínterin. Estos detalles podrían incluir información como el nombre de usuario y la contraseña, lo que teóricamente permitiría a un usuario furtivo aprovechar una conexión anterior, aunque las credenciales de autenticación que suministraron en su propia solicitud no pasarían el examen si la conexión se estableciera desde cero. El código actualizado ahora obliga a establecer una nueva conexión a menos que todas las configuraciones de conexión coincidan exactamente con las de su uso anterior.
- CVE-2022-27781. CERTINFO búsqueda activa interminable. Este fallo podía desencadenarse si se pedía a curl que extrajera todos los detalles de la llamada cadena de confianza de los certificados web en una conexión protegida por TLS. Curl podría quedarse atascado en un bucle infinito mientras recorre la lista. Dado que puedes indicar a curl para que valide la cadena de confianza sin obtener todos los certificados por ti mismo (de hecho, puedes argumentar que es más seguro dejar que curl haga la verificación por ti, del mismo modo que es más seguro usar una biblioteca criptográfica de confianza que tejer la tuya propia), es poco probable que este fallo afecte a mucho código de la vida real. Las herramientas de registro de seguridad suelen estar interesadas en examinar y registrar los detalles de la cadena de certificados, pero esperamos que este tipo de herramientas, desarrolladas para buscar y registrar posibles anomalías, incluyan su propia protección de bucle infinito para detectar y acabar con los intentos de espionaje de seguridad que nunca terminan.
- CVE-2022-27780. Separador codificado como porcentaje en el host de la URL. Este es un fallo interesante que nos recuerda lo difícil que es lidiar con todas las variaciones y caprichos de cómo se presentan los datos en las peticiones web. Por ejemplo, las URL usan el carácter BARRA de una manera especial, como separador, así que si quieres codificar un carácter de barra en un término de búsqueda, por ejemplo, necesitas codificarlo de una manera especial también, usando un signo de porcentaje seguido de su código hexadecimal: %2F. Desgraciadamente, se puede colar un %2F en la parte del nombre del servidor de una URL de curl, por ejemplo escribiendo dodgy.invalid%2Fmy.nice.example, que a un filtro de URL le parece que es un servidor alojado en un dominio llamado nice.example). Pero cuando curl realmente iba a hacer la conexión, la cadena se convertiría en invalid/my.nice.example, donde el carácter BARRA decodificado actuaría de repente como un separador entre el nombre del servidor y el resto de la URL, por lo que la conexión se haría con el dominio de nivel superior invalid en su lugar.
- CVE-2022-27779. Cookie para el punto final del TLD. Se trata de un tipo de error similar al primero de la lista. Se supone que los navegadores y los descargadores deben ignorar las cookies establecidas para los llamados prefijos públicos, como .com o .co.uk, para que los operadores sin escrúpulos no puedan engañarte para que establezcas cookies en un nivel de dominio bajo el cual cada subdominio es probable que esté bajo el control de un propietario diferente. Como puedes imaginar, esto estropearía la política de “mismo origen”, y podría filtrar datos de cookies entre sitios teo que fueran propiedad y estuvieran operados por personas completamente diferentes. Un punto al final de un nombre de dominio podría confundir la comprobación de curl, y permitir que se establezcan cookies para dominios de alto nivel peligrosos.
- CVE-2022-27778. Curl elimina un archivo incorrecto por error. Esto es un recordatorio de cómo diferentes opciones de productos pueden terminar compitiendo entre sí de maneras que el programador nunca esperó. Curl tiene una opción –no-clobber, que evita que una descarga sobrescriba un archivo existente por error. A la segunda y subsiguientes descargas del mismo archivo se les añade un número para crear un nombre nuevo y único que no sobreescriba ningún archivo existente. Pero curl también tiene –remove-on-error, que dice que se borre el archivo que se acaba de descargar si algo va mal, para evitar dejar archivos parciales o dañados. Si usas ambas opciones, entonces una descarga fallida de un archivo que ya existía dejaría datos incompletos en el archivo nuevo y único (el que tiene un número al final), y borraría erróneamente el archivo original que –no-clobber debía proteger.
¿Qué hacer?
- Actualiza a curl 7.83.1 si puedes en tus propios sistemas. Si curl forma parte de la distribución de tu sistema operativo, como suele ocurrir en Windows, Mac y Linux, probablemente tendrás un parche en la próxima actualización programada. (El hecho de que ninguno de estos fallos sea crítico, y que ninguno de ellos se haya visto “in the wild”, significa que las actualizaciones de emergencia o fuera de banda son poco probables para los productos de código cerrado).
- Si tienes un aparato u otro dispositivo de red, comprueba con tu proveedor si utiliza curl (es muy probable que lo haga) y, si es así, cuándo puedes esperar una actualización.
- Si te encargas de tus propios proyectos de software, echa un vistazo a la página de avisos de seguridad de curl. Es un excelente ejemplo de cómo documentar las actualizaciones de seguridad de forma clara, limpia y correcta, con explicaciones en inglés sencillo y una lista útil que muestra el número de versión cuando cada error entró por primera vez en la base de código, y cuando fue corregido.
El proyecto Curl hace que sea fácil averiguar cómo informar de los errores; dice lo que puedes esperar cuando los informes; e incluso incluye un elemento de Seguridad en su menú desplegable de Documentación, dejando así claro que los informes de seguridad son ciudadanos de primera clase en su ecosistema de desarrollo de software.
Una pequeña cosa que puedes hacer y que el equipo de Curl no ha hecho todavía es añadir un archivo security.txt, en un formato estándar, en un lugar estándar conocido de tu sitio web. De esta manera, hay un lugar canónico, en un formato canónico, donde los investigadores de seguridad pueden encontrar tus canales oficiales de notificación de errores. Puedes usar el nuestro como ejemplo, mirando en sophos.com/security.txt y en sophos.com/.well-known/security.txt.