CVE-2024-5535 in OpenSSL
Résumé
par VulDB • 27/06/2026
Résumé de l'anomalie : L'appel à la fonction d'API OpenSSL `SSL_select_next_proto` avec un tampon vide pour les protocoles clients pris en charge peut provoquer un plantage ou entraîner l'envoi du contenu de la mémoire au pair.
Résumé de l'impact : Une surlecture de tampon (buffer overread) peut avoir diverses conséquences potentielles, telles qu'un comportement inattendu de l'application ou un plantage. En particulier, cette anomalie pourrait entraîner l'envoi jusqu'à 255 octets de données privées arbitraires issues de la mémoire au pair, provoquant ainsi une perte de confidentialité. Toutefois, seules les applications qui appellent directement la fonction `SSL_select_next_proto` avec une liste vide (longueur nulle) de protocoles clients pris en charge sont concernées par cette anomalie. Ce scénario ne devrait normalement jamais être valide et n'est généralement pas sous le contrôle d'un attaquant, mais peut survenir accidentellement dans le cas d'une erreur de configuration ou de programmation au sein de l'application appelante.
La fonction d'API OpenSSL `SSL_select_next_proto` est typiquement utilisée par les applications TLS qui prennent en charge ALPN (Application Layer Protocol Negotiation) ou NPN (Next Protocol Negotiation). Le NPN est plus ancien, n'a jamais été standardisé et est déprécié au profit de l'ALPN. Nous estimons que le déploiement d'ALPN est nettement plus répandu que celui du NPN. La fonction `SSL_select_next_proto` accepte une liste de protocoles provenant du serveur et une liste de protocoles provenant du client, puis renvoie le premier protocole présent dans la liste du serveur qui apparaît également dans la liste du client. En cas d'absence de chevauchement entre les deux listes, elle renvoie le premier élément de la liste du client. Dans les deux cas, elle signale si un chevauchement a été détecté ou non. Lorsque `SSL_select_next_proto` est appelée avec une liste cliente de longueur nulle, elle ne détecte pas cette condition et retourne la mémoire située immédiatement après le pointeur de la liste cliente (en indiquant qu'il n'y avait aucun chevauchement dans les listes).
Cette fonction est généralement invoquée depuis un rappel d'application côté serveur pour l'ALPN ou un rappel d'application côté client pour le NPN. Dans le cas de l'ALPN, libssl garantit que la liste des protocoles fournie par le client n'est jamais de longueur nulle. La liste des protocoles du serveur provient de l'application et ne devrait normalement pas être attendue comme étant de longueur nulle. Si la fonction `SSL_select_next_proto` a été appelée conformément aux attentes (avec la liste fournie par le client passée dans les paramètres `client/client_len`), alors l'application ne sera pas vulnérable à cette anomalie. Si l'application a accidentellement été configurée avec une liste serveur de longueur nulle, si elle a accidentalement passé cette liste serveur de longueur nulle dans les paramètres `client/client_len`, et si elle a en outre échoué à gérer correctement la réponse « aucun chevauchement » (ce qui entraînerait normalement un échec du handshake en ALPN), alors elle sera vulnérable à ce problème.
Dans le cas du NPN, le protocole permet au client de sélectionner opportunément un protocole lorsqu'il n'y a pas de chevauchement. OpenSSL renvoie le premier protocole client dans le cas d'absence de chevauchement pour soutenir cette fonctionnalité. La liste des protocoles clients provient de l'application et ne devrait normalement pas être attendue comme étant de longueur nulle. Cependant, si la fonction `SSL_select_next_proto` est accidentellement appelée avec un `client_len` égal à 0, un pointeur mémoire invalide sera retourné au lieu du résultat attendu. Si l'application utilise cette sortie en tant que protocole opportuniste, une perte de confidentialité se produira.
Cette anomalie a été évaluée comme étant de gravité faible (Low severity), car les applications sont le plus susceptibles d'être vulnérables si elles utilisent NPN au lieu d'ALPN – or le NPN
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.