16
Nouvelles du projet openSUSE / News openSUSE : Ce que nous devons retenir de la porte dérobée XZ
source : https://news.opensuse.org/2024/04/12/learn-from-the-xz-backdoor/
traduction automatique en ligne ci-dessous en deux messages car l'article est trop long pour un seul
Ce que nous devons retenir de la porte dérobée XZ
12. avril 2024 | Dirk Müller | CC-BY-SA-3.0
Dans les coulisses
Quelques jours avant la divulgation publique de la porte dérobée XZ, l'équipe de sécurité des produits SUSE a eu un indice selon lequel il y avait quelque chose d'étrange dans les versions XZ 5.6.x. Je suis l'employé de SUSE et le packager openSUSE qui mettait à jour et incluait cette version dans openSUSE Tumbleweed, je me suis donc impliqué assez tôt. À ce moment-là, aucun contexte ni aucune information partagée lors de la divulgation publique initiale n’étaient disponibles. Cependant, cet indice était toute l’information dont nous avions besoin. Cela a changé notre façon de considérer un projet open source central et établi. Sans cela, les petites différences étranges dans l'étape de « configuration » du système de construction auraient été facilement ignorées.Un jour avant la divulgation, jeudi soir, la sécurité des produits SUSE a reçu un rapport plus long et détaillé d'Andres Freund via la liste de divulgation de sécurité des distributions partagées. La liste de distribution est une liste de diffusion cryptée où les distributeurs collaborent et se coordonnent sur la divulgation de problèmes de sécurité. Ce rapport a apporté de nouvelles connaissances selon lesquelles la porte dérobée XZ ciblait spécifiquement OpenSSH, qui est l'une des parties réseau de presque tous les systèmes Linux. Cela a encore accru notre niveau de menace d'être une porte dérobée d'accès à distance et nous a également amené à élargir nos efforts de communication prévus.
L'équipe de sécurité SUSE et moi avons commencé à analyser. La sécurité des produits SUSE est membre de divers forums de sécurité privés, comme la liste des distributions et CERT VINCE et autres, qui nous permettent de coordonner les correctifs entre les fournisseurs de logiciels et de préparer les mises à jour aux dates de divulgation. Avec les premières informations indiquant qu'il y avait quelque chose de suspect, il était relativement facile de trouver des éléments plus suspects sans ordre particulier :
- openSUSE et SUSE suivent les signatures d'artefacts de publication avec un trousseau de signatures fiables. Nous avons remarqué que la clé avec laquelle les artefacts étaient signés avait changé il y a quelque temps, nous avons donc dû mettre à jour notre trousseau de confiance pour le projet XZ. Nous avons vérifié qu'il y a eu un transfert de responsabilité entre le responsable et que le nouveau responsable a un accès direct aux validations ainsi que la possibilité de signer les versions et de les publier. Le réseau de confiance de cette nouvelle clé de signature n'était pas bien connecté, ce qui aurait pu déclencher une alerte, mais elle était signée par le précédent mainteneur et cela nous suffisait.
- En regardant l'historique des commits, il y a eu une vague de commits entre la dernière version bêta 5.5 et la version 5.6.0 dans un court laps de temps par ce nouveau responsable ; ne vient pas via une Pull Request et aucun examen ou discussion évident à ce sujet. C’était immédiatement préoccupant. Normalement, les projets ne font pas cela juste avant une nouvelle version majeure. L'examen de chaque validation a immédiatement montré que des fichiers de test étranges étaient validés et mis à jour dans la version 5.6.1, et qui n'avaient pas de mises à jour correspondantes dans le cadre de test ou dans le code du projet, ils étaient donc « inutilisés ». Normalement, les fichiers de test sont validés avec un correctif de code dans la même validation, ou avec une référence à un problème antérieur, ou à une validation abordée par le scénario de test. Pour un responsable expérimenté d’un projet en amont, cela semblait être un gros oubli. Les messages de validation étaient en quelque sorte plausibles mais n'avaient pas vraiment de sens, surtout si l'on compare les (petites) différences entre 5.6.0 et 5.6.1.
Depuis un certain temps, openSUSE n'utilise pas XZ pour la compression de nos packages RPM de distribution ; nous sommes passés à Zstd il y a quelque temps. Cependant, XZ est très largement utilisé dans la distribution, entre autres pour décompresser les sources de notre compilateur GCC que nous utilisons pour construire tout le reste de la distribution. Nous avons vérifié et constaté que la version potentiellement malveillante de XZ était utilisée pour créer notre compilateur actif openSUSE GCC, qui est utilisé dans toutes les autres versions de la distribution. Le pire des cas auquel penser ici est que le déballage des sources de construction du compilateur GCC a été modifié par le XZ malveillant et que nous avons un compilateur système qui n'est plus digne de confiance. Bien que nous ayons des vérifications de signature sur les sources (et que nous ayons sécurisé des copies de chaque entrée de source que nous avons utilisée n'importe où dans un magasin de confiance), nous ne vérifions pas si les sources décompressées sont réellement les sources dont la signature a été vérifiée avant le déballage.
Ainsi, même sans plus d’informations sur la porte dérobée, nous avons compris que l’impact dans le pire des cas pourrait être désastreux. Nous avons donc commencé à identifier les projets, produits et distributions concernés. Heureusement, cette liste s’est avérée assez restreinte. Une équipe ad hoc a été constituée pour gérer la suppression de la porte dérobée.
Suppression initiale de la porte dérobée pour nos utilisateurs
openSUSE Tumbleweed fournit un canal de mise à jour d'urgence que nous pouvons utiliser pour récupérer des régressions fatales dans les instantanés Tumbleweed réguliers. Ces phénomènes sont extrêmement rares grâce à notre pipeline de tests automatisés, mais ils surviennent. Nous avons injecté une rétrogradation de XZ dans ce canal de mise à jour d'urgence et avons commencé à créer une version intermédiaire d'instantané openSUSE dans laquelle la mise à jour malveillante de XZ a été supprimée. Cependant, en raison de la nature inconnue de la porte dérobée obscurcie, nous avions prévu la pire hypothèse. Nous avons commencé à collecter le nombre de packages qui ont été construits et publiés avec la construction du compilateur GCC suspect dans l'environnement de construction. C'était une très longue liste. De plus, comprendre l’inversion du code objet malveillant de la porte dérobée dans Ghidra nous prendrait encore quelques heures. Après une courte synchronisation, nous avons décidé d'opter pour la voie sûre et de jeter tous les paquets construits avec XZ/GCC potentiellement malveillants et avons commencé à les reconstruire tous avec uniquement les paquets provenant d'une sauvegarde sécurisée, pour restaurer l'intégrité de notre distribution le plus rapidement possible. openSUSE teste régulièrement ce « mode bootstrap » dans le cadre du développement de notre distribution et s'appuie sur l'automatisation de la reconstruction fournie par l' Open Build Service , ce n'était donc pas beaucoup de travail humain. C'était juste beaucoup de charge pour notre cluster de build. Nous avons attendu quelques heures devant nous, ce qui a permis une analyse plus approfondie de la porte dérobée.Analyse de la porte dérobée
L’analyse du code objet s’est avérée prendre beaucoup de temps. Même si la deuxième étape qui vérifiait les bonnes conditions de build (s'agit-il d'une version de distribution, dispose-t-elle de l'environnement de compilateur attendu, etc.) était facile à décoder et nous a aidé à comprendre l'impact potentiel, au départ, nous ne savions pas vraiment quoi. le code objet obscurci qui a été injecté lors de la construction fonctionnait.En utilisant Ghidra, nous avons pu récupérer du code C quelque peu lisible à partir du code machine injecté, nous avons donc commencé à essayer de déchiffrer le puzzle. Repérer le point d'entrée dans la _get_cpuid fonction qui faisait partie de la gestion IFUNC a été l'une des premières découvertes. Le simple fait de rechercher cette combinaison de mots sur Google a conduit à une discussion en amont, à la désactivation d'ifunc dans le projet oss fuzz et à un rapport de bug intéressant dans la communauté Fedora où des problèmes de Valgrind ont été signalés avec XZ 5.6.0 et apparemment, l'amont les corrigeait en mettant à jour. des choses sans rapport, y compris « les fichiers de test » dans le référentiel. Il y avait non seulement des commits dans le dépôt, mais aussi une communication trompeuse autour du problème directement lié à ces commits, ce qui montrait évident que nous ne trouvions pas un accident malheureux provoqué par un responsable innocent qui aurait pu être piraté, mais une action planifiée de la part du responsable actuel. responsable en amont. Juste au cas où les sonnettes d'alarme ne seraient pas déjà assez fortes, cela a doublé leur niveau sonore.
Préparation à la divulgation publique
En combinant tout ce que nous avons appris jusqu’à présent, le tableau est devenu plus clair. Quelqu'un avait passé des années de préparation à préparer le terrain, à se bâtir une bonne réputation de mainteneur, à reprendre le projet, puis à choisir un moment qui était une fenêtre critique pour plusieurs projets de distribution et également au milieu du Nouvel An lunaire. comme d'autres jours fériés pour publier une nouvelle version avec de nouvelles fonctionnalités et une porte dérobée obscurcie qui a été bien conçue pour cibler uniquement des distributions spécifiques, à savoir celles utilisant GCC, Binutils, Glibc avec RPM ou les processus de construction Debian sur x86_64.En gardant tout cela à l’esprit, nous avons réalisé que ce sujet allait faire l’objet d’une grande couverture publique. Cela fera la une des journaux pendant des jours, voire des semaines. Nous avons donc lancé un nouveau chantier pour nous y préparer avec les équipes de communication.
Divulgation publique
Au moment de la divulgation publique, tous les axes de travail étaient déjà terminés. Nous avons identifié la liste des produits concernés et avons déjà publié toutes les mises à jour pour tous les produits concernés. La communication était prête à être mise en ligne et envoyée aux parties concernées. Tout cela a été possible parce que de nombreuses personnes se sont surpassées, ont mis tout le reste de côté pour réagir en temps opportun et avec beaucoup d'engagement pour s'assurer que nous n'avons rien manqué ou négligé ; tout cela alors qu'un long week-end férié avait déjà commencé. Félicitations à tous ceux qui ont travaillé 24 heures sur 24 pour préparer cela.Héros de l'histoire
Si rien de pire ne s'est produit, c'est uniquement grâce à Andres Freund, un développeur de la communauté PostgreSQL, qui n'a pas ignoré une étrange régression des performances des connexions SSH sur son installation instable Debian récemment mise à niveau. Un autre témoignage selon lequel ne pas abandonner quelque chose que tout le monde aurait probablement ignoré au cours des mois ou des années à venir est ce qui fait d'un héros un héros.Toutefois, s’appuyer sur des héros n’est pas une stratégie durable et fiable. Donc, pour l’avenir, nous devons tous tirer les leçons de ce qui s’est passé et devenir une grande équipe de petits héros.
La photo sur cet article a été prise par Matthias Pastwa et utilisée sous CC-BY-ND 2.0 DEED
