[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <c9c2b61f-f6f7-4d6d-8331-3a38a4311e11@gmail.com>
Date: Wed, 28 Jan 2026 04:06:06 -0500
From: Demi Marie Obenour <demiobenour@...il.com>
To: oss-security@...ts.openwall.com, Tomas Mraz <tomas@...nssl.org>
Subject: Re: OpenSSL Security Advisory (corrected - added
CVE-2026-22795 and CVE-2026-22796)
On 1/27/26 10:48, Tomas Mraz wrote:
> OpenSSL Security Advisory [27th January 2026]
> =============================================
>
> Improper validation of PBMAC1 parameters in PKCS#12 MAC verification (CVE-2025-11187)
> =====================================================================================
>
> Severity: Moderate
>
> Issue summary: PBMAC1 parameters in PKCS#12 files are missing validation
> which can trigger a stack-based buffer overflow, invalid pointer or NULL
> pointer dereference during MAC verification.
>
> Impact summary: The stack buffer overflow or NULL pointer dereference may
> cause a crash leading to Denial of Service for an application that parses
> untrusted PKCS#12 files. The buffer overflow may also potentially enable
> code execution depending on platform mitigations.
>
> When verifying a PKCS#12 file that uses PBMAC1 for the MAC, the PBKDF2
> salt and keylength parameters from the file are used without validation.
> If the value of keylength exceeds the size of the fixed stack buffer used
> for the derived key (64 bytes), the key derivation will overflow the buffer.
> The overflow length is attacker-controlled. Also, if the salt parameter is
> not an OCTET STRING type this can lead to invalid or NULL pointer
> dereference.
>
> Exploiting this issue requires a user or application to process
> a maliciously crafted PKCS#12 file. It is uncommon to accept untrusted
> PKCS#12 files in applications as they are usually used to store private
> keys which are trusted by definition. For this reason the issue was assessed
> as Moderate severity.
I would not at all be surprised if using untrusted private keys is
not uncommon. It can be easier to upload a key pair and certificate
than to download a CSR, sign it, and then upload the certificates.
Also, programs may well assume that the PKCS#12 authenticated
encryption is sufficient to mitigate risks from an untrusted file.
> Stack buffer overflow in CMS AuthEnvelopedData parsing (CVE-2025-15467)
> =======================================================================
>
> Severity: High
>
> Issue summary: Parsing CMS AuthEnvelopedData message with maliciously
> crafted AEAD parameters can trigger a stack buffer overflow.
>
> Impact summary: A stack buffer overflow may lead to a crash, causing Denial
> of Service, or potentially remote code execution.
>
> When parsing CMS AuthEnvelopedData structures that use AEAD ciphers such as
> AES-GCM, the IV (Initialization Vector) encoded in the ASN.1 parameters is
> copied into a fixed-size stack buffer without verifying that its length fits
> the destination. An attacker can supply a crafted CMS message with an
> oversized IV, causing a stack-based out-of-bounds write before any
> authentication or tag verification occurs.
>
> Applications and services that parse untrusted CMS or PKCS#7 content using
> AEAD ciphers (e.g., S/MIME AuthEnvelopedData with AES-GCM) are vulnerable.
> Because the overflow occurs prior to authentication, no valid key material
> is required to trigger it. While exploitability to remote code execution
> depends on platform and toolchain mitigations, the stack-based write
> primitive represents a severe risk.
If an application calls PKCS7_d2i() and then checks a signature,
is it affected?
> Out of bounds write in PKCS12_get_friendlyname() UTF-8 conversion (CVE-2025-69419)
> ==================================================================================
>
> Severity: Low
>
> Issue summary: Calling PKCS12_get_friendlyname() function on a maliciously
> crafted PKCS#12 file with a BMPString (UTF-16BE) friendly name containing
> non-ASCII BMP code point can trigger a one byte write before the allocated
> buffer.
>
> Impact summary: The out-of-bounds write can cause a memory corruption
> which can have various consequences including a Denial of Service.
>
> The OPENSSL_uni2utf8() function performs a two-pass conversion of a PKCS#12
> BMPString (UTF-16BE) to UTF-8. In the second pass, when emitting UTF-8 bytes,
> the helper function bmp_to_utf8() incorrectly forwards the remaining UTF-16
> source byte count as the destination buffer capacity to UTF8_putc(). For BMP
> code points above U+07FF, UTF-8 requires three bytes, but the forwarded
> capacity can be just two bytes. UTF8_putc() then returns -1, and this negative
> value is added to the output length without validation, causing the
> length to become negative. The subsequent trailing NUL byte is then written
> at a negative offset, causing write outside of heap allocated buffer.
>
> The vulnerability is reachable via the public PKCS12_get_friendlyname() API
> when parsing attacker-controlled PKCS#12 files. While PKCS12_parse() uses a
> different code path that avoids this issue, PKCS12_get_friendlyname() directly
> invokes the vulnerable function. Exploitation requires an attacker to provide
> a malicious PKCS#12 file to be parsed by the application and the attacker
> can just trigger a one zero byte write before the allocated buffer.
> For that reason the issue was assessed as Low severity according to our
> Security Policy.
One byte out of bound writes have been exploited before.
See https://projectzero.google/2016/12/chrome-os-exploit-one-byte-overflow-and.html
> Missing ASN1_TYPE validation in TS_RESP_verify_response() function (CVE-2025-69420)
> ===================================================================================
>
> Severity: Low
>
> Issue summary: A type confusion vulnerability exists in the TimeStamp Response
> verification code where an ASN1_TYPE union member is accessed without first
> validating the type, causing an invalid or NULL pointer dereference when
> processing a malformed TimeStamp Response file.
>
> Impact summary: An application calling TS_RESP_verify_response() with a
> malformed TimeStamp Response can be caused to dereference an invalid or
> NULL pointer when reading, resulting in a Denial of Service.
>
> The functions ossl_ess_get_signing_cert() and ossl_ess_get_signing_cert_v2()
> access the signing cert attribute value without validating its type.
> When the type is not V_ASN1_SEQUENCE, this results in accessing invalid memory
> through the ASN1_TYPE union, causing a crash.
Is the data read from the bad pointer returned to the caller?
> Missing ASN1_TYPE validation in PKCS#12 parsing (CVE-2026-22795)
> ================================================================
>
> Severity: Low
>
> Issue summary: An invalid or NULL pointer dereference can happen in
> an application processing a malformed PKCS#12 file.
>
> Impact summary: An application processing a malformed PKCS#12 file can be
> caused to dereference an invalid or NULL pointer on memory read, resulting
> in a Denial of Service.
>
> A type confusion vulnerability exists in PKCS#12 parsing code where
> an ASN1_TYPE union member is accessed without first validating the type,
> causing an invalid pointer read.
>
> The location is constrained to a 1-byte address space, meaning any
> attempted pointer manipulation can only target addresses between 0x00 and 0xFF.
> This range corresponds to the zero page, which is unmapped on most modern
> operating systems and will reliably result in a crash, leading only to a
> Denial of Service. Exploiting this issue also requires a user or application
> to process a maliciously crafted PKCS#12 file. It is uncommon to accept
> untrusted PKCS#12 files in applications as they are usually used to store
> private keys which are trusted by definition. For these reasons, the issue
> was assessed as Low severity.
See above about private key import.
> ASN1_TYPE Type Confusion in the PKCS7_digest_from_attributes() function (CVE-2026-22796)
> ========================================================================================
>
> Severity: Low
>
> Issue summary: A type confusion vulnerability exists in the signature
> verification of signed PKCS#7 data where an ASN1_TYPE union member is
> accessed without first validating the type, causing an invalid or NULL
> pointer dereference when processing malformed PKCS#7 data.
>
> Impact summary: An application performing signature verification of PKCS#7
> data or calling directly the PKCS7_digest_from_attributes() function can be
> caused to dereference an invalid or NULL pointer when reading, resulting in
> a Denial of Service.
>
> The function PKCS7_digest_from_attributes() accesses the message digest attribute
> value without validating its type. When the type is not V_ASN1_OCTET_STRING,
> this results in accessing invalid memory through the ASN1_TYPE union, causing
> a crash.
Is the memory accessed through the bad pointer returned to the caller
in any way?
> Exploiting this vulnerability requires an attacker to provide a malformed
> signed PKCS#7 to an application that verifies it. The impact of the
> exploit is just a Denial of Service, the PKCS7 API is legacy and applications
> should be using the CMS API instead. For these reasons the issue was
> assessed as Low severity.
I know that EDK2 definitely uses the PKCS7 API.
--
Sincerely,
Demi Marie Obenour (she/her/hers)
Download attachment "OpenPGP_0xB288B55FFF9C22C1.asc" of type "application/pgp-keys" (7141 bytes)
Download attachment "OpenPGP_signature.asc" of type "application/pgp-signature" (834 bytes)
Powered by blists - more mailing lists
Please check out the
Open Source Software Security Wiki, which is counterpart to this
mailing list.
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
