Si elles sont exploitées, ces failles peuvent permettre aux attaquants d'obtenir un accès non autorisé à des informations sensibles ou de causer des problèmes en général.
Des informations ont été publiées sur un vulnérabilité qui a été détectée dans l'implémentation OpenSSH de agent ssh qui permet au code de s'exécuter sur un système qui a fourni un accès ssh-agent à un hôte à l'autre extrémité d'une connexion ssh.
La vulnérabilité, déjà cataloguée sous CVE-2023-38408, il est remarquable car il est exploitable à distance. L'attaque uniquement possible si l'utilisateur s'est connecté via ssh à un système contrôlé par l'attaquant en activant le transfert de socket vers ssh-agent via ssh à l'aide de l'option "-A" ou du paramètre ForwardAgent dans le fichier de configuration.
Le processus ssh-agent, utilisé pour mettre en cache les clés privées pour l'authentification par clé publique, prend en charge un mode de transfert facultatif qui permet au côté distant d'une connexion ssh d'accéder à l'agent ssh sur le système local afin de ne pas mettre en cache les données d'authentification sur d'autres hôtes.
Vulnérabilité est lié à la présence dans ssh-agent du support du chargement des modules PKCS#11, qui peut être démarré, entre autres, via un socket unix transmis à un autre système vers ssh-agent.
Cette fonctionnalité permet à un attaquant qui contrôle l'hôte auquel il est relié charger et décharger immédiatement toutes les bibliothèques partagées des répertoires /usr/lib* sur le système local de la victime dans un processus ssh-pkcs11-helper séparé. Cette fonctionnalité apparaît dans ssh-agent compilé avec l'option ENABLE_PKCS11, qui est activée par défaut.
Initialement, la possibilité de charger des bibliothèques partagées n'était pas considérée comme une menace pour des raisons de sécurité, puisque le chargement n'est possible qu'à partir des répertoires système /usr/lib*, qui contiennent les bibliothèques officiellement fournies par la distribution, et que les opérations sur ces bibliothèques se limitent à appeler dlopen() et dlclose(), sans appeler les fonctions de la bibliothèque .
Toutefois, oublié que certaines bibliothèques ont des fonctions de construction et de destruction qui sont appelées automatiquement lors de l'exécution des opérations dlopen() et dlclose(). Cela peut être suffisant pour récupérer les bibliothèques nécessaires et organiser l'exécution de code à distance.
La capacité d'attaquer est démontrée dans l'environnement par défaut de Ubuntu, car non testé dans d'autres distributions, qui installe également trois packages à partir du référentiel "universe" (bien qu'il soit supposé que dans certaines distributions, il est possible d'attaquer dans la configuration par défaut).
8 variantes de l'attaque ont été proposées.
Par exemple, l'une des options prometteuses pour créer un exploit fonctionnel est basée sur le fait que la bibliothèque libgnatcoll_postgres.so, lors de l'exécution de dlopen(), enregistre une pile de signaux séparée utilisée dans les gestionnaires de signaux en appelant sigaltstack(), et après avoir appelé dlclose() supprime l'allocation de mémoire, mais ne désactive pas le registre (SS_DISABLE) de la pile de signaux.
Pour exploiter la vulnérabilité, les manipulations suivantes sont effectuées:
- Diverses bibliothèques sont chargées pour modifier la mise en page mmap.
- La bibliothèque libgnatcoll_postgres.so est chargée, une autre pile de signaux est enregistrée et munmap() est exécuté.
- Les bibliothèques sont chargées pour modifier la disposition de mmap et remplacer la pile de signaux séparée par une autre zone de mémoire en mode écriture (par exemple, la pile de flux ou les segments .data/.bss).
- Charge une bibliothèque qui enregistre le gestionnaire de signal SA_ONSTACK mais ne l'enregistre pas avec munmap() lorsque dlclose() est appelée.
- La bibliothèque qui reçoit le signal et appelle le gestionnaire de signal SA_ONSTACK est chargée, provoquant l'écrasement de la zone de mémoire remplacée par les cadres de pile du gestionnaire de signal.
- Les bibliothèques sont chargées pour écraser spécifiquement le contenu de la zone de mémoire remplacée.
En ce qui concerne la vulnérabilité, il convient de mentionner que cette a été corrigé dans la version OpenSSH 9.3p2 récemment publié. Dans la nouvelle version, les demandes de chargement des modules PKCS#11 sont désactivées par défaut. Pour contourner le problème de sécurité, vous pouvez spécifier une liste blanche PKCS#11/FIDO vide (ssh-agent -P ») lors du démarrage de ssh-agent, ou définir explicitement les bibliothèques autorisées dans la liste blanche.
Enfin, si vous souhaitez en savoir plus, vous pouvez consulter les détails dans la lien suivant