Si je comprends bien toute l'idée ici est de provoquer l'exécution de code sur la machine de la personne qui se connecte en exploitant une faille dans ssh-agent. Ça nécessite que l'attaquant ait accès à la machine sur laquelle on se connecte pour installer les libraries nécessaires dans /usr/lib. Ça a l'air intéressant comme concept mais ça a l'air compliqué à exploiter en l'état dans la nature.
En gros, évitez d'utiliser -A si vous n'en avez pas besoin et supprimez l'option de votre configuration par défaut (alias ou ssh_config). Ceci n'est pas lié à ce problème mais une bonne pratique générale :-)
Posté par Misc (site web personnel) .
Évalué à 4.
Dernière modification le 20 juillet 2023 à 10:27.
L'attaquand doit être root sur la machine en face (pour accéder à la socket transmise), et il faut avoir assez de libs sur la machine cible afin de construire un exploit spécifique en combinant des chargements/déchargements.
Je connais aucune des libs détaillés par qualys dans la démonstration, j'imagine à dessein pour ne pas rendre ça trop facile à utiliser. Mais du coup, c'est pas clair si c'est faisable facilement en dehors du cas spécifique d'ubuntu 20.04 par défaut.
(et à mon grand regret, ssh-agent n'est pas confiné avec selinux sur ma Fedora)
À vous lire, l'attaque paraît délicate à employer. Ce qui m'intrigue c'est qu'il n'ait fallu que 14 jours entre le signalement (avec patch) et la mise à disposition par les distributions (chez moi la correction a été faite ce matin). Est-ce un délai court ? Standard ? N'est-ce pas une réaction digne d'une menace importante ?
Je suis tenté de dire qu'il vaut mieux corriger pendant que la vulnérabilité est encore difficile à exploiter, plutôt que d'attendre une exploitation massive dans la nature et que "tout le monde" doive appliquer des correctifs en urgence.
Ouais enfin, il faut 1) être root sur la machine en face 2) avoir quelqu'un qui utilise un forward d'agent.
Si 1 et 2 sont remplis, il faut bien voir que tu es déjà dans la merde vu que root peut juste taper dans ton socket et utiliser ta clé, et par exemple, dans des cas hypothétiques, faire un ssh pour revenir vers ta propre machine avec ton compte, ou ce genre de choses.
Je dit pas qu'il faut pas corriger, mais clairement, je pense qu'il n'y a pas trop lieu de paniquer dans la grande majorité des cas.
# Bonnes pratiques
Posté par nud . Évalué à 3.
Si je comprends bien toute l'idée ici est de provoquer l'exécution de code sur la machine de la personne qui se connecte en exploitant une faille dans ssh-agent. Ça nécessite que l'attaquant ait accès à la machine sur laquelle on se connecte pour installer les libraries nécessaires dans /usr/lib. Ça a l'air intéressant comme concept mais ça a l'air compliqué à exploiter en l'état dans la nature.
En gros, évitez d'utiliser
-Asi vous n'en avez pas besoin et supprimez l'option de votre configuration par défaut (alias oussh_config). Ceci n'est pas lié à ce problème mais une bonne pratique générale :-)Voir aussi https://cve.circl.lu/cve/CVE-2023-38408
[^] # Re: Bonnes pratiques
Posté par Misc (site web personnel) . Évalué à 4. Dernière modification le 20 juillet 2023 à 10:27.
L'attaquand doit être root sur la machine en face (pour accéder à la socket transmise), et il faut avoir assez de libs sur la machine cible afin de construire un exploit spécifique en combinant des chargements/déchargements.
Je connais aucune des libs détaillés par qualys dans la démonstration, j'imagine à dessein pour ne pas rendre ça trop facile à utiliser. Mais du coup, c'est pas clair si c'est faisable facilement en dehors du cas spécifique d'ubuntu 20.04 par défaut.
(et à mon grand regret, ssh-agent n'est pas confiné avec selinux sur ma Fedora)
[^] # Re: Bonnes pratiques
Posté par ǝpɐןƃu∀ nǝıɥʇʇɐW-ǝɹɹǝıԀ (site web personnel) . Évalué à 2.
À vous lire, l'attaque paraît délicate à employer. Ce qui m'intrigue c'est qu'il n'ait fallu que 14 jours entre le signalement (avec patch) et la mise à disposition par les distributions (chez moi la correction a été faite ce matin). Est-ce un délai court ? Standard ? N'est-ce pas une réaction digne d'une menace importante ?
« IRAFURORBREVISESTANIMUMREGEQUINISIPARETIMPERAT » — Odes — Horace
[^] # Re: Bonnes pratiques
Posté par Nils Ratusznik (site web personnel, Mastodon) . Évalué à 4.
Je suis tenté de dire qu'il vaut mieux corriger pendant que la vulnérabilité est encore difficile à exploiter, plutôt que d'attendre une exploitation massive dans la nature et que "tout le monde" doive appliquer des correctifs en urgence.
[^] # Re: Bonnes pratiques
Posté par Misc (site web personnel) . Évalué à 4.
Ouais enfin, il faut 1) être root sur la machine en face 2) avoir quelqu'un qui utilise un forward d'agent.
Si 1 et 2 sont remplis, il faut bien voir que tu es déjà dans la merde vu que root peut juste taper dans ton socket et utiliser ta clé, et par exemple, dans des cas hypothétiques, faire un ssh pour revenir vers ta propre machine avec ton compte, ou ce genre de choses.
Je dit pas qu'il faut pas corriger, mais clairement, je pense qu'il n'y a pas trop lieu de paniquer dans la grande majorité des cas.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.