[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <c26e1de1bddfdf783926294fa3d2b8933352d144.camel@openssl.org>
Date: Wed, 28 Jan 2026 10:21:41 +0100
From: Tomas Mraz <tomas@...nssl.org>
To: Demi Marie Obenour <demiobenour@...il.com>,
oss-security@...ts.openwall.com
Subject: Re: OpenSSL Security Advisory (corrected - added
CVE-2026-22795 and CVE-2026-22796)
On Wed, 2026-01-28 at 04:06 -0500, Demi Marie Obenour wrote:
> 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
> >
...
> > 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.
>
Yes, but it is still uncommon enough to keep this at Moderate severity
in our opinion.
> > Stack buffer overflow in CMS AuthEnvelopedData parsing (CVE-2025-
> > 15467)
> > ===================================================================
> > ====
> >
> > Severity: High
> >
...
> If an application calls PKCS7_d2i() and then checks a signature,
> is it affected?
No. PKCS7 API is not affected, only CMS API.
>
> > Out of bounds write in PKCS12_get_friendlyname() UTF-8 conversion
> > (CVE-2025-69419)
> > ===================================================================
> > ===============
> >
> > Severity: Low
> >
...
> > 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
Yes, but this is much more constrained vulnerability than the one you
are linking.
> > 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?
If you're thinking about leaking some data to the attacker. No, we do
not think this can be exploited in such way.
>
>
> > 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?
Again, we do not think this vulnerability can be used to leak any
private data to the attacker.
>
--
Tomáš Mráz, Chief Technology Officer, OpenSSL Foundation
Join the Code Protectors or support us on Github Sponsors
https://openssl-foundation.org/donate/
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.
