TL;DR: Face à la troisième débordement de mémoire tampon détectée en 2026 (et, selon F5, RCE sans ASLR) lors de l'utilisation d'expressions régulières et de variables, le développeur de freenginx, Maxim Dunin, a décidé qu'il était temps d'agir et a ajouté à son produit une vérification de la taille de la variable avant d'y écrire des données. Cette nouveauté a été reprise par nginx, ce qui donne de l'espoir pour mettre fin à de nouvelles vulnérabilités CVE sur ce sujet.
Voici les détails.
Le 19 juin, un commit a été fait dans freenginx, ajoutant dans la description de la variable un champ end, indiquant la fin du tampon. Auparavant, il n'y avait qu'un pointeur sur le début (pos), la longueur requise étant calculée (et étant encore calculée) à l'avance, et au moment de copier les données dans la variable, on supposait que la longueur correctement calculée garantissait que les données tiendraient dans le tampon. Malheureusement, deux fois en mai 2026, à cause de divers oublis, cela ne s'est pas produit (1 (linux.org.ru), 2 (linux.org.ru)), ce qui a conduit à des débordements de mémoire tampon et à de mauvaises conséquences. Donc, maintenant, lors de la création d'un tampon de variable, un pointeur vers sa fin est également rempli, et avant d'écrire les données dans la variable, si les données ne peuvent pas y tenir, le traitement de la requête sera contrôlablement terminé avec une erreur. Cela signifie que les erreurs de calcul de la longueur peuvent toujours exister, mais elles ne provoqueront plus de corruption de mémoire, mais échoueront seulement une requête http spécifique. Les commits suivants (2 (freenginx.org), 3 (freenginx.org)) ont ajouté une protection similaire dans d'autres parties du code, y compris le code de journalisation d'accès. Le 7 juillet, une version freenginx 1.31.3, incluant cette correction, a été publiée.
Le 15 juillet, ces commits ont été intégrés par nginx (1 (github.com), 2 (github.com), 3 (github.com), échangent inexplicablement le deuxième et le troisième dans la chaîne), la question a été assignée CVE-2026-42533, et F5 a publié un SA (f5.com).
Concernant la vulnérabilité spécifique cette fois-ci : elle se manifeste lors de l'utilisation de la directive map avec des regex impliquant des paramètres capturés. En ce qui concerne les autres conditions nécessaires à son déclenchement, le texte dans la description du commit et le texte dans le SA diffèrent légèrement : le SA mentionne qu'il doit y avoir un calcul d'une certaine chaîne, utilisant le paramètre capturé restant de map, avant le résultat de ce même map. Dans la description du commit, un exemple montre qu'une variable, contenant le paramètre capturé, est remise à zéro entre ces étapes. Quoi qu'il en soit, ce type de vulnérabilité ne se rencontrera probablement pas dans la plupart des installations de nginx, et donc elle a peu affecté quiconque. Il convient également de noter que les corrections concernant le calcul de la longueur dans ce cas particulier ne semblent pas présentes dans les modifications effectuées (ou alors je n'ai pas bien cherché ?), il n'y a que une protection transformant le problème en un échec contrôlé de la requête http. Cependant, le 19 juillet, quelques corrections ont été ajoutées dans freenginx.5bfb, 7622, b906) du calcul de la longueur pour une situation similaire, mais il est difficile de dire immédiatement si c'est cela ou non.
La vulnérabilité est apparue dans la version nginx 0.9.6, les corrections ont été intégrées dans les versions freenginx 1.31.3, nginx 1.30.4, nginx 1.31.3.
Dans le SA nginx, des remerciements sont adressés à plusieurs personnes pour leurs communications indépendantes concernant la vulnérabilité et le respect des « normes de divulgation coordonnée » :
F5 remercie Ming Xuan, DKD (@pidifn), Ji’an Zhou, et Zhen Yan de AntAISecurityLab, Rafael Gacek, Sergii Negodiuk d'EVO.company, Lam Jun Rong de Calif.io, Mufeed VH de Winfunc Research (winfunc.com), Vexera AI (https://vexera.ai), Tu Tran Dinh (@1w4y), Stan Shaw (cyberstan), qianshuidewajueji, zenneth (randomguy6407), Zhenpeng (Leo) Lin de depthfirst, Lukas Johannes Moeller, Melih Tolga Sahin de Vodafone Türkiye, Ayoub Nabil Boubagrat (GitHub : @ayoubnabil), et Milan Jovic (Kljunowsky) pour avoir porté individuellement ce problème à notre attention et avoir suivi les normes les plus élevées de divulgation coordonnée.
Dans freenginx, les informations accompagnant la correction se limitent en fait à un message lors du commit. Dans changelog-ce correction n'est même pas marquée par la mention « sécurité » (security) ni « correction » (bugfix), juste « ajout » (feature). Il est probable que l'auteur ne considérait pas ce problème comme critique. Il n'a pas été possible de déterminer comment se rapportent les messages sur le problème de la part des personnes mentionnées chez F5 et le commit emprunté de freenginx, s'ils ont (ou quelqu'un d'autre) signalé le problème à l'auteur de freenginx.
Source : linux.org.ru
