Il vaut peut-être mieux éviter d’installer de nouveaux logiciels pendant quelque temps

• Après copy.fail, d’autres vulnérabilités du noyau Linux ont été publiées
• La période actuelle est considérée comme particulièrement propice à des dégâts majeurs via des attaques sur la chaîne d’approvisionnement NPM
• Il est recommandé de faire une exception pour les correctifs du noyau Linux fournis par la distribution
• En dehors de cela, il vaut mieux suspendre l’installation de nouveaux logiciels pendant environ une semaine
• Une note précise que, depuis la publication, les faits ou la situation peuvent avoir évolué, et demande à être contacté avant toute conclusion si certains points semblent erronés ou peu clairs

[GN⁺]

Avis sur Hacker News

• C’était un cauchemar inévitable depuis longtemps. Il y a trop de paquets, et la surface d’attaque de la chaîne d’approvisionnement est devenue si énorme que ça devait finir par exploser pour tout le monde
  Mais c’était tellement pratique. Ceux qui essayaient d’alerter ou de réduire les risques se faisaient balayer par des gens qui n’avaient jamais essayé d’autres façons de faire, et "import antigravity" était bien trop facile pour qu’on y renonce
  On a l’impression d’être entrés dans la phase où il faut « en payer le prix »

  • Dans une entreprise, on opérait de manière vraiment conservatrice. Tous les composants externes étaient épinglés à une version, jamais mis à jour sans revue, et passaient généralement par une période de stabilisation suffisante
    Presque tout, y compris le compilateur, le noyau, etc., était compilé depuis les sources, les serveurs/infrastructures de build n’avaient aucun accès à Internet, et il existait une procédure pour introduire des changements. Les CVE concernés étaient examinés à chaque publication pour déterminer s’ils nous affectaient et comment les atténuer ou les traiter
    Ensuite, dans l’entreprise suivante, les builds avaient accès à Internet et on montait de version dès qu’une nouvelle sortait. Les gens considéraient ça comme une bonne pratique parce qu’on obtenait les derniers correctifs de bugs, et la revue des CVE relevait de l’équipe sécurité
    Puis, dans la startup suivante, il y avait un mélange de plusieurs pratiques. Il y avait de très bons côtés, mais aussi une grosse dette de CVE. Par exemple, les serveurs avaient un démarrage sécurisé et des disques chiffrés, et ils avaient une assez bonne maîtrise de la sécurité des communications entre composants
    Tout le monde pense faire ce qu’il faut. Il est presque impossible de convaincre les partisans des « mises à niveau fréquentes » qu’il y a un risque d’introduire de nouveaux problèmes. Le secteur a besoin d’un meilleur ensemble de pratiques, et personnellement je trouve que la première entreprise gérait mieux ses dépendances. Dans l’ensemble, les pratiques de sécurité y étaient bien en place et le produit était vraiment sûr
  • Quitte à ouvrir la boîte de Pandore, je me demande quel serait l’effet net si faire émerger tous ces vecteurs d’attaque inconnus vidait les réserves de vulnérabilités stockées par les services de renseignement du monde entier
    Tous les logiciels utiles finiraient avec du fuzzing, des tests basés sur les propriétés et de la vérification formelle, et tous ceux qui cherchent des vulnérabilités devraient repartir de zéro
    Bien sûr, cela suppose qu’on survive à la période de transition pendant laquelle chaque pays balance ses dernières cartouches sur ses pires ennemis. Sinon, on finira peut-être à se frapper avec des os d’animaux
  • Je veux depuis des années un modèle de sécurité fondé sur les capacités, et j’en ai déjà débattu ici. Une capacité, c’est comme un pointeur d’objet portant les permissions associées, un peu comme un descripteur de fichier Unix
    Au niveau du système d’exploitation, un programme lancé recevrait des jetons de capacité depuis le shell ou depuis l’endroit qui l’a lancé, et tous les appels système devraient prendre une capacité en premier argument. Donc "open path /foo" deviendrait open(cap, "/foo"). Cette capacité pourrait être un faux système de fichiers, une branche du vrai système de fichiers, un système de fichiers réseau, peu importe, et le programme n’aurait pas besoin de savoir dans quel sandbox il vit
    Au niveau des bibliothèques/langages aussi, lors de l’import d’une bibliothèque tierce comme un module npm, il faudrait transmettre des capacités au moment de l’import ou à chaque point d’appel. Cette bibliothèque ne devrait pas avoir un accès en lecture/écriture à chaque octet de l’espace mémoire de mon programme, ni pouvoir tout faire sur mon ordinateur comme si c’était moi. La question clé est : quel est le rayon d’explosion de ce code ? Quand une bibliothèque utilisée est malveillante ou vulnérable, il faut des valeurs par défaut raisonnables quant à l’ampleur des dégâts. Un appel à lib::add(1, 2) ne devrait pas pouvoir mener à une compromission persistante de toute ma machine
    SeL4 fournit depuis longtemps des capacités rapides et efficaces au niveau du système d’exploitation, et ça fonctionne bien. C’est souvent plus rapide que Linux, et très utile pour le sandboxing transparent, les pilotes en espace utilisateur, la communication interprocessus, les améliorations de sécurité, etc. On peut aussi exécuter Linux comme processus au-dessus de SeL4. Je veux un système d’exploitation qui offre toutes les fonctionnalités d’un bureau Linux tout en se comportant comme SeL4
    Malheureusement, il ne semble pas exister de langage de programmation avec les capacités au niveau du langage exactement sous la forme que je veux. Rust s’en approche pas mal, mais il faudrait un moyen d’empêcher un crate tiers d’appeler n’importe quel code unsafe, y compris via un unsafe appelé par une dépendance non fiable. Il faudrait aussi corriger les vieux bugs de sûreté de Rust, et disposer d’une bibliothèque standard fondée sur les capacités. Les open() / listen() globaux et autres devraient disparaître, et il ne devrait rester que openat() et des équivalents correspondant aux autres parties du système d’exploitation
    Si les LLM continuent de s’améliorer, je compte leur faire construire tout ça d’ici quelques années si personne ne le fait avant. La sécurité des systèmes d’exploitation de bureau modernes est une blague
  • La plupart des gens ne mettent pas n’importe quoi dans leur bouche par défaut. Ils n’attendent pas de voir si une culture microbienne revient positive avant de refuser
    Il nous faut une culture de l’hygiène pour le code, et ce n’est finalement pas si différent des normes que la plupart des cultures ont développées autour de l’alimentation. C’est un assemblage d’heuristiques grossières, mais cette réaction de « beurk » sauve des milliards de personnes
  • Il y a un an, j’ai avancé l’idée qu’il valait mieux écrire soi-même du code plutôt que d’intégrer du tiers quand c’était possible. À l’époque, rien que prendre en compte le fait que les LLM puissent combler les trous passait pour une hérésie
    Aujourd’hui, je réduis plus que jamais mon exposition aux dépendances, surtout pour les choses qu’on peut implémenter en quelques centaines de lignes. C’est carrément un changement de paradigme

• L’approche consistant à « attendre une semaine avant d’installer un logiciel » ne marche pas. Il y a seulement quelques mois, une vulnérabilité massive a frappé le web, et c’était une attaque à retardement qui avait dormi plus d’un mois avant d’être exécutée
  Si tout le monde commence à attendre une semaine, les attaquants attendront deux semaines. Les cybercriminels n’ont pas besoin d’exploiter immédiatement ; il leur suffit de finir par le faire. Et beaucoup de types de vulnérabilités, comme le typosquatting, ne changent pas avec cette approche

  • L’auteur ne semble pas dire qu’il faut continuer à retarder toutes les mises à jour, mais plutôt qu’il faut attendre une semaine, à titre exceptionnel, le temps que des correctifs et des patchs soient distribués pour certaines vulnérabilités qui ont été divulguées trop tôt cette fois-ci. Pour le reste, je suis d’accord
  • Je pense que tu as mal compris l’article. La proposition n’est pas d’attendre une semaine après la publication d’un logiciel avant de l’installer. Elle veut dire : à partir de maintenant, ne rien installer pendant les 7 prochains jours
    Parce qu’il y a de fortes chances qu’il n’existe pas encore de patch pour ces vulnérabilités, et même s’il y en a un, il y a de fortes chances qu’une vulnérabilité encore plus inquiétante soit bientôt découverte
  • Dans ce cas, il suffit d’attendre un mois ou deux. L’intérêt de la période d’attente n’est pas d’empêcher l’exécution d’exploits déjà installés, mais d’éviter l’installation de nouveaux exploits
  • Les paquets populaires sont davantage exposés. Une fois l’artefact publié, le monde entier peut le voir, et on peut s’attendre à ce que quelqu’un vérifie les différences entre versions
    Mais sans aucun délai, on peut se faire avoir par un exploit que personne n’a encore vu
  • De mémoire, toutes les compromissions de dépendances de ces « derniers mois » ont été détectées en quelques minutes, pas en quelques heures : litellm, axios, bitwarden CLI, image Docker Checkmarx, Pytorch lightning, intercom/intercom-php
    En plus, la découverte de ces compromissions n’a absolument pas dépendu du fait qu’elles aient été réellement exploitées ou non. Du coup, je ne comprends pas l’idée selon laquelle « si tout le monde attend une semaine, les attaquants attendront deux semaines »

• Sinon, on peut passer à un système d’exploitation comme FreeBSD, qui n’aborde pas la sécurité en mode YOLO
  Les correctifs de sécurité ne sont pas simplement balancés dans le noyau FreeBSD sans coordination. Ils passent par l’équipe sécurité de FreeBSD, puis des mises à jour binaires sont distribuées via FreeBSD Update et pkgbase pour 15.0-RELEASE quelques minutes seulement après l’intégration du patch dans l’arbre src
  En gros, il faut quelques secondes pour voir apparaître dans Slack un message du type « patch poussé », 10 à 30 secondes pour l’upload du patch, et au plus environ 1 minute pour la synchronisation des miroirs

  • Je suis un peu sceptique là-dessus. Il y a quelques années, j’ai signalé une vulnérabilité à l’équipe sécurité de FreeBSD, puis envoyé un mail de relance plusieurs semaines plus tard, sans jamais recevoir de réponse
    Pour être équitable, mon rapport portait sur quelque chose de non critique et difficile à exploiter, mais Debian, OpenBSD, SUSE et Gentoo ont tous patché dans la semaine https://www.maxchernoff.ca/p/luatex-vulnerabilities#timeline
    Cela dit, je ne veux pas juger tout un système d’exploitation sur le traitement d’un seul rapport mineur, car sur tout le reste que j’ai vu, FreeBSD semble prendre les rapports de sécurité assez au sérieux. Mais on peut appliquer le même raisonnement aux bugs du noyau Linux. Ce genre de mauvaise gestion des patchs est aussi assez rare côté Linux
  • Si on migre vers BSD pour des raisons de sécurité, pourquoi FreeBSD ? OpenBSD n’est-il pas la référence en la matière ? Je demande parce que ça fait longtemps que je n’ai pas suivi ces projets
  • FreeBSD est assez laxiste sur la sécurité, surtout en matière de valeurs par défaut et de configuration
    Il tend à privilégier l’utilisabilité par rapport à la sécurité. Un exemple célèbre ici : https://vez.mrsk.me/freebsd-defaults
    J’apprécie les contributions au projet, mais tant que ces mauvais réglages par défaut existent, je ne peux pas en conscience recommander aux gens de migrer
  • FreeBSD n’avait même pas d’ASLR en espace utilisateur avant 2019, et il lui manque encore kASLR, qui est l’une des autres mesures d’atténuation. Ce n’est pas un système d’exploitation sérieux pour quelqu’un qui accorde de l’importance à la sécurité
    Si on veut FreeBSD et la sécurité, mieux vaut utiliser HardenedBSD de Shawn Webb
  • Il y en a toujours un pour intervenir dans ce genre de discussion. Tant mieux si ta distribution préférée est clairement plus sûre. Même si ça réduisait les exploits d’un facteur à un chiffre, il en resterait encore quelques milliers. Ozymandias aurait utilisé Gentoo

• Même les experts en sécurité doivent maintenant admettre que notre monde repose sur un équilibre extrêmement fragile. Je pense que les gens sous-estiment vraiment ça
  Et pas seulement le monde de l’IT : le monde tout entier est construit sur quantité d’équilibres très fragiles. Il y aura toujours des exploits de sécurité. Pas seulement dans le logiciel, mais aussi dans le monde réel. Quelqu’un a déjà réussi à s’infiltrer dans une conférence sécurité, et ce n’était qu’un youtubeur. Ce n’était pas un événement ultra sécurisé, bien sûr, mais c’est l’exemple qui m’est venu. Fondamentalement, dans la plupart des cas, contourner la sécurité est vraiment facile
  Ce que je veux dire, c’est que notre monde fonctionne au fond surtout parce que la plupart des gens n’abusent pas des failles. Les sociétés humaines ont toujours marché ainsi, et il est probable que cela continue

  • Je me souviens qu’il y a eu une mode chez des influenceurs britanniques consistant à entrer dans des lieux avec la technique de « l’échelle et du gilet fluorescent » pour montrer à quel point la sécurité physique était bancale https://www.youtube.com/watch?v=LTI0SeyhAPA
    Si je me souviens bien, un youtubeur nommé Max Fosh est entré plusieurs fois à l’International Security Expo. Au Royaume-Uni, dans https://www.youtube.com/watch?v=qM3imMiERdU, et aux États-Unis, dans https://www.youtube.com/watch?v=NmgLwxK8TvA, il utilisait respectivement les pseudonymes « Rob Banks » et « Nick Everything »
    J’ai déjà étudié la culture de la sécurité, et au final on retombe presque toujours sur une échelle glissante avec la sécurité d’un côté et la commodité/l’accessibilité de l’autre. Plus c’est sûr, moins c’est accessible, et inversement

• Pour les attaques de chaîne d’approvisionnement visant des gestionnaires de dépendances comme npm, PyPI ou Cargo, il existe déjà une solution tout à fait correcte. Il suffit de configurer le système pour n’installer que des versions de paquets âgées de plusieurs jours
  Toutes les grosses attaques récentes ont été découvertes et annulées en moins d’une journée, donc cette méthode aurait permis de les éviter sans problème. Ce comportement devrait être la valeur par défaut. Il suffit de laisser les bêta-testeurs volontaires et les entreprises de scan de sécurité essayer les toutes dernières versions pendant un jour environ avant tout le monde. La méthode est ici : https://cooldowns.dev/

  • Cet outil montré sur Show HN il y a 3 mois me semble plus adapté : https://github.com/artifact-keeper
    C’est un gestionnaire d’artefacts. Il permet de ne récupérer que ce que vous avez approuvé. On peut mettre à jour rapidement quand c’est nécessaire, et utiliser des versions stables validées de manière cohérente quand il le faut. Ça demande de petites surcharges de configuration, mais c’est facile à faire
    J’avais bricolé moi-même un outil un peu bancal pour un objectif similaire, et celui-ci est un bon projet
  • Une meilleure approche est que l’entreprise n’utilise que des dépôts qu’elle a validés, et que personne ne puisse rien installer directement depuis des dépôts Internet
    Évidemment, hors du cadre d’une entreprise, ça fonctionne rarement aussi bien
  • Mais dans ce cas, on reçoit aussi plus tard les mises à jour de sécurité, non ? Beaucoup de vulnérabilités existent en production pendant des années avant d’être découvertes et corrigées
    Une fois découvertes, elles déclenchent aussitôt une explosion d’exploits, et retarder les mises à jour donne plus de temps à des attaquants surexcités
  • Personnellement, je pense que l’approche la plus durable reste le modèle des distributions Linux / ports BSD / Homebrew. Au lieu de pousser directement une nouvelle bibliothèque dans un registre public, on écrit des scripts de packaging revus à chaque changement
    Un autre modèle est celui du CPAN de Perl, qui ne distribue que des fichiers source

• Ceux qui ont adopté relativement récemment l’intégration continue et les builds conteneurisés feraient bien de vérifier que leur système n’est pas en train de tirer latest depuis plusieurs paquets à chaque build
  Chez nous, on construit un conteneur de base qui intègre toutes les dépendances externes, puis on ne le met à jour explicitement que lorsqu’on décide que le moment est venu
  On est donc un peu moins à la pointe, mais on s’expose beaucoup moins au risque qu’une vulnérabilité de chaîne d’approvisionnement aléatoire soit immédiatement déployée dans le monde entier

  • Vous constaterez aussi que cela réduit fortement les temps de build en CI ainsi que les échecs aléatoires et instables
  • En plus, mieux vaut n’utiliser que des dépôts internes

• C’est un billet d’opinion activement nuisible. J’ai du mal à suivre la logique
  Il suffit de 45 secondes pour vérifier depuis combien de temps existent réellement les vulnérabilités copyfail et dirtyfrag. C’est plus long que le temps nécessaire pour lire l’article. Dirtyfrag peut concerner des systèmes remontant jusqu’à 2017
  Ce ne sont pas les « nouveaux » logiciels qui sont touchés. Et les logiciels réellement anciens sont dans un état encore pire, simplement parce qu’ils ont eu beaucoup plus de temps pour accumuler des problèmes

  • Le billet original dit seulement que si une attaque sur la chaîne d’approvisionnement se produit maintenant, ça pourrait être très mauvais ; donc, pour réduire ce risque, il faudrait éviter d’installer ou de mettre à jour des paquets NPM

• Un jour, quelqu’un reconstruira toute la pile complète, du système d’exploitation jusqu’aux applications, avec des mises à niveau en proof-carrying code
  La seule manière d’exécuter du code fiable est de co-concevoir et co-construire ensemble les preuves et le code

• Cela ne s’applique pas seulement aux logiciels, mais en réalité à presque tout
  Je ne me souviens plus où j’ai lu ça, mais au fond tout se résume à la différence entre besoin et envie
  J’ai appliqué cette règle pour décider d’acheter une voiture neuve ou d’occasion, un aspirateur haut de gamme ou un modèle de base. C’est pareil pour l’achat d’un gadget flambant neuf, l’introduction de quelque chose de nouveau dans une stack technique, ou le choix d’une nouvelle stack technique

• J’aimerais mieux comprendre ce qu’est copyfail et quel est le lien avec les paquets NPM
  Si je résume, copyfail semble être un bug du noyau qui permettrait à un paquet npm malveillant d’obtenir les privilèges root sur un serveur Linux
  Donc, comme il existe encore des serveurs non patchés, c’est le moment idéal pour les attaquants de viser les paquets NPM
  Si le conseil n’est pas simplement « mettez à jour le noyau », c’est parce que de nouveaux problèmes liés continuent encore d’être découverts ?

  • Les patchs pour les vulnérabilités les plus récentes ne sont même pas encore sortis. Donc si une nouvelle attaque de chaîne d’approvisionnement se produit maintenant, ce serait vraiment le pire moment, car elle pourrait obtenir root sur presque tous les systèmes
  • Les attaques de chaîne d’approvisionnement NPM se propagent très vite
    Si un paquet NPM populaire était compromis pour inclure un exploit copy.fail, beaucoup de systèmes deviendraient vulnérables à une élévation de privilèges root
  • Si le conseil n’est pas « mettez à jour le noyau », c’est parce qu’il n’y a pas de mise à jour. La vulnérabilité la plus récente découverte après copy.fail n’est pas encore corrigée