CVSS: 9.8EPSS: 1%CPEs: 4EXPL: 0CVE-2017-8817 – curl: FTP wildcard out of bounds read
https://notcve.org/view.php?id=CVE-2017-8817
The FTP wildcard function in curl and libcurl before 7.57.0 allows remote attackers to cause a denial of service (out-of-bounds read and application crash) or possibly have unspecified other impact via a string that ends with an '[' character. La función FTP wildcard en curl y libcurl en versiones anteriores a la 7.57.0 permite que atacantes remotos provoquen una denegación de servicio (lectura fuera de límites y cierre inesperado de aplicación) o, probablemente, causen cualquier otro tipo de impacto mediante una cadena que termina con un carácter "[". • http://security.cucumberlinux.com/security/details.php?id=162 http://www.securityfocus.com/bid/102057 http://www.securitytracker.com/id/1039897 https://access.redhat.com/errata/RHSA-2018:3558 https://curl.haxx.se/docs/adv_2017-ae72.html https://lists.debian.org/debian-lts-announce/2017/11/msg00040.html https://security.gentoo.org/glsa/201712-04 https://www.debian.org/security/2017/dsa-4051 https://access.redhat.com/security/cve/CVE-2017-8817 https://bugzilla.redhat.com& • CWE-125: Out-of-bounds Read •
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 •