ALPINE-CVE-2016-8623
A flaw was found in curl before version 7.51.0. The way curl handles cookies permits other threads to trigger a use-after-free leading to information disclosure.
- Actualiza a 7.49.1-r4
Publicación Actualización
PatchFirst · Vulnerabilidades recientes
Vulnerabilidades de curl
Vulnerabilidades publicadas para curl en los últimos 30 días: 0. Incluidas en el catálogo KEV: 0.
Vulnerabilidades: 27
ALPINE-CVE-2016-8620
The 'globbing' feature in curl before version 7.51.0 has a flaw that leads to integer overflow and out-of-bounds read via user controlled input.
- Actualiza a 7.49.1-r4
Publicación ActualizaciónALPINE-CVE-2016-8619
The function `read_data()` in security.c in curl before version 7.51.0 is vulnerable to memory double free.
- Actualiza a 7.49.1-r4
Publicación ActualizaciónALPINE-CVE-2016-8616
A flaw was found in curl before version 7.51.0 When re-using a connection, curl was doing case insensitive comparisons of user name and password with the existing connections. This means that if an unused connection with proper credentials exists for a protocol that has connection-scoped credentials, an attacker can cause that connection to be reused if s/he knows the case-insensitive version of the correct password.
- Actualiza a 7.49.1-r4
Publicación ActualizaciónALPINE-CVE-2016-8615
A flaw was found in curl before version 7.51. If cookie state is written into a cookie jar file that is later read back and used for subsequent requests, a malicious HTTP server can inject new cookies for arbitrary domains into said cookie jar.
- Actualiza a 7.49.1-r4
Publicación ActualizaciónALPINE-CVE-2016-8621
The `curl_getdate` function in curl before version 7.51.0 is vulnerable to an out of bounds read if it receives an input with one digit short.
- Actualiza a 7.49.1-r4
Publicación ActualizaciónALPINE-CVE-2016-8617
The base64 encode function in curl before version 7.51.0 is prone to a buffer being under allocated in 32bit systems if it receives at least 1Gb as input via `CURLOPT_USERNAME`.
- Actualiza a 7.49.1-r4
Publicación ActualizaciónALPINE-CVE-2016-8624
curl before version 7.51.0 doesn't parse the authority component of the URL correctly when the host name part ends with a '#' character, and could instead be tricked into connecting to a different host. This may have security implications if you for example use an URL parser that follows the RFC to check for allowed domains before using curl to request them.
- Actualiza a 7.49.1-r4
Publicación ActualizaciónALPINE-CVE-2016-8622
The URL percent-encoding decode function in libcurl before 7.51.0 is called `curl_easy_unescape`. Internally, even if this function would be made to allocate a unscape destination buffer larger than 2GB, it would return that new length in a signed 32 bit integer variable, thus the length would get either just truncated or both truncated and turned negative. That could then lead to libcurl writing outside of its heap based buffer.
- Actualiza a 7.49.1-r4
Publicación ActualizaciónALPINE-CVE-2016-8618
The libcurl API function called `curl_maprintf()` before version 7.51.0 can be tricked into doing a double-free due to an unsafe `size_t` multiplication, on systems using 32 bit `size_t` variables.
- Actualiza a 7.49.1-r4
Publicación ActualizaciónALPINE-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).
- Actualiza a 7.52.1-r1
Publicación ActualizaciónALPINE-CVE-2017-7468
In curl and libcurl 7.52.0 to and including 7.53.1, libcurl would attempt to resume a TLS session even if the client certificate had changed. That is unacceptable since a server by specification is allowed to skip the client certificate check on resume, and may instead use the old identity which was established by the previous certificate (or no certificate). libcurl supports by default the use of TLS session id/ticket to resume previous TLS sessions to speed up subsequent TLS handshakes. They are used when for any reason an existing TLS connection couldn't be kept alive to make the next handshake faster. This flaw is a regression and identic
- Actualiza a 7.52.1-r1
Publicación ActualizaciónALPINE-CVE-2016-9594
curl before version 7.52.1 is vulnerable to an uninitialized random in libcurl's internal function that returns a good 32bit random value. Having a weak or virtually non-existent random value makes the operations that use it vulnerable.
- Actualiza a 7.52.1-r0
Publicación ActualizaciónALPINE-CVE-2016-9586
curl before version 7.52.0 is vulnerable to a buffer overflow when doing a large floating point output in libcurl's implementation of the printf() functions. If there are any application that accepts a format string from the outside without necessary input filtering, it could allow remote attacks.
- Actualiza a 7.52.1-r0
Publicación ActualizaciónALPINE-CVE-2016-9953
The verify_certificate function in lib/vtls/schannel.c in libcurl 7.30.0 through 7.51.0, when built for Windows CE using the schannel TLS backend, allows remote attackers to obtain sensitive information, cause a denial of service (crash), or possibly have unspecified other impact via a wildcard certificate name, which triggers an out-of-bounds read.
- Actualiza a 7.52.1-r0
Publicación ActualizaciónALPINE-CVE-2016-9952
The verify_certificate function in lib/vtls/schannel.c in libcurl 7.30.0 through 7.51.0, when built for Windows CE using the schannel TLS backend, makes it easier for remote attackers to conduct man-in-the-middle attacks via a crafted wildcard SAN in a server certificate, as demonstrated by "*.com."
- Actualiza a 7.52.1-r0
Publicación ActualizaciónALPINE-CVE-2017-1000257
An IMAP FETCH response line indicates the size of the returned data, in number of bytes. When that response says the data is zero bytes, libcurl would pass on that (non-existing) data with a pointer and the size (zero) to the deliver-data function. libcurl's deliver-data function treats zero as a magic number and invokes strlen() on the data to figure out the length. The strlen() is called on a heap based buffer that might not be zero terminated so libcurl might read beyond the end of it into whatever memory lies after (or just crash) and then deliver that to the application as if it was actually downloaded.
- Actualiza a 7.55.0-r2
Publicación ActualizaciónALPINE-CVE-2017-1000254
libcurl may read outside of a heap allocated buffer when doing FTP. When libcurl connects to an FTP server and successfully logs in (anonymous or not), it asks the server for the current directory with the `PWD` command. The server then responds with a 257 response containing the path, inside double quotes. The returned path name is then kept by libcurl for subsequent uses. Due to a flaw in the string parser for this directory name, a directory name passed like this but without a closing double quote would lead to libcurl not adding a trailing NUL byte to the buffer holding the name. When libcurl would then later access the string, it could r
- Actualiza a 7.55.0-r1
Publicación ActualizaciónALPINE-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`.
- Actualiza a 7.55.0-r0
Publicación ActualizaciónALPINE-CVE-2017-1000100
When doing a TFTP transfer and curl/libcurl is given a URL that contains a very long file name (longer than about 515 bytes), the file name is truncated to fit within the buffer boundaries, but the buffer size is still wrongly updated to use the untruncated length. This too large value is then used in the sendto() call, making curl attempt to send more data than what is actually put into the buffer. The endto() function will then read beyond the end of the heap based buffer. A malicious HTTP(S) server could redirect a vulnerable libcurl-using client to a crafted TFTP URL (if the client hasn't restricted which protocols it allows redirects to)
- Actualiza a 7.55.0-r0
Publicación Actualización
Comprueba tu servidor
Compara tu pila y las versiones instaladas con las bases actuales de vulnerabilidades.