CVSS: 9.8EPSS: 0%CPEs: 38EXPL: 0CVE-2018-1000007 – curl: HTTP authentication leak in redirects
https://notcve.org/view.php?id=CVE-2018-1000007
libcurl 7.1 through 7.57.0 might accidentally leak authentication data to third parties. When asked to send custom headers in its HTTP requests, libcurl will send that set of headers first to the host in the initial URL but also, if asked to follow redirects and a 30X HTTP response code is returned, to the host mentioned in URL in the `Location:` response header value. Sending the same set of headers to subsequent hosts is in particular a problem for applications that pass on custom `Authorization:` headers, as this header often contains privacy sensitive information or data that could allow others to impersonate the libcurl-using client's request. libcurl, desde la versión 7.1 hasta la 7.57.0, podría filtrar accidentalmente datos de autenticación a terceros. Cuando se le solicita que envíe cabeceras personalizadas en sus peticiones HTTP, libcurl enviará primero ese conjunto de cabeceras al host en la URL inicial pero también, si se le pide que siga redirecciones y se devuelve un código de respuesta HTTP 30X al host mencionado en la URL en el valor de la cabecera de respuesta "Location:". El envío de la misma serie de cabeceras a hosts subsecuentes es un problema en particular para las aplicaciones que pasan cabeceras "Authorization:" personalizadas, ya que esta cabecera suele contener información sensible de privacidad o datos que podrían permitir que otros suplanten la petición del cliente que emplea libcurl. • http://www.openwall.com/lists/oss-security/2022/04/27/4 http://www.securitytracker.com/id/1040274 https://access.redhat.com/errata/RHBA-2019:0327 https://access.redhat.com/errata/RHSA-2018:3157 https://access.redhat.com/errata/RHSA-2018:3558 https://access.redhat.com/errata/RHSA-2019:1543 https://access.redhat.com/errata/RHSA-2020:0544 https://access.redhat.com/errata/RHSA-2020:0594 https://curl.haxx.se/docs/adv_2018-b3bf.html https://lists.debian.org/debian • CWE-200: Exposure of Sensitive Information to an Unauthorized Actor •
CVSS: 6.5EPSS: 0%CPEs: 32EXPL: 0CVE-2017-1000101 – curl: URL globbing out of bounds read
https://notcve.org/view.php?id=CVE-2017-1000101
curl supports "globbing" of URLs, in which a user can pass a numerical range to have the tool iterate over those numbers to do a sequence of transfers. In the globbing function that parses the numerical range, there was an omission that made curl read a byte beyond the end of the URL if given a carefully crafted, or just wrongly written, URL. The URL is stored in a heap based buffer, so it could then be made to wrongly read something else instead of crashing. An example of a URL that triggers the flaw would be `http://ur%20[0-60000000000000000000`. curl es compatible con el "globbing" de URL, donde un usuario puede pasar un rango numérico para hacer que la herramienta itere sobre esos números para realizar una secuencia de transferencias. En la función de "globbing" que analiza sintácticamente el rango numérico, hay una omisión que hace que curl lea un byte más allá del fin de la URL si se proporciona una URL manipulada o simplemente mal escrita. • http://www.debian.org/security/2017/dsa-3992 http://www.securityfocus.com/bid/100249 http://www.securitytracker.com/id/1039117 https://access.redhat.com/errata/RHSA-2018:3558 https://curl.haxx.se/docs/adv_20170809A.html https://security.gentoo.org/glsa/201709-14 https://support.apple.com/HT208221 https://access.redhat.com/security/cve/CVE-2017-1000101 https://bugzilla.redhat.com/show_bug.cgi?id=1478309 • CWE-119: Improper Restriction of Operations within the Bounds of a Memory Buffer CWE-125: Out-of-bounds Read •
CVSS: 5.3EPSS: 0%CPEs: 1EXPL: 0CVE-2017-9502
https://notcve.org/view.php?id=CVE-2017-9502
In curl before 7.54.1 on Windows and DOS, libcurl's default protocol function, which is the logic that allows an application to set which protocol libcurl should attempt to use when given a URL without a scheme part, had a flaw that could lead to it overwriting a heap based memory buffer with seven bytes. If the default protocol is specified to be FILE or a file: URL lacks two slashes, the given "URL" starts with a drive letter, and libcurl is built for Windows or DOS, then libcurl would copy the path 7 bytes off, so that the end of the given path would write beyond the malloc buffer (7 bytes being the length in bytes of the ascii string "file://"). En curl en sus versiones anteriores a la 7.54.1 de Windows y DOS, la función libcurl de protocolo por defecto, el cual es lógico que permita una aplicación poner que protocolo libcurl debe intentar usar cuando una URL le es dada sin una parte diseñada, tiene un flaw que podría llevar a sobrescribir buffer heap --heap-- con siete bytes. Si se especifica que el protocolo sea FILE o un archivo: A la URL le faltan dos barras, la URL dada comienza con una letra de unidad, y libcurl es construida para Windows o DOS, entonces libcurl copiaría la ruta de 7bytes, asique el final de la ruta dada escribiría mas allá del buffer reservado (7 bytes son la longitud de la cadena ASCII "file://"). • http://openwall.com/lists/oss-security/2017/06/14/1 http://www.securityfocus.com/bid/99120 http://www.securitytracker.com/id/1038697 https://curl.haxx.se/docs/adv_20170614.html • CWE-119: Improper Restriction of Operations within the Bounds of a Memory Buffer •
CVSS: 6.5EPSS: 0%CPEs: 1EXPL: 0CVE-2017-2629
https://notcve.org/view.php?id=CVE-2017-2629
curl before 7.53.0 has an incorrect TLS Certificate Status Request extension feature that asks for a fresh proof of the server's certificate's validity in the code that checks for a test success or failure. It ends up always thinking there's valid proof, even when there is none or if the server doesn't support the TLS extension in question. This could lead to users not detecting when a server's certificate goes invalid or otherwise be mislead that the server is in a better shape than it is in reality. This flaw also exists in the command line tool (--cert-status). curl en versiones anteriores a la 7.53.0 tiene una característica de extensión TLS Certificate Status Request que solicita una nueva prueba de la validez del certificado del servidor en el código que comprueba el éxito o el fracaso de una prueba. Acaba siempre pensando que hay pruebas válidas, incluso cuando no hay ninguna o si el servidor no soporta la extensión TLS en cuestión. • http://www.securityfocus.com/bid/96382 http://www.securitytracker.com/id/1037871 https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2017-2629 https://curl.haxx.se/docs/adv_20170222.html https://security.gentoo.org/glsa/201703-04 https://www.tenable.com/security/tns-2017-09 • CWE-295: Improper Certificate Validation •
CVSS: 7.5EPSS: 0%CPEs: 1EXPL: 0CVE-2016-8625 – curl: IDNA 2003 makes curl use wrong host
https://notcve.org/view.php?id=CVE-2016-8625
curl before version 7.51.0 uses outdated IDNA 2003 standard to handle International Domain Names and this may lead users to potentially and unknowingly issue network transfer requests to the wrong host. curl en versiones anteriores a la 7.51.0 emplea el estándar IDNA 2003 obsoleto para gestionar nombres de dominio internacionales, lo que podría hacer que los usuarios envíen peticiones de transferencia de red al host erróneo sin darse cuenta. • http://www.securityfocus.com/bid/94107 http://www.securitytracker.com/id/1037192 https://access.redhat.com/errata/RHSA-2018:2486 https://access.redhat.com/errata/RHSA-2018:3558 https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2016-8625 https://curl.haxx.se/CVE-2016-8625.patch https://curl.haxx.se/docs/adv_20161102K.html https://lists.apache.org/thread.html/r58af02e294bd07f487e2c64ffc0a29b837db5600e33b6e698b9d696b%40%3Cissues.bookkeeper.apache.org%3E https://lists.apache.org/thread.html/rf4c0277 • CWE-20: Improper Input Validation •