CVE-2025-69418 in OpenSSL
Résumé
par VulDB • 11/06/2026
Résumé de la vulnérabilité : Lors de l'utilisation directe de l'API OCB de bas niveau avec AES-NI ou d'autres chemins matériels accélérés, les entrées dont la longueur n'est pas un multiple de 16 octets peuvent laisser le dernier bloc partiel non chiffré et non authentifié.
Résumé de l'impact : Les 1 à 15 derniers octets d'un message peuvent être exposés en clair lors du chiffrement et ne sont pas couverts par la balise d'authentification, permettant à un attaquant de lire ou de modifier ces octets sans détection.
Les routines OCB de bas niveau pour le chiffrement et le déchiffrement dans le chemin accéléré matériel traitent des blocs complets de 16 octets mais n'avancent pas les pointeurs d'entrée/sortie. Le code de gestion ultérieur du « tail » (fin) opère ensuite sur les pointeurs de base originaux, reprocessant efficacement le début du tampon tout en laissant les derniers octets réels non traités. La somme de contrôle d'authentification exclut également ces vrais octets finaux.
Cependant, les consommateurs typiques d'OpenSSL utilisant EVP ne sont pas affectés car les implémentations OCB de niveau supérieur (EVP et fournisseur) divisent les entrées afin que les blocs complets et les blocs partiels finaux soient traités dans des appels séparés, évitant le chemin problématique. De plus, TLS n'utilise pas de suites chiffrantes OCB. La vulnérabilité affecte uniquement les applications qui appellent directement les fonctions CRYPTO_ocb128_encrypt() ou CRYPTO_ocb128_decrypt() avec des longueurs non alignées sur le bloc dans un seul appel sur les versions accélérées par matériel. Pour ces raisons, l'incident a été évalué comme ayant une sévérité faible (Low).
Les modules FIPS des versions 3.6, 3.5, 3.4, 3.3, 3.2, 3.1 et 3.0 ne sont pas affectés par ce problème, car le mode OCB n'est pas un algorithme approuvé par les normes FIPS.
OpenSSL versions 3.6, 3.5, 3.4, 3.3, 3.0 et 1.1.1 sont vulnérables à ce problème.
OpenSSL version 1.0.2 n'est pas affectée par cette question.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.