Dans le patch gssapi.patch utilisé dans de nombreuses distributions Linux, qui ajoute la prise en charge de l'échange de clés basé sur GSSAPI à OpenSSH, une vulnérabilité a été identifiée (CVE-2026-3497), entraînant un déréférencement de pointeur, une corruption de la mémoire et un contournement du mécanisme de séparation des privilèges (Privsep). La vulnérabilité peut être exploitée à distance avant l'authentification. Le chercheur ayant découvert le problème a démontré l'initiation d'un arrêt d'urgence du processus en envoyant un paquet réseau modifié au serveur SSH. Il n'est pas exclu qu'en plus d'un déni de service, des options d'exploitation plus dangereuses existent.
Il est remarquable qu'à l'époque, les développeurs d'OpenSSH aient refusé d'inclure dans la version principale le changement pour la prise en charge de GSSAPI en raison de doutes sur sa sécurité. Cependant, de nombreuses distributions Linux ont inclus ce patch dans leurs paquets OpenSSH. Plusieurs versions du patch GSSAPI circulent, mais la plupart d'entre elles contiennent une erreur qui entraîne la vulnérabilité. Une correction n'est encore disponible que sous la forme d'un patch, les modifications consistant à remplacer l'appel de la fonction sshpkt_disconnect() par ssh_packet_disconnect() dans le fichier kexgsss.c.
Actuellement, la vulnérabilité est confirmée dans Debian et Ubuntu. Pour les autres distributions, l'utilisation du patch problématique et sa susceptibilité à la vulnérabilité sont en cours de vérification (SUSE/openSUSE, RHEL, Gentoo, Arch, Fedora). La vulnérabilité ne se manifeste que lorsque l'option "GSSAPIKeyExchange yes" est activée dans les paramètres. La possibilité d'exploitation dépend également des options du compilateur avec lesquelles le paquet a été construit dans les distributions.
La cause de la vulnérabilité réside dans une erreur dans la fonction sshpkt_disconnect(), qui empêchait le processus de se terminer après la réception d'un message de déconnexion, permettant à un attaquant, au moment de l'accord sur les clés, d'envoyer un type de message GSSAPI non prévu par la logique opérationnelle. de serveurs message GSSAPI imprévu. serveur il le place dans une file d'attente et ne stoppe pas l'exécution du programme, mais n'initialise pas les variables qui déterminent les paramètres de connexion. Ensuite, dans la boucle de traitement des événements, il exécute le code qui lit la structure non initialisée recv_tok depuis la pile (il lit les données restantes dans la pile de l'appel précédent de la fonction), l'envoie à un processus privilégié via IPC, puis la passe à la fonction gss_release_buffer(), qui peut appeler la fonction free() et libérer la mémoire pour un pointeur incorrect, pointant vers une zone mémoire aléatoire.
Source : opennet.ru
