It's 2014, why not use LibreSSL.
You don't have to bring up AI, everyone just needs to leave OpenSSL to die.
And make sure to make it a hybrid of PHP and JavaScript /s
If you had a dynamically sized heap allocated buffer as the destination you'd still have a denial of service attack, no matter what language was used.
1. Find out how big this data is, we tell the ASN.1 code how big it's allowed to be, but since we're not storing it anywhere those tests don't matter
2. Check we found at least some data, zero isn't OK, failure isn't OK, but too big is fine
3. Copy the too big data onto a local buffer
The API design is typical of C and has the effect of encouraging this mistake
int ossl_asn1_type_get_octetstring_int(const ASN1_TYPE *a, long *num, unsigned char *data, int max_len)
This encourages people to either forget the return value entirely (it's just some integer, who cares, in the happy path this works) or check it for -1 which indicates some fatal ASN.1 layer problem, give up, but ignore other values.
If the thing you got back from your function was a Result type you'd know that this wasn't OK, because it isn't OK. But the "Eh, everything is an integer" model popular in C discourages such sensible choices because they were harder to implement decades ago.
“ Impact summary: A stack buffer overflow may lead to a crash, causing Denial of Service, or potentially remote code execution.”
Additionally they note: -
"While exploitability to remote code execution depends on platform and toolchain mitigations, the stack-based write primitive represents a severe risk."
IMO, probably in of itself, this alone is not able to do much besides maybe a crash / Denial of Service on modern systems. But it might be able to be used as part of a more advanced exploit chain, alongside other vulnerabilities, to potentially reach remote code execution, though this would be a much more sophisticated exploit and is maybe a bit of a reach. Still, I hesitate to call it impossible on modern systems due to the creativity of exploit developers.
Not necessarily. I have successfully exploited stack buffer overflows in major products despite stack canaries, ASLR, and DEP. It largely depends on context; if the vector is something that can be hit repeatedly, such a webform that that takes a cert or whatever, that simplifies things a lot versus something like a file format exploit, where you probably only get one chance. While I haven't analyzed this vulnerability, I would absolutely assume exploitability even if I couldn't see a way myself.
I never paid attention to the fact that one table had "Fixed" and the other "Not affected" for the same "Not affected" package.
selckin•1h ago
"Applications and services that parse untrusted CMS or PKCS#7 content using AEAD ciphers (e.g., S/MIME AuthEnvelopedData with AES-GCM) are vulnerable"
to human?
woodruffw•1h ago
(Unless I'm missing something, a key piece of context here is that CMD/PKCS#7 blobs are typically allowed to select their own algorithms, at least within an allowlist controlled by the receiving party. So the fact that it depends on an AEAD-specific parameter encoding is probably not a huge hurdle for someone looking to exploit this.)
[1]: https://datatracker.ietf.org/doc/html/rfc5652
[2]: https://datatracker.ietf.org/doc/html/rfc2315
tptacek•1h ago
AEAD ciphers are those that simultaneously encrypt and authenticate data. AES-GCM is the most popular; Chapoly is the 2nd most popular. AEAD ciphers are how modern programs do encryption.
AEAD ciphers all rely on additional parameters, most commonly a nonce; it's critical to security that the nonce only ever be used once with a given key. You need the nonce to decrypt the AEAD ciphertext, so it's usually tacked on to the message (in more clever formats you can derive it contextually, but PKCS7 is a general-purpose format).
In parsing PKCS7 messages, when OpenSSL comes across AEAD-encrypted blobs, it needs to parse out the nonce. AEAD nonces tend to have fixed sizes, but there are extended-nonce variants of AEADs, and the format allows for arbitrary-sized values. OpenSSL assumed a fixed nonce size, but parsed with a library that handled arbitrary-sized values. Stack overflow.
A maliciously formatted Authenticode signature, certificate chain, OCSP response (I think?), all things that could trigger the bug.