All, See below for a security advisory on the bug fixed by libtasn1 4.21.0.
If anyone can establish a reasonable scenario where this can be triggered by an attacker, that would be useful. I would not consider this a security issue until we know of such a scenario. There is a CVE with relative high severity so we felt we had to respond somehow. We forgot to post the advisory earlier but canonical reference for it is the git repository which can be viewed here: https://codeberg.org/libtasn1/libtasn1/src/branch/master/doc/security/CVE-2025-13151.md (I realize we should tweak the markdown usage to look better cross-platforms.. and maybe use orgdown instead) /Simon ================================================================== CVE-2025-13151: Stack-based buffer overflow in `asn1_expand_octet_string` function ================================================================== Expanding an "OCTET STRING" element of a structure using the `asn1_expand_octet_string` function may lead to a one-byte stack overflow that may corrupt adjacent memory in the worst case scenario. Severity: Low Vulnerable versions : All released version of libtasn1 Not vulnerable : libtasn1 4.21.0 Vulnerability information ========================= The `asn1_expand_octet_string` function was using an internal buffer of size `2 * ASN1_MAX_NAME_SIZE + 1`, allocated on the stack. The function then constructs the element name on the buffer, by concatenating `definitions->name` and `p2->name`, separated with a dot (".") character. When both the names are of `ASN1_MAX_NAME_SIZE` characters, the final NUL character could have been written past the boundary. For details, see the original issue reported at: https://gitlab.com/gnutls/libtasn1/-/issues/55 Exploitation ============ In order to exploit this, the target program must be using the `asn1_expand_octet_string` function explicitly with an excessively long name (`ASN1_MAX_NAME_SIZE` = 64 characters) for both the ASN.1 definition and the target element. Given the ASN.1 definitions are normally part of the application code base, it is highly unlikely to be exploitable. Recommendation ========= To address this vulnerability, please upgrade to libtasn1 4.21.0 or later. We recommend that applications using libtasn1 should embed the ASN.1 definitions as a C table created using the `asn1Parser` program, rather than loading it at run time, to reduce the attack surface. Workaround ========== For those who cannot modify the application code, compile the libtasn1 with the `-D_FORTIFY_SOURCE=2` flag will mitigate the issue by replacing the `strcat` implementation with a bounds check. Credits ======= Thanks to Benny Zelster from Microsoft Research and Vijay Sarvepalli from CERT/CC for coordinating the disclosure of this vulnerability.
signature.asc
Description: PGP signature
