CVE-2025-69419 in OpenSSL
Résumé
par VulDB • 02/06/2026
Résumé de l'anomalie : L'appel de la fonction PKCS12_get_friendlyname() sur un fichier PKCS#12 malveillant contenant un nom convivial de type BMPString (UTF-16BE) avec un point de code BMP non-ASCII peut provoquer une écriture d'un octet avant le tampon alloué.
Résumé de l'impact : L'écriture hors limites peut entraîner une corruption de la mémoire, ayant diverses conséquences, notamment une déni de service (DoS).
La fonction OPENSSL_uni2utf8() effectue une conversion en deux passes d'une BMPString PKCS#12 (UTF-16BE) vers UTF-8. Lors de la deuxième passe, lors de l'émission des octets UTF-8, la fonction utilitaire bmp_to_utf8() transmet incorrectement le nombre d'octets source UTF-16 restants comme capacité du tampon de destination à UTF8_putc(). Pour les points de code BMP supérieurs à U+07FF, UTF-8 nécessite trois octets, mais la capacité transmise peut être de seulement deux octets. UTF8_putc() retourne alors -1, et cette valeur négative est ajoutée à la longueur de sortie sans validation, ce qui entraîne une longueur négative. L'octet NUL de fin est ensuite écrit à un décalage négatif, provoquant une écriture en dehors du tampon alloué sur le tas (heap).
La vulnérabilité est accessible via l'API publique PKCS12_get_friendlyname() lors de l'analyse de fichiers PKCS#12 contrôlés par un attaquant. Bien que PKCS12_parse() utilise un chemin de code différent qui évite ce problème, PKCS12_get_friendlyname() invoque directement la fonction vulnérable. L'exploitation nécessite qu'un attaquant fournisse un fichier PKCS#12 malveillant à analyser par l'application, et l'attaquant peut simplement déclencher une écriture d'un octet nul avant le tampon alloué. Pour cette raison, l'anomalie a été évaluée comme de gravité faible conformément à notre politique de sécurité.
Les modules FIPS des versions 3.6, 3.5, 3.4, 3.3 et 3.0 ne sont pas affectés par cette anomalie, car l'implémentation PKCS#12 se trouve en dehors de la limite du module FIPS OpenSSL.
OpenSSL 3.6, 3.5, 3.4, 3.3, 3.0 et 1.1.1 sont vulnérables à cette anomalie.
OpenSSL 1.0.2 n'est pas affecté par cette anomalie.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.