dompurify is a DOM-only XSS sanitizer for HTML, MathML and SVG.
+
Affected versions of this package are vulnerable to Operator Precedence Logic Error in the form of short-circuit evaluation that gives precedence to ADD_TAGS over FORBID_TAGS in _sanitizeElements(). In an application where ADD_TAGS is used as a function (via EXTRA_ELEMENT_HANDLING.tagCheck) and FORBID_TAGS is in use, an attacker can cause forbidden tags to be allowed.
Note:Versions mentioned in the description apply only to the upstream openssl package and not the openssl package as distributed by Alpine.
+ See How to fix? for Alpine:3.23 relevant fixed versions and status.
+
Issue summary: During processing of a crafted CMS EnvelopedData message
+ with KeyTransportRecipientInfo a NULL pointer dereference can happen.
+
Impact summary: Applications that process attacker-controlled CMS data may
+ crash before authentication or cryptographic operations occur resulting in
+ Denial of Service.
+
When a CMS EnvelopedData message that uses KeyTransportRecipientInfo with
+ RSA-OAEP encryption is processed, the optional parameters field of
+ RSA-OAEP SourceFunc algorithm identifier is examined without checking
+ for its presence. This results in a NULL pointer dereference if the field
+ is missing.
+
Applications and services that call CMS_decrypt() on untrusted input
+ (e.g., S/MIME processing or CMS-based protocols) are vulnerable.
+
The FIPS modules in 3.6, 3.5, 3.4, 3.3 and 3.0 are not affected by this
+ issue, as the affected code is outside the OpenSSL FIPS module boundary.
+
Remediation
+
Upgrade Alpine:3.23openssl to version 3.5.6-r0 or higher.
Note:Versions mentioned in the description apply only to the upstream openssl package and not the openssl package as distributed by Alpine.
+ See How to fix? for Alpine:3.23 relevant fixed versions and status.
+
Issue summary: When a delta CRL that contains a Delta CRL Indicator extension
+ is processed a NULL pointer dereference might happen if the required CRL
+ Number extension is missing.
+
Impact summary: A NULL pointer dereference can trigger a crash which
+ leads to a Denial of Service for an application.
+
When CRL processing and delta CRL processing is enabled during X.509
+ certificate verification, the delta CRL processing does not check
+ whether the CRL Number extension is NULL before dereferencing it.
+ When a malformed delta CRL file is being processed, this parameter
+ can be NULL, causing a NULL pointer dereference.
+
Exploiting this issue requires the X509_V_FLAG_USE_DELTAS flag to be enabled in
+ the verification context, the certificate being verified to contain a
+ freshestCRL extension or the base CRL to have the EXFLAG_FRESHEST flag set, and
+ an attacker to provide a malformed CRL to an application that processes it.
+
The vulnerability is limited to Denial of Service and cannot be escalated to
+ achieve code execution or memory disclosure. For that reason the issue was
+ assessed as Low severity according to our Security Policy.
+
The FIPS modules in 3.6, 3.5, 3.4, 3.3 and 3.0 are not affected by this issue,
+ as the affected code is outside the OpenSSL FIPS module boundary.
+
Remediation
+
Upgrade Alpine:3.23openssl to version 3.5.6-r0 or higher.
Note:Versions mentioned in the description apply only to the upstream openssl package and not the openssl package as distributed by Alpine.
+ See How to fix? for Alpine:3.23 relevant fixed versions and status.
+
Issue summary: During processing of a crafted CMS EnvelopedData message
+ with KeyAgreeRecipientInfo a NULL pointer dereference can happen.
+
Impact summary: Applications that process attacker-controlled CMS data may
+ crash before authentication or cryptographic operations occur resulting in
+ Denial of Service.
+
When a CMS EnvelopedData message that uses KeyAgreeRecipientInfo is
+ processed, the optional parameters field of KeyEncryptionAlgorithmIdentifier
+ is examined without checking for its presence. This results in a NULL
+ pointer dereference if the field is missing.
+
Applications and services that call CMS_decrypt() on untrusted input
+ (e.g., S/MIME processing or CMS-based protocols) are vulnerable.
+
The FIPS modules in 3.6, 3.5, 3.4, 3.3 and 3.0 are not affected by this
+ issue, as the affected code is outside the OpenSSL FIPS module boundary.
+
Remediation
+
Upgrade Alpine:3.23openssl to version 3.5.6-r0 or higher.
Note:Versions mentioned in the description apply only to the upstream openssl package and not the openssl package as distributed by Alpine.
+ See How to fix? for Alpine:3.23 relevant fixed versions and status.
+
Issue summary: An OpenSSL TLS 1.3 server may fail to negotiate the expected
+ preferred key exchange group when its key exchange group configuration includes
+ the default by using the 'DEFAULT' keyword.
+
Impact summary: A less preferred key exchange may be used even when a more
+ preferred group is supported by both client and server, if the group
+ was not included among the client's initial predicated keyshares.
+ This will sometimes be the case with the new hybrid post-quantum groups,
+ if the client chooses to defer their use until specifically requested by
+ the server.
+
If an OpenSSL TLS 1.3 server's configuration uses the 'DEFAULT' keyword to
+ interpolate the built-in default group list into its own configuration, perhaps
+ adding or removing specific elements, then an implementation defect causes the
+ 'DEFAULT' list to lose its 'tuple' structure, and all server-supported groups
+ were treated as a single sufficiently secure 'tuple', with the server not
+ sending a Hello Retry Request (HRR) even when a group in a more preferred tuple
+ was mutually supported.
+
As a result, the client and server might fail to negotiate a mutually supported
+ post-quantum key agreement group, such as 'X25519MLKEM768', if the client's
+ configuration results in only 'classical' groups (such as 'X25519' being the
+ only ones in the client's initial keyshare prediction).
+
OpenSSL 3.5 and later support a new syntax for selecting the most preferred TLS
+ 1.3 key agreement group on TLS servers. The old syntax had a single 'flat'
+ list of groups, and treated all the supported groups as sufficiently secure.
+ If any of the keyshares predicted by the client were supported by the server
+ the most preferred among these was selected, even if other groups supported by
+ the client, but not included in the list of predicted keyshares would have been
+ more preferred, if included.
+
The new syntax partitions the groups into distinct 'tuples' of roughly
+ equivalent security. Within each tuple the most preferred group included among
+ the client's predicted keyshares is chosen, but if the client supports a group
+ from a more preferred tuple, but did not predict any corresponding keyshares,
+ the server will ask the client to retry the ClientHello (by issuing a Hello
+ Retry Request or HRR) with the most preferred mutually supported group.
+
The above works as expected when the server's configuration uses the built-in
+ default group list, or explicitly defines its own list by directly defining the
+ various desired groups and group 'tuples'.
+
No OpenSSL FIPS modules are affected by this issue, the code in question lies
+ outside the FIPS boundary.
+
OpenSSL 3.6 and 3.5 are vulnerable to this issue.
+
OpenSSL 3.6 users should upgrade to OpenSSL 3.6.2 once it is released.
+ OpenSSL 3.5 users should upgrade to OpenSSL 3.5.6 once it is released.
+
OpenSSL 3.4, 3.3, 3.0, 1.0.2 and 1.1.1 are not affected by this issue.
+
Remediation
+
Upgrade Alpine:3.23openssl to version 3.5.6-r0 or higher.
Note:Versions mentioned in the description apply only to the upstream openssl package and not the openssl package as distributed by Alpine.
+ See How to fix? for Alpine:3.23 relevant fixed versions and status.
+
Issue summary: Converting an excessively large OCTET STRING value to
+ a hexadecimal string leads to a heap buffer overflow on 32 bit platforms.
+
Impact summary: A heap buffer overflow may lead to a crash or possibly
+ an attacker controlled code execution or other undefined behavior.
+
If an attacker can supply a crafted X.509 certificate with an excessively
+ large OCTET STRING value in extensions such as the Subject Key Identifier
+ (SKID) or Authority Key Identifier (AKID) which are being converted to hex,
+ the size of the buffer needed for the result is calculated as multiplication
+ of the input length by 3. On 32 bit platforms, this multiplication may overflow
+ resulting in the allocation of a smaller buffer and a heap buffer overflow.
+
Applications and services that print or log contents of untrusted X.509
+ certificates are vulnerable to this issue. As the certificates would have
+ to have sizes of over 1 Gigabyte, printing or logging such certificates
+ is a fairly unlikely operation and only 32 bit platforms are affected,
+ this issue was assigned Low severity.
+
The FIPS modules in 3.6, 3.5, 3.4, 3.3 and 3.0 are not affected by this
+ issue, as the affected code is outside the OpenSSL FIPS module boundary.
+
Remediation
+
Upgrade Alpine:3.23openssl to version 3.5.6-r0 or higher.
Note:Versions mentioned in the description apply only to the upstream openssl package and not the openssl package as distributed by Alpine.
+ See How to fix? for Alpine:3.23 relevant fixed versions and status.
+
Issue summary: An uncommon configuration of clients performing DANE TLSA-based
+ server authentication, when paired with uncommon server DANE TLSA records, may
+ result in a use-after-free and/or double-free on the client side.
+
Impact summary: A use after free can have a range of potential consequences
+ such as the corruption of valid data, crashes or execution of arbitrary code.
+
However, the issue only affects clients that make use of TLSA records with both
+ the PKIX-TA(0/PKIX-EE(1) certificate usages and the DANE-TA(2) certificate
+ usage.
+
By far the most common deployment of DANE is in SMTP MTAs for which RFC7672
+ recommends that clients treat as 'unusable' any TLSA records that have the PKIX
+ certificate usages. These SMTP (or other similar) clients are not vulnerable
+ to this issue. Conversely, any clients that support only the PKIX usages, and
+ ignore the DANE-TA(2) usage are also not vulnerable.
+
The client would also need to be communicating with a server that publishes a
+ TLSA RRset with both types of TLSA records.
+
No FIPS modules are affected by this issue, the problem code is outside the
+ FIPS module boundary.
+
Remediation
+
Upgrade Alpine:3.23openssl to version 3.5.6-r0 or higher.
Note:Versions mentioned in the description apply only to the upstream openssl package and not the openssl package as distributed by Alpine.
+ See How to fix? for Alpine:3.23 relevant fixed versions and status.
+
Issue summary: Applications using RSASVE key encapsulation to establish
+ a secret encryption key can send contents of an uninitialized memory buffer to
+ a malicious peer.
+
Impact summary: The uninitialized buffer might contain sensitive data from the
+ previous execution of the application process which leads to sensitive data
+ leakage to an attacker.
+
RSA_public_encrypt() returns the number of bytes written on success and -1
+ on error. The affected code tests only whether the return value is non-zero.
+ As a result, if RSA encryption fails, encapsulation can still return success to
+ the caller, set the output lengths, and leave the caller to use the contents of
+ the ciphertext buffer as if a valid KEM ciphertext had been produced.
+
If applications use EVP_PKEY_encapsulate() with RSA/RSASVE on an
+ attacker-supplied invalid RSA public key without first validating that key,
+ then this may cause stale or uninitialized contents of the caller-provided
+ ciphertext buffer to be disclosed to the attacker in place of the KEM
+ ciphertext.
+
As a workaround calling EVP_PKEY_public_check() or
+ EVP_PKEY_public_check_quick() before EVP_PKEY_encapsulate() will mitigate
+ the issue.
+
The FIPS modules in 3.6, 3.5, 3.4, 3.3, 3.1 and 3.0 are affected by this issue.
+
Remediation
+
Upgrade Alpine:3.23openssl to version 3.5.6-r0 or higher.
Note:Versions mentioned in the description apply only to the upstream musl package and not the musl package as distributed by Alpine.
+ See How to fix? for Alpine:3.23 relevant fixed versions and status.
+
An issue was discovered in musl libc 0.7.10 through 1.2.6. Stack-based memory corruption can occur during qsort of very large arrays, due to incorrectly implemented double-word primitives. The number of elements must exceed about seven million, i.e., the 32nd Leonardo number on 32-bit platforms (or the 64th Leonardo number on 64-bit platforms, which is not practical).
+
Remediation
+
Upgrade Alpine:3.23musl to version 1.2.5-r23 or higher.
Note:Versions mentioned in the description apply only to the upstream musl package and not the musl package as distributed by Alpine.
+ See How to fix? for Alpine:3.23 relevant fixed versions and status.
+
A security flaw has been discovered in musl libc up to 1.2.6. Affected is the function iconv of the file src/locale/iconv.c of the component GB18030 4-byte Decoder. Performing a manipulation results in inefficient algorithmic complexity. The attack must be initiated from a local position. To fix this issue, it is recommended to deploy a patch.
+
Remediation
+
Upgrade Alpine:3.23musl to version 1.2.5-r22 or higher.
Note:Versions mentioned in the description apply only to the upstream zlib package and not the zlib package as distributed by Alpine.
+ See How to fix? for Alpine:3.21 relevant fixed versions and status.
+
zlib before 1.3.2 allows CPU consumption via crc32_combine64 and crc32_combine_gen64 because x2nmodp can do right shifts within a loop that has no termination condition.
+
Remediation
+
Upgrade Alpine:3.21zlib to version 1.3.2-r0 or higher.
Note:Versions mentioned in the description apply only to the upstream openssl package and not the openssl package as distributed by Alpine.
+ See How to fix? for Alpine:3.21 relevant fixed versions and status.
+
Issue summary: Converting an excessively large OCTET STRING value to
+ a hexadecimal string leads to a heap buffer overflow on 32 bit platforms.
+
Impact summary: A heap buffer overflow may lead to a crash or possibly
+ an attacker controlled code execution or other undefined behavior.
+
If an attacker can supply a crafted X.509 certificate with an excessively
+ large OCTET STRING value in extensions such as the Subject Key Identifier
+ (SKID) or Authority Key Identifier (AKID) which are being converted to hex,
+ the size of the buffer needed for the result is calculated as multiplication
+ of the input length by 3. On 32 bit platforms, this multiplication may overflow
+ resulting in the allocation of a smaller buffer and a heap buffer overflow.
+
Applications and services that print or log contents of untrusted X.509
+ certificates are vulnerable to this issue. As the certificates would have
+ to have sizes of over 1 Gigabyte, printing or logging such certificates
+ is a fairly unlikely operation and only 32 bit platforms are affected,
+ this issue was assigned Low severity.
+
The FIPS modules in 3.6, 3.5, 3.4, 3.3 and 3.0 are not affected by this
+ issue, as the affected code is outside the OpenSSL FIPS module boundary.
+
Remediation
+
Upgrade Alpine:3.21openssl to version 3.3.7-r0 or higher.
Note:Versions mentioned in the description apply only to the upstream openssl package and not the openssl package as distributed by Alpine.
+ See How to fix? for Alpine:3.21 relevant fixed versions and status.
+
Issue summary: During processing of a crafted CMS EnvelopedData message
+ with KeyTransportRecipientInfo a NULL pointer dereference can happen.
+
Impact summary: Applications that process attacker-controlled CMS data may
+ crash before authentication or cryptographic operations occur resulting in
+ Denial of Service.
+
When a CMS EnvelopedData message that uses KeyTransportRecipientInfo with
+ RSA-OAEP encryption is processed, the optional parameters field of
+ RSA-OAEP SourceFunc algorithm identifier is examined without checking
+ for its presence. This results in a NULL pointer dereference if the field
+ is missing.
+
Applications and services that call CMS_decrypt() on untrusted input
+ (e.g., S/MIME processing or CMS-based protocols) are vulnerable.
+
The FIPS modules in 3.6, 3.5, 3.4, 3.3 and 3.0 are not affected by this
+ issue, as the affected code is outside the OpenSSL FIPS module boundary.
+
Remediation
+
Upgrade Alpine:3.21openssl to version 3.3.7-r0 or higher.
Note:Versions mentioned in the description apply only to the upstream openssl package and not the openssl package as distributed by Alpine.
+ See How to fix? for Alpine:3.21 relevant fixed versions and status.
+
Issue summary: During processing of a crafted CMS EnvelopedData message
+ with KeyAgreeRecipientInfo a NULL pointer dereference can happen.
+
Impact summary: Applications that process attacker-controlled CMS data may
+ crash before authentication or cryptographic operations occur resulting in
+ Denial of Service.
+
When a CMS EnvelopedData message that uses KeyAgreeRecipientInfo is
+ processed, the optional parameters field of KeyEncryptionAlgorithmIdentifier
+ is examined without checking for its presence. This results in a NULL
+ pointer dereference if the field is missing.
+
Applications and services that call CMS_decrypt() on untrusted input
+ (e.g., S/MIME processing or CMS-based protocols) are vulnerable.
+
The FIPS modules in 3.6, 3.5, 3.4, 3.3 and 3.0 are not affected by this
+ issue, as the affected code is outside the OpenSSL FIPS module boundary.
+
Remediation
+
Upgrade Alpine:3.21openssl to version 3.3.7-r0 or higher.
Note:Versions mentioned in the description apply only to the upstream openssl package and not the openssl package as distributed by Alpine.
+ See How to fix? for Alpine:3.21 relevant fixed versions and status.
+
Issue summary: When a delta CRL that contains a Delta CRL Indicator extension
+ is processed a NULL pointer dereference might happen if the required CRL
+ Number extension is missing.
+
Impact summary: A NULL pointer dereference can trigger a crash which
+ leads to a Denial of Service for an application.
+
When CRL processing and delta CRL processing is enabled during X.509
+ certificate verification, the delta CRL processing does not check
+ whether the CRL Number extension is NULL before dereferencing it.
+ When a malformed delta CRL file is being processed, this parameter
+ can be NULL, causing a NULL pointer dereference.
+
Exploiting this issue requires the X509_V_FLAG_USE_DELTAS flag to be enabled in
+ the verification context, the certificate being verified to contain a
+ freshestCRL extension or the base CRL to have the EXFLAG_FRESHEST flag set, and
+ an attacker to provide a malformed CRL to an application that processes it.
+
The vulnerability is limited to Denial of Service and cannot be escalated to
+ achieve code execution or memory disclosure. For that reason the issue was
+ assessed as Low severity according to our Security Policy.
+
The FIPS modules in 3.6, 3.5, 3.4, 3.3 and 3.0 are not affected by this issue,
+ as the affected code is outside the OpenSSL FIPS module boundary.
+
Remediation
+
Upgrade Alpine:3.21openssl to version 3.3.7-r0 or higher.
Note:Versions mentioned in the description apply only to the upstream openssl package and not the openssl package as distributed by Alpine.
+ See How to fix? for Alpine:3.21 relevant fixed versions and status.
+
Issue summary: Applications using RSASVE key encapsulation to establish
+ a secret encryption key can send contents of an uninitialized memory buffer to
+ a malicious peer.
+
Impact summary: The uninitialized buffer might contain sensitive data from the
+ previous execution of the application process which leads to sensitive data
+ leakage to an attacker.
+
RSA_public_encrypt() returns the number of bytes written on success and -1
+ on error. The affected code tests only whether the return value is non-zero.
+ As a result, if RSA encryption fails, encapsulation can still return success to
+ the caller, set the output lengths, and leave the caller to use the contents of
+ the ciphertext buffer as if a valid KEM ciphertext had been produced.
+
If applications use EVP_PKEY_encapsulate() with RSA/RSASVE on an
+ attacker-supplied invalid RSA public key without first validating that key,
+ then this may cause stale or uninitialized contents of the caller-provided
+ ciphertext buffer to be disclosed to the attacker in place of the KEM
+ ciphertext.
+
As a workaround calling EVP_PKEY_public_check() or
+ EVP_PKEY_public_check_quick() before EVP_PKEY_encapsulate() will mitigate
+ the issue.
+
The FIPS modules in 3.6, 3.5, 3.4, 3.3, 3.1 and 3.0 are affected by this issue.
+
Remediation
+
Upgrade Alpine:3.21openssl to version 3.3.7-r0 or higher.
Note:Versions mentioned in the description apply only to the upstream openssl package and not the openssl package as distributed by Alpine.
+ See How to fix? for Alpine:3.21 relevant fixed versions and status.
+
Issue summary: An uncommon configuration of clients performing DANE TLSA-based
+ server authentication, when paired with uncommon server DANE TLSA records, may
+ result in a use-after-free and/or double-free on the client side.
+
Impact summary: A use after free can have a range of potential consequences
+ such as the corruption of valid data, crashes or execution of arbitrary code.
+
However, the issue only affects clients that make use of TLSA records with both
+ the PKIX-TA(0/PKIX-EE(1) certificate usages and the DANE-TA(2) certificate
+ usage.
+
By far the most common deployment of DANE is in SMTP MTAs for which RFC7672
+ recommends that clients treat as 'unusable' any TLSA records that have the PKIX
+ certificate usages. These SMTP (or other similar) clients are not vulnerable
+ to this issue. Conversely, any clients that support only the PKIX usages, and
+ ignore the DANE-TA(2) usage are also not vulnerable.
+
The client would also need to be communicating with a server that publishes a
+ TLSA RRset with both types of TLSA records.
+
No FIPS modules are affected by this issue, the problem code is outside the
+ FIPS module boundary.
+
Remediation
+
Upgrade Alpine:3.21openssl to version 3.3.7-r0 or higher.
Note:Versions mentioned in the description apply only to the upstream musl package and not the musl package as distributed by Alpine.
+ See How to fix? for Alpine:3.21 relevant fixed versions and status.
+
An issue was discovered in musl libc 0.7.10 through 1.2.6. Stack-based memory corruption can occur during qsort of very large arrays, due to incorrectly implemented double-word primitives. The number of elements must exceed about seven million, i.e., the 32nd Leonardo number on 32-bit platforms (or the 64th Leonardo number on 64-bit platforms, which is not practical).
+
Remediation
+
Upgrade Alpine:3.21musl to version 1.2.5-r11 or higher.
Note:Versions mentioned in the description apply only to the upstream musl package and not the musl package as distributed by Alpine.
+ See How to fix? for Alpine:3.21 relevant fixed versions and status.
+
A security flaw has been discovered in musl libc up to 1.2.6. Affected is the function iconv of the file src/locale/iconv.c of the component GB18030 4-byte Decoder. Performing a manipulation results in inefficient algorithmic complexity. The attack must be initiated from a local position. To fix this issue, it is recommended to deploy a patch.
+
Remediation
+
Upgrade Alpine:3.21musl to version 1.2.5-r10 or higher.
Note:Versions mentioned in the description apply only to the upstream zlib package and not the zlib package as distributed by Alpine.
+ See How to fix? for Alpine:3.22 relevant fixed versions and status.
+
zlib before 1.3.2 allows CPU consumption via crc32_combine64 and crc32_combine_gen64 because x2nmodp can do right shifts within a loop that has no termination condition.
+
Remediation
+
Upgrade Alpine:3.22zlib to version 1.3.2-r0 or higher.
Note:Versions mentioned in the description apply only to the upstream openssl package and not the openssl package as distributed by Alpine.
+ See How to fix? for Alpine:3.22 relevant fixed versions and status.
+
Issue summary: Converting an excessively large OCTET STRING value to
+ a hexadecimal string leads to a heap buffer overflow on 32 bit platforms.
+
Impact summary: A heap buffer overflow may lead to a crash or possibly
+ an attacker controlled code execution or other undefined behavior.
+
If an attacker can supply a crafted X.509 certificate with an excessively
+ large OCTET STRING value in extensions such as the Subject Key Identifier
+ (SKID) or Authority Key Identifier (AKID) which are being converted to hex,
+ the size of the buffer needed for the result is calculated as multiplication
+ of the input length by 3. On 32 bit platforms, this multiplication may overflow
+ resulting in the allocation of a smaller buffer and a heap buffer overflow.
+
Applications and services that print or log contents of untrusted X.509
+ certificates are vulnerable to this issue. As the certificates would have
+ to have sizes of over 1 Gigabyte, printing or logging such certificates
+ is a fairly unlikely operation and only 32 bit platforms are affected,
+ this issue was assigned Low severity.
+
The FIPS modules in 3.6, 3.5, 3.4, 3.3 and 3.0 are not affected by this
+ issue, as the affected code is outside the OpenSSL FIPS module boundary.
+
Remediation
+
Upgrade Alpine:3.22openssl to version 3.5.6-r0 or higher.
Note:Versions mentioned in the description apply only to the upstream openssl package and not the openssl package as distributed by Alpine.
+ See How to fix? for Alpine:3.22 relevant fixed versions and status.
+
Issue summary: An OpenSSL TLS 1.3 server may fail to negotiate the expected
+ preferred key exchange group when its key exchange group configuration includes
+ the default by using the 'DEFAULT' keyword.
+
Impact summary: A less preferred key exchange may be used even when a more
+ preferred group is supported by both client and server, if the group
+ was not included among the client's initial predicated keyshares.
+ This will sometimes be the case with the new hybrid post-quantum groups,
+ if the client chooses to defer their use until specifically requested by
+ the server.
+
If an OpenSSL TLS 1.3 server's configuration uses the 'DEFAULT' keyword to
+ interpolate the built-in default group list into its own configuration, perhaps
+ adding or removing specific elements, then an implementation defect causes the
+ 'DEFAULT' list to lose its 'tuple' structure, and all server-supported groups
+ were treated as a single sufficiently secure 'tuple', with the server not
+ sending a Hello Retry Request (HRR) even when a group in a more preferred tuple
+ was mutually supported.
+
As a result, the client and server might fail to negotiate a mutually supported
+ post-quantum key agreement group, such as 'X25519MLKEM768', if the client's
+ configuration results in only 'classical' groups (such as 'X25519' being the
+ only ones in the client's initial keyshare prediction).
+
OpenSSL 3.5 and later support a new syntax for selecting the most preferred TLS
+ 1.3 key agreement group on TLS servers. The old syntax had a single 'flat'
+ list of groups, and treated all the supported groups as sufficiently secure.
+ If any of the keyshares predicted by the client were supported by the server
+ the most preferred among these was selected, even if other groups supported by
+ the client, but not included in the list of predicted keyshares would have been
+ more preferred, if included.
+
The new syntax partitions the groups into distinct 'tuples' of roughly
+ equivalent security. Within each tuple the most preferred group included among
+ the client's predicted keyshares is chosen, but if the client supports a group
+ from a more preferred tuple, but did not predict any corresponding keyshares,
+ the server will ask the client to retry the ClientHello (by issuing a Hello
+ Retry Request or HRR) with the most preferred mutually supported group.
+
The above works as expected when the server's configuration uses the built-in
+ default group list, or explicitly defines its own list by directly defining the
+ various desired groups and group 'tuples'.
+
No OpenSSL FIPS modules are affected by this issue, the code in question lies
+ outside the FIPS boundary.
+
OpenSSL 3.6 and 3.5 are vulnerable to this issue.
+
OpenSSL 3.6 users should upgrade to OpenSSL 3.6.2 once it is released.
+ OpenSSL 3.5 users should upgrade to OpenSSL 3.5.6 once it is released.
+
OpenSSL 3.4, 3.3, 3.0, 1.0.2 and 1.1.1 are not affected by this issue.
+
Remediation
+
Upgrade Alpine:3.22openssl to version 3.5.6-r0 or higher.
Note:Versions mentioned in the description apply only to the upstream openssl package and not the openssl package as distributed by Alpine.
+ See How to fix? for Alpine:3.22 relevant fixed versions and status.
+
Issue summary: Applications using RSASVE key encapsulation to establish
+ a secret encryption key can send contents of an uninitialized memory buffer to
+ a malicious peer.
+
Impact summary: The uninitialized buffer might contain sensitive data from the
+ previous execution of the application process which leads to sensitive data
+ leakage to an attacker.
+
RSA_public_encrypt() returns the number of bytes written on success and -1
+ on error. The affected code tests only whether the return value is non-zero.
+ As a result, if RSA encryption fails, encapsulation can still return success to
+ the caller, set the output lengths, and leave the caller to use the contents of
+ the ciphertext buffer as if a valid KEM ciphertext had been produced.
+
If applications use EVP_PKEY_encapsulate() with RSA/RSASVE on an
+ attacker-supplied invalid RSA public key without first validating that key,
+ then this may cause stale or uninitialized contents of the caller-provided
+ ciphertext buffer to be disclosed to the attacker in place of the KEM
+ ciphertext.
+
As a workaround calling EVP_PKEY_public_check() or
+ EVP_PKEY_public_check_quick() before EVP_PKEY_encapsulate() will mitigate
+ the issue.
+
The FIPS modules in 3.6, 3.5, 3.4, 3.3, 3.1 and 3.0 are affected by this issue.
+
Remediation
+
Upgrade Alpine:3.22openssl to version 3.5.6-r0 or higher.
Note:Versions mentioned in the description apply only to the upstream openssl package and not the openssl package as distributed by Alpine.
+ See How to fix? for Alpine:3.22 relevant fixed versions and status.
+
Issue summary: An uncommon configuration of clients performing DANE TLSA-based
+ server authentication, when paired with uncommon server DANE TLSA records, may
+ result in a use-after-free and/or double-free on the client side.
+
Impact summary: A use after free can have a range of potential consequences
+ such as the corruption of valid data, crashes or execution of arbitrary code.
+
However, the issue only affects clients that make use of TLSA records with both
+ the PKIX-TA(0/PKIX-EE(1) certificate usages and the DANE-TA(2) certificate
+ usage.
+
By far the most common deployment of DANE is in SMTP MTAs for which RFC7672
+ recommends that clients treat as 'unusable' any TLSA records that have the PKIX
+ certificate usages. These SMTP (or other similar) clients are not vulnerable
+ to this issue. Conversely, any clients that support only the PKIX usages, and
+ ignore the DANE-TA(2) usage are also not vulnerable.
+
The client would also need to be communicating with a server that publishes a
+ TLSA RRset with both types of TLSA records.
+
No FIPS modules are affected by this issue, the problem code is outside the
+ FIPS module boundary.
+
Remediation
+
Upgrade Alpine:3.22openssl to version 3.5.6-r0 or higher.
Note:Versions mentioned in the description apply only to the upstream openssl package and not the openssl package as distributed by Alpine.
+ See How to fix? for Alpine:3.22 relevant fixed versions and status.
+
Issue summary: During processing of a crafted CMS EnvelopedData message
+ with KeyAgreeRecipientInfo a NULL pointer dereference can happen.
+
Impact summary: Applications that process attacker-controlled CMS data may
+ crash before authentication or cryptographic operations occur resulting in
+ Denial of Service.
+
When a CMS EnvelopedData message that uses KeyAgreeRecipientInfo is
+ processed, the optional parameters field of KeyEncryptionAlgorithmIdentifier
+ is examined without checking for its presence. This results in a NULL
+ pointer dereference if the field is missing.
+
Applications and services that call CMS_decrypt() on untrusted input
+ (e.g., S/MIME processing or CMS-based protocols) are vulnerable.
+
The FIPS modules in 3.6, 3.5, 3.4, 3.3 and 3.0 are not affected by this
+ issue, as the affected code is outside the OpenSSL FIPS module boundary.
+
Remediation
+
Upgrade Alpine:3.22openssl to version 3.5.6-r0 or higher.
Note:Versions mentioned in the description apply only to the upstream openssl package and not the openssl package as distributed by Alpine.
+ See How to fix? for Alpine:3.22 relevant fixed versions and status.
+
Issue summary: When a delta CRL that contains a Delta CRL Indicator extension
+ is processed a NULL pointer dereference might happen if the required CRL
+ Number extension is missing.
+
Impact summary: A NULL pointer dereference can trigger a crash which
+ leads to a Denial of Service for an application.
+
When CRL processing and delta CRL processing is enabled during X.509
+ certificate verification, the delta CRL processing does not check
+ whether the CRL Number extension is NULL before dereferencing it.
+ When a malformed delta CRL file is being processed, this parameter
+ can be NULL, causing a NULL pointer dereference.
+
Exploiting this issue requires the X509_V_FLAG_USE_DELTAS flag to be enabled in
+ the verification context, the certificate being verified to contain a
+ freshestCRL extension or the base CRL to have the EXFLAG_FRESHEST flag set, and
+ an attacker to provide a malformed CRL to an application that processes it.
+
The vulnerability is limited to Denial of Service and cannot be escalated to
+ achieve code execution or memory disclosure. For that reason the issue was
+ assessed as Low severity according to our Security Policy.
+
The FIPS modules in 3.6, 3.5, 3.4, 3.3 and 3.0 are not affected by this issue,
+ as the affected code is outside the OpenSSL FIPS module boundary.
+
Remediation
+
Upgrade Alpine:3.22openssl to version 3.5.6-r0 or higher.
Note:Versions mentioned in the description apply only to the upstream openssl package and not the openssl package as distributed by Alpine.
+ See How to fix? for Alpine:3.22 relevant fixed versions and status.
+
Issue summary: During processing of a crafted CMS EnvelopedData message
+ with KeyTransportRecipientInfo a NULL pointer dereference can happen.
+
Impact summary: Applications that process attacker-controlled CMS data may
+ crash before authentication or cryptographic operations occur resulting in
+ Denial of Service.
+
When a CMS EnvelopedData message that uses KeyTransportRecipientInfo with
+ RSA-OAEP encryption is processed, the optional parameters field of
+ RSA-OAEP SourceFunc algorithm identifier is examined without checking
+ for its presence. This results in a NULL pointer dereference if the field
+ is missing.
+
Applications and services that call CMS_decrypt() on untrusted input
+ (e.g., S/MIME processing or CMS-based protocols) are vulnerable.
+
The FIPS modules in 3.6, 3.5, 3.4, 3.3 and 3.0 are not affected by this
+ issue, as the affected code is outside the OpenSSL FIPS module boundary.
+
Remediation
+
Upgrade Alpine:3.22openssl to version 3.5.6-r0 or higher.
Note:Versions mentioned in the description apply only to the upstream musl package and not the musl package as distributed by Alpine.
+ See How to fix? for Alpine:3.22 relevant fixed versions and status.
+
An issue was discovered in musl libc 0.7.10 through 1.2.6. Stack-based memory corruption can occur during qsort of very large arrays, due to incorrectly implemented double-word primitives. The number of elements must exceed about seven million, i.e., the 32nd Leonardo number on 32-bit platforms (or the 64th Leonardo number on 64-bit platforms, which is not practical).
+
Remediation
+
Upgrade Alpine:3.22musl to version 1.2.5-r12 or higher.
Note:Versions mentioned in the description apply only to the upstream musl package and not the musl package as distributed by Alpine.
+ See How to fix? for Alpine:3.22 relevant fixed versions and status.
+
A security flaw has been discovered in musl libc up to 1.2.6. Affected is the function iconv of the file src/locale/iconv.c of the component GB18030 4-byte Decoder. Performing a manipulation results in inefficient algorithmic complexity. The attack must be initiated from a local position. To fix this issue, it is recommended to deploy a patch.
+
Remediation
+
Upgrade Alpine:3.22musl to version 1.2.5-r11 or higher.