Ce que l’on sait de la porte dérobée xz Utils qui a failli infecter presque toute la planète
(arstechnica.com)- Andres Freund de Microsoft a découvert une porte dérobée implantée dans xz Utils, utilisé dans presque tous les environnements Linux/Unix, en remontant une anomalie de performances SSH sur des systèmes Debian
- Le code malveillant a été introduit dans xz Utils 5.6.0 et 5.6.1 et a été conçu pour permettre à un attaquant disposant d’une clé privée spécifique de dissimuler du code dans un certificat de connexion SSH afin de l’exécuter sur un appareil compromis
- L’attaquant a cherché à détourner la chaîne via des tarballs de release plutôt que le code source GitHub, des fichiers de test, des scripts de build et IFUNC de glibc pour accrocher la routine d’authentification de sshd en passant par liblzma
- La porte dérobée vérifiait les conditions de build amd64/x86_64, glibc et les paquets Debian ou de la famille Red Hat, et a été incluse dans Fedora Rawhide, Fedora 41, Debian testing/unstable/experimental, openSUSE Tumbleweed/MicroOS et certaines releases de Kali Linux sur une période donnée
- Une persona de développeur nommée Jia Tan a participé pendant des années à la maintenance de xz Utils, l’incident est suivi sous CVE-2024-3094, et des outils de détection et d’analyse comme la page d’inspection Binarly et xzbot ont émergé
Découverte et périmètre d’impact
- Andres Freund, développeur et ingénieur travaillant chez Microsoft sur PostgreSQL, a repéré un comportement anormal en enquêtant sur un login SSH qui consommait trop de CPU et déclenchait des erreurs valgrind sur des systèmes Debian
- La cause était une mise à jour de xz Utils, et Freund a révélé sur l’Open Source Security List qu’il s’agissait d’une porte dérobée intentionnellement implantée dans ce logiciel de compression
- xz Utils fournit la compression et la décompression de données sans perte sur presque tous les systèmes d’exploitation de la famille Unix, y compris Linux, et prend aussi en charge l’ancien format .lzma
- Filippo Valsorda a estimé qu’il pourrait s’agir de « l’exemple le mieux exécuté d’attaque de la chaîne d’approvisionnement décrit publiquement, avec le scénario cauchemardesque d’un upstream malveillant, compétent et autorisé dans une bibliothèque largement utilisée »
Ce que visait la porte dérobée
- Le code malveillant a été ajouté dans xz Utils 5.6.0 et 5.6.1, modifiant la manière dont le logiciel se comporte
- La porte dérobée manipulait sshd, l’exécutable utilisé pour les connexions SSH distantes
- Une personne disposant d’une clé cryptographique prédéfinie pouvait dissimuler le code de son choix dans un certificat de connexion SSH, l’envoyer, puis le faire exécuter sur l’appareil compromis
- Le code réellement envoyé n’ayant pas été identifié, on ne sait pas ce que les attaquants comptaient exécuter
- En théorie, cela pouvait permettre presque n’importe quelle action, y compris le vol de clés cryptographiques ou l’installation de malware
Comment la bibliothèque de compression a atteint SSH
- Une bibliothèque peut manipuler le fonctionnement interne des exécutables qui lui sont liés
- L’implémentation de référence de sshd dans OpenSSH n’est pas liée à liblzma par défaut
- Debian et plusieurs distributions Linux ajoutent un patch reliant sshd à systemd
- systemd est le programme qui charge plusieurs services au démarrage
- systemd est lié à liblzma
- Ce chemin de dépendance a permis à xz Utils d’affecter sshd
Des signes de préparation sur plusieurs années
- En 2021, un utilisateur nommé JiaT75 a laissé son premier commit connu dans un projet open source
- Dans le projet libarchive, ce changement remplaçait la fonction safe_fprint par une variante depuis longtemps connue comme moins sûre, sans que personne ne le remarque à l’époque
- En 2022, JiaT75 a soumis un patch à la mailing list de xz Utils
- Peu après, un nouveau contributeur nommé Jigar Kumar a fait pression en affirmant que Lasse Collin ne mettait pas à jour xz Utils assez souvent ni assez rapidement
- Dennis Ens et d’autres nouveaux contributeurs ont eux aussi poussé Collin à intégrer davantage de mainteneurs
- En janvier 2023, JiaT75 a signé son premier commit dans xz Utils et s’est impliqué plus profondément sous le nom de Jia Tan
- Il a remplacé le contact de Collin par le sien dans oss-fuzz
- Il a demandé de désactiver la fonctionnalité IFUNC pendant les tests oss-fuzz, ce qui a empêché la détection ultérieure des changements malveillants ajoutés à xz Utils
- En février 2024, Tan a publié les commits de xz Utils 5.6.0 et 5.6.1, qui implémentaient la porte dérobée
- Ensuite, Tan ou d’autres personnes ont demandé à des développeurs Ubuntu, Red Hat et Debian d’intégrer cette mise à jour dans leurs systèmes d’exploitation
Distributions touchées et conditions d’exécution
- Selon Tenable, les versions backdoorées ou mises à jour associées ont été intégrées dans les releases suivantes
- Fedora Rawhide : la distribution de développement de Fedora Linux
- Fedora 41
- Debian testing, unstable, experimental : de 5.5.1alpha-0.1 à 5.6.1-1
- openSUSE Tumbleweed et openSUSE MicroOS : inclusion de versions xz backdoorées entre le 7 et le 28 mars
- Kali Linux : inclusion de xz-utils 5.6.0-0.2 entre le 26 et le 28 mars
- Selon l’analyse de Sam James, le script malveillant vérifiait que la cible de build était amd64/x86_64, utilisait le nom linux-gnu et s’appuyait sur GCC et GNU ld
- Il vérifiait aussi s’il s’agissait d’un build de paquet Debian ou si RPM_ARCH était x86_64
- L’attaque semble avoir visé des environnements construisant des distributions dérivées de Debian ou Red Hat sur des systèmes amd64 utilisant glibc
- On ne savait pas alors si d’autres systèmes étaient vulnérables
Mode d’implémentation et techniques de dissimulation
- Sam James a résumé la porte dérobée comme un ensemble de plusieurs composants
- Le tarball de release distribué par l’upstream n’était pas identique au code disponible sur GitHub
- Le build-to-host.m4 du tarball de release différait fortement de celui de l’upstream GitHub
- Le dossier tests/ du dépôt git contenait des fichiers de test manipulés
tests/files/bad-3-corrupt_lzma2.xztests/files/good-large_compressed.lzma
- Un script appelé par build-to-host.m4 décompressait les données de test malveillantes et modifiait le processus de build
- L’IFUNC de glibc servait à accrocher ou rediriger à l’exécution la routine d’authentification d’OpenSSH
- HD Moore a confirmé que l’étape finale de la porte dérobée ne s’exécutait que lors de la compilation de la bibliothèque sur amd64 et de la création de paquets Debian ou RPM
- Selon l’analyse des chercheurs, si une fonction d’empreinte particulière et une clé publique donnée correspondaient pendant la vérification d’une clé publique SSH, le contenu de la clé était déchiffré avec une clé prépartagée avant même la validation réelle de la clé publique
- Si le contenu déchiffré correspondait à un format précis, il était transmis directement à
system - Si l’empreinte ne correspondait pas ou si le contenu déchiffré n’avait pas le bon format, le processus revenait à la validation normale de la clé, rendant la différence difficile à remarquer pour l’utilisateur
La chaîne d’exécution décrite par Akamai
- Les chercheurs d’Akamai estiment que la porte dérobée a été incluse uniquement dans les releases tarball du code source, et non dans le dépôt GitHub de xz, afin d’échapper à la détection
- La porte dérobée était répartie sur plusieurs commits
- Pendant le build, l’usage d’IFUNC permettait au malware d’intercepter la fonction de résolution des symboles
- Un objet partagé obfusqué était caché dans les fichiers de test
- Un script s’exécutait pendant le build de la bibliothèque pour extraire cet objet partagé
- La fonctionnalité de sécurité landlocking, qui limite les privilèges du processus, était désactivée
- La chaîne d’exécution se déroulait en plusieurs étapes
build-to-host.m4s’exécutait pendant le build de la bibliothèque et décodaitbad-3-corrupt_lzma2.xzen script bash- Ce script bash décodait ensuite
good-large_compressed.lzmad’une manière plus complexe afin de produire un autre script - Ce script extrayait l’objet partagé
liblzma_la-crc64-fast.oet l’ajoutait au processus de compilation de liblzma
- Cet objet partagé était compilé dans liblzma pour remplacer le processus normal de résolution des noms de fonction
- La bibliothèque malveillante pouvait remplacer le pointeur de fonction
RSA_public_decryptd’OpenSSH par une fonction malveillante qu’elle avait créée - Selon l’analyse de Filippo Valsorda, cette fonction malveillante extrayait des commandes du certificat du client d’authentification, vérifiait qu’il s’agissait bien de l’acteur menaçant, puis les transmettait à
system()pour obtenir une exécution de code à distance avant authentification
Jia Tan et les questions restantes
- On dispose de très peu d’informations sur Jia Tan
- Cette persona de développeur a participé à des dizaines d’autres logiciels open source au cours des dernières années
- On ignore s’il y avait une personne réelle derrière le nom d’utilisateur Jia Tan ou s’il s’agissait d’un personnage entièrement fabriqué
- Des analyses techniques supplémentaires sont disponibles dans le fil Bluesky de Filippo Valsorda, l’analyse de Kevin Beaumont et les informations publiées par Freund le vendredi
CVE et outils de vérification
- L’identifiant de suivi de cette vulnérabilité est CVE-2024-3094
- La page xz.fail de Binarly détecte l’implémentation IFUNC et s’appuie sur une analyse comportementale
- Elle peut automatiquement détecter des invariants même si une porte dérobée similaire est implantée ailleurs
- xzbot fournit des fonctions d’analyse et d’expérimentation
- honeypot : faux serveur vulnérable pour détecter les tentatives d’exploit
- ed448 patch : patch de
liblzma.sopour utiliser sa propre clé publique ED448 - backdoor format : format de payload de la porte dérobée
- backdoor demo : CLI qui déclenche la RCE en supposant la connaissance de la clé privée ED448
1 commentaires
Avis de Hacker News
L’objectif était de faciliter l’écriture de tests pour XZ en utilisant un framework de test standardisé
Jia écrivait le 17/06/2022 qu’il restait beaucoup de fonctionnalités non testées, et que cela aiderait à augmenter la couverture de tests pour la stabilité à long terme du projet
C’était donc un changement préparé de longue date
Le mécanisme de linkage qui a permis à la lib de s’interposer sur
RSA_public_decryptne semble pas avoir été beaucoup discutéOn parle beaucoup de séparation de processus, mais peu de cette redirection d’appel de fonction
Je me demande s’il ne serait pas possible de lier des composants critiques, comme le code entrant via SSH, avec des bibliothèques selon un modèle de confiance hiérarchique, du type « je fais confiance à ce que j’appelle à cet endroit, mais je ne l’autorise pas à s’insérer de lui-même dans d’autres points d’appel »
Cela peut susciter le réflexe habituel du « security through obscurity », au motif qu’il existe des contournements et que cela ne sert donc à rien, mais on peut tout de même y voir une réduction de la surface d’attaque
Cela dit, dans les systèmes d’exploitation, plusieurs contextes de sécurité se superposent. Pour la backdoor XZ, il s’agit surtout de sécurité à base de capabilities au niveau des modules, mais il existe aussi des capabilities au niveau des programmes, de l’isolation mémoire au niveau de la pagination, de l’isolation au niveau microarchitectural, etc.
Faire fonctionner tout cela ensemble tout en conservant de bonnes performances est assez difficile, et il semble pratiquement impossible que les systèmes de type Unix passent à ce modèle, car il faudrait remplacer le concept même de processus
C’est ce qui a cassé les tests de XZ, puis des comptes sont soudainement apparus pour faire pression afin de désactiver ces tests, ce qui a rendu l’exploit possible
./configure && make) pour patcher l’ifunc resolver et lui faire appeler l’objet malveillant fourniLe fichier objet compromis est lié avec le flag de linker
now, ce qui force la résolution immédiate de l’ifunc au chargement de la bibliothèque ; à ce moment-là, la table de linkage du processus est encore modifiable, et le resolver patché est appeléC’est précisément le point important : au chargement de la bibliothèque, elle pouvait simplement intercepter en mémoire la fonction
RSA_public_decryptUn article qui analyse très bien le processus d’injection de la backdoor : https://research.swtch.com/xz-script
dlopenavec les bibliothèques de compression : https://github.com/systemd/systemd/pull/31550En ce sens, c’est une méthode de linkage plus sûre
ltracesurveille les symboles appelésJe ne comprends pas pourquoi on dit que cela a « presque » infecté le monde entier
Au moins trois distributions Linux assez populaires, Arch, Gentoo et openSUSE Tumbleweed, ont distribué la backdoor pendant plusieurs semaines, et elle fonctionnait clairement sur Tumbleweed
Pendant plusieurs semaines, SSH contenait une backdoor ; « presque » me paraît donc trop faible
Il ne fonctionnait que sur les cibles deb/rpm, donc, dans les faits, il a été stoppé avant d’atteindre la production
Cela ne veut pas dire que ce n’est pas grave ; si cela était resté inaperçu assez longtemps pour arriver dans RHEL ou Debian/Ubuntu stable, des banques ou des établissements de santé auraient reçu des alertes
Avec une exécution de code à distance avant authentification, il aurait été difficile de dire « nous ne sommes pas affectés », sauf pour les organisations ayant un réseau très strictement limité et une bonne journalisation des flux
En comparant les
liblzma.so.5.6.1dexz-5.6.1-1etxz-5.6.1-2aveccmp -l, on ne voit que de très petites différencesIl semble que cela n’était pas connu avant la rédaction de l’avis
https://github.com/QubesOS/qubes-issues/issues/9067#issuecom...
Cela dit, je ne sais pas comment obtenir des données pour l’étayer
Je parierais 101 dollars que quelque chose de similaire sera découvert en environnement réel dans les 12 prochains mois
Parce que les mainteneurs vont commencer à examiner avec suspicion les anciens commits les uns des autres
Il suffit de regarder les bases de code importantes mais peu connues, avec très peu de mainteneurs
Si j’avais eu quelque chose comme ça et que cela fonctionnait bien, je l’aurais probablement fait « découvrir » plus tard par un autre compte pour le faire corriger
Voici les conclusions personnelles que je tire de cette affaire
Premièrement, les tarballs de distribution des sources contenant un code différent de celui du dépôt source sont une mauvaise chose, et il faut s’en éloigner. Une autre grande attaque de la chaîne d’approvisionnement, event-stream, avait exploité quelque chose de similaire
En conséquence, les artefacts générés automatiquement devraient toujours être commités
Deuxièmement, les artefacts générés automatiquement que tout le monde fait défiler avec Page Down lors des revues de code posent problème. Si ce genre de fichiers se trouve dans le dépôt, il faut aussi des tests automatiques pour vérifier que personne ne les a modifiés, et pour éviter de laisser traîner de vieux fichiers générés automatiquement
Troisièmement, par conséquence des points 1 et 2, autotools est mauvais, et la culture autotools l’est aussi
Quatrièmement, Libsystemd est un problème pour l’écosystème. Quand on dit ça, on est catalogué comme anti-systemd, mais c’est gros, complexe, avec beaucoup de dépendances, et la plupart des programmes n’en utilisent qu’une toute petite partie. Encourager tous les services à en dépendre pour les notifications d’initialisation est insensé
Cinquièmement, il existe une culture selon laquelle la réutilisation de code est toujours une bonne chose, et qu’il est acceptable de dépendre d’une grosse bibliothèque pour une petite fonctionnalité. Ce n’est pas vrai. Les dépendances sont une charge de maintenance et un risque de sécurité, et il faut les mettre en balance avec les fonctionnalités qu’elles apportent
Sixièmement, le fait que les mainteneurs de distributions appliquent de gros patches aux paquets pose aussi problème. Cela crée des forks de fait, largement utilisés, de bibliothèques et d’applications que les vrais mainteneurs ne surveillent pas
Septièmement, du point de vue des développeurs, l’OSS doit devenir financièrement soutenable. Liblzma et xz-utils ont probablement des dizaines de millions d’installations, mais reposaient sur un seul mainteneur qui avait des problèmes de santé mentale
Huitièmement, je n’aime pas le dire, mais aujourd’hui il faut aussi prendre en compte les considérations géopolitiques dans les revues de code et les transferts de droits de maintenance
Rien ne prouve que Jia Tan soit un vrai nom, ni même qu’il s’agisse d’une personne réelle
Si les projets commencent à refuser les contributions de personnes dont le nom sonne asiatique, la prochaine attaque n’aura qu’à utiliser le nom Richard Jones
Quand on vient du monde BSD, systemd est un choc : monstrueux, avec des tentacules partout
Les consommateurs sont naïfs, mais l’industrie logicielle elle-même l’est aussi face aux menaces de sécurité
Les exploits sociaux font partie des exploits de code
Le principe du FOSS selon lequel « plus il y a d’yeux sur le code, mieux c’est » est juste, mais il ne fonctionne que si ces yeux sont formés. Le FOSS a besoin d’un soutien matériel de l’industrie
C’est un ingénieur MSFT qui a repéré cet exploit, mais il s’est quand même retrouvé dans les versions publiques générales de Fedora 41, openSUSE et Kali
La chaîne d’outils de développement et les processus de test n’ont jamais été conçus pour tester la sécurité. SolarWinds est aussi un exemple à méditer : https://www.wired.com/story/the-untold-story-of-solarwinds-t...
Les artefacts de release ne contiennent pas seulement des scripts autoconf
Il y a beaucoup de raisons d’inclure des blobs binaires dans une archive de release : ressources de jeux, images de firmware, cas de test, etc. On disait par exemple que mpv incluait comme cas de test certains fichiers média générés avec des encodeurs propriétaires ; ce n’est pas une mauvaise chose, c’est une bonne chose
sqlite, qui est bien maintenu, est utilisé partout et dispose aussi d’une excellente suite de tests. À chaque release, il publie non pas un mais deux tarballs, correspondant à deux étapes de compilation. Il serait facile d’arrêter de le faire, mais cela ne ferait qu’augmenter le travail des mainteneurs de paquets, sans améliorer la sécurité
Si Debian construit à partir de tarballs sélectionnés, c’est parce qu’ils sont sélectionnés par des humains et signés avec des clés bien connues. Bien sûr, on pourrait aussi construire depuis git, mais il n’est pas certain que cela améliorerait la situation. Tous les projets ne signent pas leurs tags de release, et même quand ils le font, il est plus probable que ce soit automatisé
Nous voulons que les changements soient examinés d’abord par les mainteneurs upstream, puis par les mainteneurs de paquets, et nous préférons que ces deux acteurs soient indépendants l’un de l’autre
Cette fois-ci, un mainteneur upstream compromis a attaqué ce processus, mais cela ne veut pas dire qu’il faut supprimer les mainteneurs upstream. Ces dernières années, cette structure a permis de bloquer plusieurs tentatives de backdoor, et ce n’est pas un processus à abandonner sans examen attentif
Les pistes d’amélioration répétées depuis longtemps restent les mêmes : poursuivre davantage les builds reproductibles, réduire si possible la surface d’attaque et la complexité de build, et faire confiance aux mainteneurs tout en vérifiant leur travail
Au contraire, ils semblent eux-mêmes perplexes sur ce point et ajoutent de la documentation sur la manière d’implémenter un simple datagramme sans libsystemd
Le nombre d’installations de liblzma et xz-utils est probablement bien supérieur à quelques dizaines de millions. Beaucoup de langages comme Python, PHP, Ruby, etc. dépendent de libxml2, et libxml2 utilise liblzma. Il y a aussi beaucoup d’autres dépendances
Les considérations géopolitiques ne relèvent pas du travail des mainteneurs. L’OSS est fourni sans garantie
De plus, « Jia Tan » était peut-être entièrement fictif. Les horodatages des commits montrent que, même le même jour, le fuseau horaire passait de l’Europe de l’Est à l’Asie. Il est au moins clair qu’il y avait un jeu d’identités
Je ne savais pas que la personne qui avait découvert ce problème était un ingénieur Microsoft travaillant sur Azure Postgres
Merci Microsoft, maintenant j’aime mieux Azure
C’est comme ça que ce problème a été découvert
Ensuite, il faudrait regarder les bibliothèques concernées et chercher des anomalies similaires où une fausse persona prend le contrôle d’un projet
Ignorer ce genre d’erreurs semble être une pratique courante
Je ne supporte vraiment pas ce genre de présentation
Il semble que le mainteneur d’origine de xz ait transmis la responsabilité à Jia Tan sans l’avoir rencontré en personne, ni même au moins lui avoir parlé au téléphone
Je me demande s’il est courant de communiquer uniquement par e-mail ou via GitHub
Après cette affaire, certains mainteneurs de projets open source vont probablement devenir plus prudents
Moi aussi, il m’est arrivé de communiquer uniquement par texte avec des gens dont je ne savais absolument pas qui ils étaient réellement, puis de reprendre ou de transmettre la maintenance d’une bibliothèque
Mais tirer de cette affaire la conclusion que « les mainteneurs devraient être plus prudents » me paraît complètement erroné
La responsabilité de ce que les gens intègrent à leurs propres projets n’incombe pas aux mainteneurs, mais aux personnes qui travaillent sur ces projets
Soit on fait confiance au mainteneur, soit on ne lui fait pas confiance ; dès qu’on commence à dépendre d’une bibliothèque, on accepte implicitement de continuer à mettre à jour la liste des personnes auxquelles on fait confiance
Des millions d’entreprises profitent gratuitement du travail de développeurs open source non rémunérés
Il n’est donc pas surprenant qu’ils s’en aillent et que des problèmes apparaissent
Quelle confiance supplémentaire cela aurait-il apportée quant aux intentions de cette personne ?
J’ai participé à environ six projets open source de tailles diverses, allant de 100 à 30 000 étoiles GitHub, et je n’ai jamais parlé à personne au téléphone ; la communication écrite était la norme
Mais connaître personnellement quelqu’un ne résout pas forcément le problème
Il y a longtemps, j’ai travaillé anonymement sur un projet open source dont je ne veux pas citer le nom ici. Le programmeur principal avait un co-mainteneur qu’il semblait assez bien connaître
Ce co-mainteneur n’a cessé de faire du gaslighting envers moi puis envers d’autres mainteneurs par la suite, de nous rabaisser et de nous pousser au départ en nous accusant pour des bugs minuscules. Une fois les insultes retirées, ce n’était même pas comparable aux engueulades pédagogiques façon Linus Torvalds
Le mainteneur principal l’encourageait parce qu’il était d’accord avec le fond technique de ses reproches
Quelques années plus tard, ce co-mainteneur a tenté une prise de contrôle hostile du projet, et les choses ne se sont pas passées comme prévu. Peu après, plusieurs correspondances privées ont été rendues publiques, révélant qu’il avait toujours voulu cela et que le gaslighting des autres mainteneurs faisait partie de cet objectif
Tout cela s’est produit alors même que les deux personnes se connaissaient
Tout le monde pense que cette backdoor a été découverte tôt, mais elle a peut-être déjà atteint son objectif
Cela pourrait notamment être le cas si les cibles étaient des développeurs utilisant des distributions en rolling release comme Kali ou Debian
En début de semaine, j’ai regardé un peu le trafic SSH, mais je n’y ai pas vraiment prêté attention à ce moment-là
Bien sûr, c’est peut-être une fausse piste : https://www.nubi-network.com/news.php?id=21
Le mème du type « Lasse Collin ne mettait pas xz Utils à jour assez souvent ou assez rapidement » était une erreur
Je ne comprends pas pourquoi SSH utiliserait xz
Est-ce vraiment nécessaire ? Est-ce si important que ça ?
OpenSSH a embarqué libsystemd pour fournir des notifications de démarrage, et libsystemd a embarqué liblzma. En temps normal, le code de liblzma ne se retrouve pas dans OpenSSH
Mais comme il est construit en tant que dépendance de libsystemd, le script de build s’exécute dans le même environnement que libsystemd et OpenSSH
La charge utile de l’attaque était dissimulée dans le répertoire de tests de liblzma, sous la forme d’un blob binaire obfusqué déguisé en cas de test de compression
Lorsqu’on compilait lzma depuis les sources git et qu’on générait les scripts de build avec autotools, rien de suspect ne se produisait. En revanche, dans les tarballs source utilisés par les packagers des distributions, autotools avait déjà été exécuté, et l’attaquant avait remplacé la sortie générée automatiquement et difficile à lire du script
Ce script vérifiait si liblzma était compilé dans le même environnement qu’OpenSSH, et s’il était compilé pour être intégré à un paquet
.debou.rpm; si les deux conditions étaient vraies, il injectait la charge utile dans OpenSSHEnsuite, la charge utile effectuait plusieurs vérifications : si OpenSSH avait été lancé normalement par un script d’init ou manuellement, si des outils de débogage courants étaient présents, etc., et ne s’attachait au processus en cours que lorsque cela ressemblait à un démarrage « naturel » sans outils de débogage
Une fois en cours d’exécution, elle accrochait la vérification des clés privées et, lorsqu’une clé privée correcte tentait de se connecter, appelait le reste du paquet entrant via
system, fournissant une exécution de code à distance avec les droits root