| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| OpenSSL 0.9.6 before 0.9.6d does not properly handle unknown message types, which allows remote attackers to cause a denial of service (infinite loop), as demonstrated using the Codenomicon TLS Test Tool. |
| The ASN1 library in OpenSSL 0.9.6d and earlier, and 0.9.7-beta2 and earlier, allows remote attackers to cause a denial of service via invalid encodings. |
| OpenSSL 0.9.6 and 0.9.7 does not properly track the number of characters in certain ASN.1 inputs, which allows remote attackers to cause a denial of service (crash) via an SSL client certificate that causes OpenSSL to read past the end of a buffer when the long form is used. |
| The SSL/TLS handshaking code in OpenSSL 0.9.7a, 0.9.7b, and 0.9.7c, when using Kerberos ciphersuites, does not properly check the length of Kerberos tickets during a handshake, which allows remote attackers to cause a denial of service (crash) via a crafted SSL/TLS handshake that causes an out-of-bounds read. |
| OpenSSL does not use RSA blinding by default, which allows local and remote attackers to obtain the server's private key by determining factors using timing differences on (1) the number of extra reductions during Montgomery reduction, and (2) the use of different integer multiplication algorithms ("Karatsuba" and normal). |
| OpenSSL 0.9.6e uses assertions when detecting buffer overflow attacks instead of less severe mechanisms, which allows remote attackers to cause a denial of service (crash) via certain messages that cause OpenSSL to abort from a failed assertion, as demonstrated using SSLv2 CLIENT_MASTER_KEY messages, which are not properly handled in s2_srvr.c. |
| Buffer overflows in OpenSSL 0.9.6d and earlier, and 0.9.7-beta2 and earlier, allow remote attackers to execute arbitrary code via (1) a large client master key in SSL2 or (2) a large session ID in SSL3. |
| OpenSSL 0.9.6k allows remote attackers to cause a denial of service (crash via large recursion) via malformed ASN.1 sequences. |
| Integer overflow in OpenSSL 0.9.6 and 0.9.7 allows remote attackers to cause a denial of service (crash) via an SSL client certificate with certain ASN.1 tag values. |
| The SSL and TLS components for OpenSSL 0.9.6i and earlier, 0.9.7, and 0.9.7a allow remote attackers to perform an unauthorized RSA private key operation via a modified Bleichenbacher attack that uses a large number of SSL or TLS connections using PKCS #1 v1.5 padding that cause OpenSSL to leak information regarding the relationship between ciphertext and the associated plaintext, aka the "Klima-Pokorny-Rosa attack." |
| The do_change_cipher_spec function in OpenSSL 0.9.6c to 0.9.6k, and 0.9.7a to 0.9.7c, allows remote attackers to cause a denial of service (crash) via a crafted SSL/TLS handshake that triggers a null dereference. |
| OpenSSL before 0.9.7, 0.9.7 before 0.9.7k, and 0.9.8 before 0.9.8c, when using an RSA key with exponent 3, removes PKCS-1 padding before generating a hash, which allows remote attackers to forge a PKCS #1 v1.5 signature that is signed by that RSA key and prevents OpenSSL from correctly verifying X.509 and other certificates that use PKCS #1. |
| The der_chop script in the openssl package in Trustix Secure Linux 1.5 through 2.1 and other operating systems allows local users to overwrite files via a symlink attack on temporary files. |
| A read buffer overrun can be triggered in X.509 certificate verification,
specifically in name constraint checking. Note that this occurs
after certificate chain signature verification and requires either a
CA to have signed the malicious certificate or for the application to
continue certificate verification despite failure to construct a path
to a trusted issuer.
The read buffer overrun might result in a crash which could lead to
a denial of service attack. In theory it could also result in the disclosure
of private memory contents (such as private keys, or sensitive plaintext)
although we are not aware of any working exploit leading to memory
contents disclosure as of the time of release of this advisory.
In a TLS client, this can be triggered by connecting to a malicious
server. In a TLS server, this can be triggered if the server requests
client authentication and a malicious client connects. |
| Issue summary: Processing some specially crafted ASN.1 object identifiers or
data containing them may be very slow.
Impact summary: Applications that use OBJ_obj2txt() directly, or use any of
the OpenSSL subsystems OCSP, PKCS7/SMIME, CMS, CMP/CRMF or TS with no message
size limit may experience notable to very long delays when processing those
messages, which may lead to a Denial of Service.
An OBJECT IDENTIFIER is composed of a series of numbers - sub-identifiers -
most of which have no size limit. OBJ_obj2txt() may be used to translate
an ASN.1 OBJECT IDENTIFIER given in DER encoding form (using the OpenSSL
type ASN1_OBJECT) to its canonical numeric text form, which are the
sub-identifiers of the OBJECT IDENTIFIER in decimal form, separated by
periods.
When one of the sub-identifiers in the OBJECT IDENTIFIER is very large
(these are sizes that are seen as absurdly large, taking up tens or hundreds
of KiBs), the translation to a decimal number in text may take a very long
time. The time complexity is O(n^2) with 'n' being the size of the
sub-identifiers in bytes (*).
With OpenSSL 3.0, support to fetch cryptographic algorithms using names /
identifiers in string form was introduced. This includes using OBJECT
IDENTIFIERs in canonical numeric text form as identifiers for fetching
algorithms.
Such OBJECT IDENTIFIERs may be received through the ASN.1 structure
AlgorithmIdentifier, which is commonly used in multiple protocols to specify
what cryptographic algorithm should be used to sign or verify, encrypt or
decrypt, or digest passed data.
Applications that call OBJ_obj2txt() directly with untrusted data are
affected, with any version of OpenSSL. If the use is for the mere purpose
of display, the severity is considered low.
In OpenSSL 3.0 and newer, this affects the subsystems OCSP, PKCS7/SMIME,
CMS, CMP/CRMF or TS. It also impacts anything that processes X.509
certificates, including simple things like verifying its signature.
The impact on TLS is relatively low, because all versions of OpenSSL have a
100KiB limit on the peer's certificate chain. Additionally, this only
impacts clients, or servers that have explicitly enabled client
authentication.
In OpenSSL 1.1.1 and 1.0.2, this only affects displaying diverse objects,
such as X.509 certificates. This is assumed to not happen in such a way
that it would cause a Denial of Service, so these versions are considered
not affected by this issue in such a way that it would be cause for concern,
and the severity is therefore considered low. |
| The function X509_VERIFY_PARAM_add0_policy() is documented to
implicitly enable the certificate policy check when doing certificate
verification. However the implementation of the function does not
enable the check which allows certificates with invalid or incorrect
policies to pass the certificate verification.
As suddenly enabling the policy check could break existing deployments it was
decided to keep the existing behavior of the X509_VERIFY_PARAM_add0_policy()
function.
Instead the applications that require OpenSSL to perform certificate
policy check need to use X509_VERIFY_PARAM_set1_policies() or explicitly
enable the policy check by calling X509_VERIFY_PARAM_set_flags() with
the X509_V_FLAG_POLICY_CHECK flag argument.
Certificate policy checks are disabled by default in OpenSSL and are not
commonly used by applications. |
| Applications that use a non-default option when verifying certificates may be
vulnerable to an attack from a malicious CA to circumvent certain checks.
Invalid certificate policies in leaf certificates are silently ignored by
OpenSSL and other certificate policy checks are skipped for that certificate.
A malicious CA could use this to deliberately assert invalid certificate policies
in order to circumvent policy checking on the certificate altogether.
Policy processing is disabled by default but can be enabled by passing
the `-policy' argument to the command line utilities or by calling the
`X509_VERIFY_PARAM_set1_policies()' function. |
| Issue summary: The AES-XTS cipher decryption implementation for 64 bit ARM
platform contains a bug that could cause it to read past the input buffer,
leading to a crash.
Impact summary: Applications that use the AES-XTS algorithm on the 64 bit ARM
platform can crash in rare circumstances. The AES-XTS algorithm is usually
used for disk encryption.
The AES-XTS cipher decryption implementation for 64 bit ARM platform will read
past the end of the ciphertext buffer if the ciphertext size is 4 mod 5 in 16
byte blocks, e.g. 144 bytes or 1024 bytes. If the memory after the ciphertext
buffer is unmapped, this will trigger a crash which results in a denial of
service.
If an attacker can control the size and location of the ciphertext buffer
being decrypted by an application using AES-XTS on 64 bit ARM, the
application is affected. This is fairly unlikely making this issue
a Low severity one. |
| Issue summary: Checking excessively long DSA keys or parameters may be very
slow.
Impact summary: Applications that use the functions EVP_PKEY_param_check()
or EVP_PKEY_public_check() to check a DSA public key or DSA parameters may
experience long delays. Where the key or parameters that are being checked
have been obtained from an untrusted source this may lead to a Denial of
Service.
The functions EVP_PKEY_param_check() or EVP_PKEY_public_check() perform
various checks on DSA parameters. Some of those computations take a long time
if the modulus (`p` parameter) is too large.
Trying to use a very large modulus is slow and OpenSSL will not allow using
public keys with a modulus which is over 10,000 bits in length for signature
verification. However the key and parameter check functions do not limit
the modulus size when performing the checks.
An application that calls EVP_PKEY_param_check() or EVP_PKEY_public_check()
and supplies a key or parameters obtained from an untrusted source could be
vulnerable to a Denial of Service attack.
These functions are not called by OpenSSL itself on untrusted DSA keys so
only applications that directly call these functions may be vulnerable.
Also vulnerable are the OpenSSL pkey and pkeyparam command line applications
when using the `-check` option.
The OpenSSL SSL/TLS implementation is not affected by this issue.
The OpenSSL 3.0 and 3.1 FIPS providers are affected by this issue. |
| Issue summary: Generating excessively long X9.42 DH keys or checking
excessively long X9.42 DH keys or parameters may be very slow.
Impact summary: Applications that use the functions DH_generate_key() to
generate an X9.42 DH key may experience long delays. Likewise, applications
that use DH_check_pub_key(), DH_check_pub_key_ex() or EVP_PKEY_public_check()
to check an X9.42 DH key or X9.42 DH parameters may experience long delays.
Where the key or parameters that are being checked have been obtained from
an untrusted source this may lead to a Denial of Service.
While DH_check() performs all the necessary checks (as of CVE-2023-3817),
DH_check_pub_key() doesn't make any of these checks, and is therefore
vulnerable for excessively large P and Q parameters.
Likewise, while DH_generate_key() performs a check for an excessively large
P, it doesn't check for an excessively large Q.
An application that calls DH_generate_key() or DH_check_pub_key() and
supplies a key or parameters obtained from an untrusted source could be
vulnerable to a Denial of Service attack.
DH_generate_key() and DH_check_pub_key() are also called by a number of
other OpenSSL functions. An application calling any of those other
functions may similarly be affected. The other functions affected by this
are DH_check_pub_key_ex(), EVP_PKEY_public_check(), and EVP_PKEY_generate().
Also vulnerable are the OpenSSL pkey command line application when using the
"-pubcheck" option, as well as the OpenSSL genpkey command line application.
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 issue. |
