La découverte accidentelle d'une porte dérobée a probablement empêché des milliers d'infections

[Le message est apparu en premier sur Deepfactor] La découverte hier de la porte dérobée xz était un accident. Mais quel heureux accident ce fut. L'acteur (ou les acteurs, nous ne le savons pas encore) faisait des efforts assidus depuis longtemps et n'a commencé que très récemment à rassembler toutes les pièces de ce qui a fini par être découvert hier. La porte dérobée est appelée à tort « porte dérobée ssh » ; c'est un peu trompeur. OpenSSH n'utilise pas xz lui-même, mais les responsables de la distribution Linux ont lié xz à sshd lors de sa construction (apparemment pour une intégration plus facile avec systemd). En fait, xz est lié à tellement de packages qu'il ne sera peut-être jamais possible de déterminer pleinement la portée de ce que la porte dérobée aurait pu faire.

""Je ne suis pas un chercheur en sécurité, ni un ingénieur inverse."" Andres Freund a posté sur la liste de diffusion oss-security que lors de tests de problèmes de performances ssh étranges et de plantages de valgrind, la porte dérobée a été découverte. Il est important de noter qu'Andres n'est pas un chercheur en sécurité (le titre de cette section est celui écrit par Andres dans la divulgation) ; ce qui signifie que ce n'était pas quelque chose qui était activement recherché, mais plutôt quelque chose sur lequel on était tombé par hasard.

Ce fut une découverte incroyablement heureuse ; comme mentionné précédemment, xz est utilisé partout. Même s'il est probable que ssh soit la cible probable, nous ne le saurons peut-être jamais. La porte dérobée a injecté du code dans liblzma via des modifications obscurcies et obscures introduites dans le script de configuration de xz. L'intention déclarée de ce changement était d'améliorer les tests, en utilisant certains fichiers .xz prédéfinis comme binaires de test. En réalité, ces binaires de test contenaient en fait le code injecté dans sshd.

Maintenant, soyons honnêtes. Combien de développeurs inspectent chaque script de configuration pour toutes les dépendances qu'ils créent eux-mêmes ? Libtool, autoconf, automake et Friends ont été créés spécifiquement pour que vous n'ayez pas besoin d'inspecter ces scripts de configuration à la main (et dans ce cas, personne ne l'a fait). Pire encore, si vous comptez sur des dépendances provenant de tiers, avez-vous vraiment confiance qu'ils le font avec diligence ?

Ces changements ont été lentement introduits par « Jia Tan » (probablement pas un vrai nom et il est également possible qu'il s'agisse d'un groupe d'individus ou d'un État-nation) avec d'autres faux comptes apparus au cours des dernières années encourageant les changements. C'était certainement l'acte d'un individu ou d'un groupe jouant sur le long terme.

Il a été rapporté que fin février, « Jia Tan » avait contacté d'autres responsables de la distribution Linux, exerçant des pressions pour inclure les versions dérobées de xz dans leurs distributions, sous couvert de « nouvelles fonctionnalités intéressantes ». Pourquoi xz, une bibliothèque dont les fonctionnalités sont essentiellement complètes depuis des années, aurait besoin de « nouvelles fonctionnalités intéressantes » me dépasse, mais nous y sommes. Quoi qu'il en soit, la bibliothèque dérobée a commencé à se frayer un chemin dans les distributions de versions continues et les versions préliminaires d'autres.

Et puis, nous avons tous eu beaucoup de chance avec la découverte de la porte dérobée. Si la porte dérobée n'avait pas introduit d'erreurs valgrind ou de problèmes de performances ssh, dans six mois, nous aurions pu être confrontés à des milliers de machines compromises lors de leur mise à niveau progressive vers de nouvelles versions de distribution. Il s'avère que quelques distributions incluaient la bibliothèque affectée, mais pour l'essentiel, l'écosystème a été épargné par un désastre plus important.

Lier toutes les choses dans sshd Base OpenSSH, tel que fourni par le projet OpenSSH, ne nécessite aucune bibliothèque tierce pour les fonctionnalités par défaut. Probablement en raison de motivations commerciales inconnues, sshd dans certaines distributions a été lié à un univers de bibliothèques sous couvert de « fonctionnalités croissantes ». Chaque fois qu'une dépendance est liée à une application comme celle-ci, l'application hérite de tous les bugs et problèmes de cette dépendance. La raison présumée de la liaison de xz, dans ce cas, était de permettre à sshd de devenir plus facilement contrôlable par systemd. C'est cette décision qui a exposé ces distributions à la porte dérobée. À mesure que systemd consomme lentement l'univers Linux, nous en verrons de plus en plus.

Ma propre expérience En guise d'expérience en préparation à la rédaction de ce blog, j'ai lancé quelques machines virtuelles et examiné combien de bibliothèques externes étaient liées à sshd pour chacune. Les résultats m'ont surpris, mais je suppose que je n'aurais pas dû être aussi surpris que je l'ai été.

| Distribution | Nombre de dépendances de bibliothèque pour sshd | |------------------------|------------------------ ----------------| | OpenBSD 7.5 (de base) | 4 | | Linux alpin 3.19 | 4 | | Gentoo | 5 (*) | | OracleLinux 9.1 | 26 | | Rocheux Linux 9.2 | 26 | | Ubuntu 22.04 | 26 | | CentOS 8 | 30 | | CentOS 7 | 47 |

(*) Pour Gentoo, j'ai fait apparaître l'ebuild openssh en utilisant les paramètres USE par défaut (par exemple, quel que soit le manuel d'utilisation indiqué). En fonction des paramètres USE, cela peut être plus important dans certains cas. Mon installation Gentoo utilisait OpenRC, pas systemd.

Les valeurs du tableau précédent ont été collectées en exécutant ldd sur le binaire openssh sshd et en déduisant le nombre d'éléments courants tels que ld.so, les entrées vdso et le binaire lui-même.

Remarque : En général, vous ne devez jamais exécuter ldd sur des fichiers binaires non fiables. Mes tests ont été effectués sur des machines virtuelles jetables et isolées pour cette raison.

Comme vous pouvez le voir, certaines distributions proposent des binaires sshd assez fins, ne reliant que des éléments tels que libc et pthreads, tandis que d'autres relient simplement l'univers entier au binaire. Certes, certaines des distributions répertoriées (par exemple, CentOS 7) sont très anciennes et approchent ou dépassent la fin de vie, mais vous pouvez voir qu'il y a un énorme écart entre les distributions qui se soucient de la minceur et d'une empreinte de sécurité plus petite et celles qui ne le font pas. Au fil du temps, le nombre semble diminuer, mais même le sshd le plus mince de ces distributions « gonflées » lie 5 à 6 fois plus de dépendances que le plus mince de la liste.

""Vous ne pouvez pas avoir de bugs dans un code que vous n'avez pas"" L'un des problèmes liés à la création de liens dans une énorme liste de dépendances est que vous êtes confronté aux vulnérabilités associées à chacune, même si vous ne vouliez pas ou n'aviez pas besoin des fonctionnalités de cette dépendance. Cela rend le suivi et la correction des vulnérabilités de votre application plus difficiles qu'ils ne devraient l'être. Par exemple, certaines des distributions répertoriées ci-dessus sont liées aux bibliothèques sshd pour prendre en charge les connexions Kerberos et par carte à puce. Combien d'installations nécessitent cela ? 5% ? dix%? Néanmoins, afin de couvrir tous les cas d'utilisation professionnels possibles, ces distributions ont décidé que tout le monde bénéficierait de ce support, juste au cas où. Cela expose désormais toutes les vulnérabilités de ces bibliothèques à l'ensemble de la communauté.

Alors que peux-tu faire? Peu de gens vont construire leur propre sshd indépendamment du responsable de la distribution, car emprunter cette voie entraîne de nombreux autres maux de tête. Nous sommes donc essentiellement coincés avec des packages potentiellement vulnérables, sans que ce soit de notre faute.

Aide! L'une des choses que nous faisons chez Deepfactor est d'aider les clients à comprendre leur situation de vulnérabilité et leurs priorités de remédiation en fonction de l'analyse de l'utilisation du runtime. Nous pouvons vous indiquer spécifiquement quelle dépendance vulnérable a été chargée en mémoire et exécutée. Ainsi, lorsque des choses comme celle-ci se produisent, vous pouvez rapidement placer la correction la plus importante en haut de la liste. À l'inverse, nous pouvons également vous indiquer ce qui n'est pas utilisé, afin que vous puissiez retirer ces mines terrestres de votre environnement. Bien que les anciens outils SCA (que nous appelons SCA 1.0) puissent répertorier les dépendances que vous avez dans votre environnement, ils ne sont pas en mesure de vous indiquer ce qui est réellement utilisé, ce qui est important dans ce cas.

Une dernière pensée Je pense que ce type d'attaque de la chaîne d'approvisionnement se poursuivra tant que nous aurons universellement utilisé des référentiels dont les responsables ont soit perdu tout intérêt pour la maintenance, soit ont complètement abandonné le code. Il existe de nombreuses autres bibliothèques open source en plus de xz qui entrent dans cette catégorie, et même si une bibliothèque universellement utilisée est maintenue aujourd'hui, rien ne garantit que cela continuera. Si un responsable se désintéresse de la maintenance de son code et qu'une personne aléatoire arrive et exprime son intérêt à prendre en charge la maintenance, pourquoi le responsable d'origine ne dirait-il pas « bien sûr, allez-y » ? Jusqu'à ce que ce problème soit résolu (et je ne suis pas sûr qu'il le sera un jour), des outils comme Deepfactor s'avéreront utiles pour vous protéger en vous indiquant à quel point vous êtes exposé et dans l'ordre dans lequel vous devez résoudre les problèmes.

Auteur

Ai Base Network (ABN), ABN ASIA a été fondée par des personnes ayant des racines profondes dans le milieu académique, avec une expérience professionnelle aux États-Unis, aux Pays-Bas, en Hongrie, au Japon, en Corée du Sud, à Singapour et au Vietnam. ABN ASIA est l'endroit où l'académie et la technologie rencontrent l'opportunité. Avec nos solutions de pointe et nos services de développement logiciel compétents, nous aidons les entreprises à se développer et à s'imposer sur la scène mondiale. Notre engagement : Plus vite. Mieux. Plus fiable. Dans la plupart des cas : moins cher également.

N'hésitez pas à nous contacter chaque fois que vous avez besoin de services informatiques, de conseils en matière de numérique, de solutions logicielles prêtes à l'emploi, ou si vous souhaitez nous envoyer des demandes de propositions (RFP). Vous pouvez nous contacter à l'adresse [email protected]. Nous sommes prêts à vous aider avec tous vos besoins technologiques.

© ABN ASIA