L’affaire de la porte dérobée xz, un microcosme des interactions dans les projets open source

• Il existe sans doute déjà de nombreuses analyses de la vulnérabilité xz/liblzma, mais la plupart tendent à passer sous silence la première étape de l’attaque
  • Le mainteneur d’origine était épuisé, et seul l’attaquant a proposé son aide (l’attaquant a donc hérité de la confiance accumulée par le mainteneur initial).
• Les archives du fil d’e-mails capturent la situation au moment où cette étape 0 s’est produite

L’épuisement du mainteneur et l’apparition de l’attaquant

• Une demande, raisonnable en apparence, est adressée au mainteneur

  • « XZ for Java est-il encore maintenu ? J’ai posé la question il y a une semaine et je n’ai toujours pas eu de réponse. »

• Cette question pousse le mainteneur à reconnaître un « échec »
  • En réalité, le mainteneur ne devait rien à personne et n’avait pas échoué, mais c’est ainsi qu’il l’a ressenti
  • Parce que décevoir la « communauté » est quelque chose de terrible
• Le mainteneur reconnaît qu’il est « en retard » et envoie un signal laissant entendre qu’il demande de l’aide
• Pourtant, dans ce fil, aucune aide n’est venue ; à la place, l’attaquant de xz/liblzma se présente comme quelqu’un qui l’a aidé

  • « Jia Tan (l’attaquant de cette affaire) m’a aidé... et pourrait jouer un rôle plus important à l’avenir... Mes ressources sont trop limitées, il est donc clair que quelque chose devra changer sur le long terme. »

• Le mainteneur mentionne que ses ressources sont limitées et qu’un changement sera nécessaire à long terme

L’apparition d’un consommateur peu coopératif

• Un consommateur peu coopératif tient des propos critiques envers le mainteneur

  • « Il n’y aura sans doute aucun progrès tant qu’il n’y aura pas un nouveau mainteneur. ... Le responsable actuel a perdu tout intérêt ou ne se soucie plus de la maintenance. C’est triste de voir un dépôt dans cet état. »

• Le mainteneur se défend en expliquant qu’il n’a pas perdu intérêt, mais que sa capacité à gérer le projet est limitée, notamment à cause de problèmes de santé mentale
• Le mainteneur rappelle aussi qu’il s’agit d’un projet de loisir non rémunéré

L’augmentation des exigences

• Une semaine plus tard, le consommateur peu coopératif réapparaît et blâme de nouveau le mainteneur.

  • « Vous ignorez de nombreux correctifs qui pourrissent peu à peu sur cette liste de diffusion. »

  • « Je suis désolé pour vos problèmes de santé mentale, mais il est important de reconnaître ses limites. Je sais que ce projet est un projet de loisir pour tous les contributeurs, mais la communauté en attend davantage. »

• Cette personne formule aussi des suggestions, mais sans jamais proposer une aide concrète

  • « Que diriez-vous de transférer les droits de maintenance sur XZ for C afin de pouvoir vous concentrer davantage sur XZ for Java ? Ou, à l’inverse, de confier XZ for Java à quelqu’un d’autre pour vous concentrer sur XZ for C ? Si vous essayez de maintenir les deux, il se peut qu’aucun des deux ne soit correctement maintenu. »

• Le mainteneur explique qu’il n’est pas simple de trouver un nouveau co-mainteneur ni de transmettre complètement le projet

La réalité des projets open source

• Les développeurs logiciels ne sont pas des rouages interchangeables que l’on peut insérer ou retirer à volonté
• Le fil d’e-mails se termine avec un consommateur mécontent qui continue d’exiger sans offrir la moindre aide, et seul l’attaquant reste en place

  • « Jia Tan pourrait jouer un rôle plus important dans le projet à l’avenir. Il m’aide énormément en dehors de la liste et, de fait, il est déjà co-mainteneur. :-) »

• Ce fil d’e-mails montre, en miniature, les interactions au sein des projets open source
• Les consommateurs imposent des exigences aux mainteneurs, et les mainteneurs réagissent de différentes façons sous l’effet du stress et de l’épuisement
• Cette manière de fonctionner doit changer

[GN⁺]

Avis Hacker News

• Certains estiment que les développeurs gaspillent beaucoup d’énergie mentale à essayer d’être gentils avec les utilisateurs et à présumer la bonne foi des auteurs de commentaires. Ce type de remarque revient surtout dans des side projects menés pour le plaisir (émulateurs, remakes de jeux, etc.). Ces projets évitent souvent de mentionner les dons afin d’échapper aux problèmes liés aux dons ou au droit d’auteur. L’intérêt pour le projet peut être important, mais l’intérêt qualifié capable de contribuer réellement reste extrêmement limité. Les échanges avec les utilisateurs sont autorisés et encouragés, mais ils peuvent parfois être perçus comme des « suggestions » ou des « exigences » qui démotivent les développeurs. Il est important de préserver la communauté, mais il existe aussi une inquiétude à l’idée de ne pas exclure les personnes qui ne contribuent pas directement.

• La première étape du problème a été une attaque d’ingénierie sociale dans laquelle le développeur du projet open source a été poussé à céder davantage de contrôle du dépôt à l’attaquant.

• En tant que mainteneur d’une bibliothèque open source orientée sécurité, chaque fois que je lis une PR, le doute pèse lourdement : « cette personne essaie-t-elle d’aider, ou de profiter de moi ? ». Je pense que ralentir le rythme de développement est la seule solution, mais le ressenti que cela provoque est le même que celui décrit dans l’article. S’il existait un moyen simple de demander de l’aide à une communauté d’experts de confiance, je l’accueillerais volontiers.

• Comme avec les cryptomonnaies, l’IA et ce cas précis, le plus gros problème ramène à la question de la confiance. Les cryptomonnaies tentent de résoudre un problème de confiance par le code, les LLM essaient de gagner la confiance par l’esbroufe, et les attaquants réussissent en partie à blanchir leur confiance. Les techniciens les plus importants ne réfléchissent pas correctement à la confiance. Dans ce cas, il y a de la compréhension pour les développeurs open source bénévoles, fatigués et non rémunérés.

• Quelqu’un se demande si un serveur SSH configuré avec du port knocking serait protégé contre cette backdoor. Comme la RCE ne peut être exécutée qu’après connexion au serveur SSH, il semble que si le port est caché derrière une séquence raisonnable de knocking TCP/UDP, il ne devrait pas y avoir de problème. Le port knocking ne remplace pas une configuration SSH correcte, mais constitue une couche de défense supplémentaire utile pour prévenir une vulnérabilité SSH, ou au moins gagner du temps pour réagir lorsqu’elle apparaît.

• Un lien est donné au sujet d’un problème lié à un patch spécifique à Linux dans OpenSSH. Sans ce patch, le problème ne se serait pas produit. Ce n’est pas un problème d’OpenSSH, mais de Linux.

• Certains estiment que les gens continuent, même après l’affaire left-pad, à traiter avec légèreté les dépendances critiques et la complexité. OpenSSH est un immense mur de code. Les systèmes complexes sont par nature difficiles à considérer comme dignes de confiance, quel que soit le langage dans lequel ils sont écrits.

• Si un hacker chinois voulait agir de manière malveillante, pourquoi utiliserait-il un nom/pseudo chinois ? Il vaudrait mieux utiliser un nom anglais ou européen pour obtenir davantage de confiance de la part des mainteneurs open source. À l’inverse, si un hacker non chinois voulait agir de manière malveillante, utiliser un nom chinois aurait plus de sens (la Chine = le mal, etc.).

• Le compte Jigar Kumar semble faire partie de l’attaque d’ingénierie sociale et aurait dû paraître très suspect.

• Les développeurs logiciels ne sont pas des pièces interchangeables, et certains réfléchissent à limiter le droit de commenter ou de participer dans la communauté. Par exemple, si GitHub introduisait des « portes d’entrée », la première pourrait consister à ajouter à la suite de tests un test qui génère un numéro de version et un hash de la sortie des tests. En ajoutant ce numéro au profil, GitHub pourrait considérer que l’utilisateur a au moins téléchargé et exécuté make test. Cela montrerait un certain degré d’engagement.