nscd: Stack-based buffer overflow in netgroup cache
If the Name Service Cache Daemon's (nscd) fixed size cache is exhausted
by client requests then a subsequent client request for netgroup data
may result in a stack-based buffer overflow. This flaw was introduced
in glibc 2.15 when the cache was added to nscd.
This vulnerability is only present in the nscd binary.
nscd: Null pointer crashes after notfound response
If the Name Service Cache Daemon's (nscd) cache fails to add a not-found
netgroup response to the cache, the client request can result in a null
pointer dereference. This flaw was introduced in glibc 2.15 when the
cache was added to nscd.
This vulnerability is only present in the nscd binary.
nscd: netgroup cache may terminate daemon on memory allocation failure
The Name Service Cache Daemon's (nscd) netgroup cache uses xmalloc or
xrealloc and these functions may terminate the process due to a memory
allocation failure resulting in a denial of service to the clients. The
flaw was introduced in glibc 2.15 when the cache was added to nscd.
This vulnerability is only present in the nscd binary.
nscd: netgroup cache assumes NSS callback uses in-buffer strings
The Name Service Cache Daemon's (nscd) netgroup cache can corrupt memory
when the NSS callback does not store all strings in the provided buffer.
The flaw was introduced in glibc 2.15 when the cache was added to nscd.
This vulnerability is only present in the nscd binary.
When a protocol selection parameter option disables all protocols without adding any then the default set of protocols would remain in the allowed set due to an error in the logic for removing protocols. The below command would perform a request to curl.se with a plaintext protocol which has been explicitly disabled. curl --proto -all,-http http://curl.se The flaw is only present if the set of selected protocols disables the entire set of available protocols, in itself a command with no practical use and therefore unlikely to be encountered in real situations. The curl security team has thus assessed this to be low severity bug.
libcurl skips the certificate verification for a QUIC connection under certain conditions, when built to use wolfSSL. If told to use an unknown/bad cipher or curve, the error path accidentally skips the verification and returns OK, thus ignoring any certificate problems.
When an application tells libcurl it wants to allow HTTP/2 server push, and the amount of received headers for the push surpasses the maximum allowed limit (1000), libcurl aborts the server push. When aborting, libcurl inadvertently does not free all the previously allocated headers and instead leaks the memory. Further, this error condition fails silently and is therefore not easily detected by an application.
libcurl did not check the server certificate of TLS connections done to a host specified as an IP address, when built to use mbedTLS. libcurl would wrongly avoid using the set hostname function when the specified hostname was given as an IP address, therefore completely skipping the certificate check. This affects all uses of TLS protocols (HTTPS, FTPS, IMAPS, POPS3, SMTPS, etc).
libexpat through 2.6.1 allows an XML Entity Expansion attack when there is isolated use of external parsers (created via XML_ExternalEntityParserCreate).
Issue summary: A bug has been identified in the processing of key and
initialisation vector (IV) lengths. This can lead to potential truncation
or overruns during the initialisation of some symmetric ciphers.
Impact summary: A truncation in the IV can result in non-uniqueness,
which could result in loss of confidentiality for some cipher modes.
When calling EVP_EncryptInit_ex2(), EVP_DecryptInit_ex2() or
EVP_CipherInit_ex2() the provided OSSL_PARAM array is processed after
the key and IV have been established. Any alterations to the key length,
via the "keylen" parameter or the IV length, via the "ivlen" parameter,
within the OSSL_PARAM array will not take effect as intended, potentially
causing truncation or overreading of these values. The following ciphers
and cipher modes are impacted: RC2, RC4, RC5, CCM, GCM and OCB.
For the CCM, GCM and OCB cipher modes, truncation of the IV can result in
loss of confidentiality. For example, when following NIST's SP 800-38D
section 8.2.1 guidance for constructing a deterministic IV for AES in
GCM mode, truncation of the counter portion could lead to IV reuse.
Both truncations and overruns of the key and overruns of the IV will
produce incorrect results and could, in some cases, trigger a memory
exception. However, these issues are not currently assessed as security
critical.
Changing the key and/or IV lengths is not considered to be a common operation
and the vulnerable API was recently introduced. Furthermore it is likely that
application developers will have spotted this problem during testing since
decryption would fail unless both peers in the communication were similarly
vulnerable. For these reasons we expect the probability of an application being
vulnerable to this to be quite low. However if an application is vulnerable then
this issue is considered very serious. For these reasons we have assessed this
issue as Moderate severity overall.
The OpenSSL SSL/TLS implementation is not affected by this issue.
The OpenSSL 3.0 and 3.1 FIPS providers are not affected by this because
the issue lies outside of the FIPS provider boundary.
OpenSSL 3.1 and 3.0 are vulnerable to this issue.