Le malware sur le thème de Shai-Hulud découvert dans la bibliothèque d’entraînement IA PyTorch Lightning

• Les versions 2.6.2 et 2.6.3 de lightning, le framework de deep learning, ont été exploitées dans une attaque de la chaîne d’approvisionnement — le simple fait d’exécuter pip install lightning déclenche automatiquement une charge utile JavaScript obfusquée dans un répertoire caché _runtime
• Comme ce framework est largement utilisé pour créer des classifieurs d’images, le fine-tuning de LLM, les modèles de diffusion ou la prévision de séries temporelles, il est probable qu’il figure déjà dans l’arbre de dépendances de nombreuses équipes IA/ML
• Une fois exécuté, le malware scanne plus de 80 chemins sur le système de fichiers local pour voler des tokens GitHub (ghp_, gho_), des tokens npm (npm_), des variables d’environnement et des secrets cloud, en traitant jusqu’à 5 Mo par fichier
• Il énumère et récupère des secrets chez les trois grands fournisseurs cloud : AWS (fichiers d’identifiants, IMDSv2, ECS, Secrets Manager, SSM), Azure (Key Vault) et GCP (Secret Manager)
• Dans les environnements GitHub Actions, il utilise le Python intégré pour vider la mémoire du processus Runner.Worker afin d’extraire tous les secrets marqués avec "isSecret":true, ainsi que les informations sur le dépôt et le workflow
• Le point d’entrée est PyPI (Python), mais la propagation en ver passe par npm (JavaScript) — à l’aide des tokens npm volés, il injecte un dropper (setup.mjs) et le malware (router_runtime.js) dans tous les paquets publiables, incrémente la version de patch puis les republie, provoquant une infection en chaîne jusqu’aux machines des développeurs qui installent ces paquets
• Pour l’exfiltration des données, il utilise quatre canaux parallèles afin qu’un simple blocage d’un chemin unique ne suffise pas : ① envoi au serveur C2 via HTTPS POST, ② dead drop via l’API de recherche de commits GitHub (avec insertion de tokens encodés en double Base64 dans les messages de commit), ③ commit sous le nom results-<timestamp>.json dans un dépôt GitHub public utilisant des noms de l’univers de Dune, ④ push direct dans le dépôt de la victime
• Après avoir pénétré un dépôt, il installe des hooks de persistance dans les outils de développement pour garantir la réinfection — il écrit un hook SessionStart dans .claude/settings.json de Claude Code pour une exécution automatique au démarrage de session, et place une tâche runOn: folderOpen dans .vscode/tasks.json de VS Code pour s’exécuter à chaque ouverture du dossier
  • Ces deux hooks appellent le dropper autonome setup.mjs et, si le runtime Bun n’est pas présent, le téléchargent discrètement depuis GitHub pour exécuter la charge utile de 14,8 Mo router_runtime.js
• Lorsqu’il obtient un token GitHub avec droits d’écriture, il pousse dans le dépôt de la victime un workflow camouflé nommé Formatter — à chaque push, il vide les secrets du dépôt avec ${{ toJSON(secrets) }} puis les téléverse comme artefact GitHub Actions
• Toutes les machines ayant installé ces versions pendant la période concernée doivent être considérées comme totalement compromises ; il faut remplacer immédiatement les tokens GitHub, identifiants cloud et clés API, et auditer les répertoires .claude/ et .vscode/ pour détecter d’éventuels fichiers inattendus
• Indicateurs de compromission : préfixe EveryBoiWeBuildIsAWormyBoi dans les messages de commit, description de dépôt "A Mini Shai-Hulud has Appeared", présence d’un répertoire _runtime/ dans le dépôt — autant d’éléments vérifiables directement via la recherche GitHub

[picopress]

Bon, il ne faudra plus faire les mises à jour maintenant...

[GN⁺]

Avis Hacker News

• C’est peut-être simplement une illusion de fréquence, mais on voit récemment pas mal d’attaques de la chaîne d’approvisionnement très médiatisées dans des paquets importants
  Rien que dans les premières pages de HN en ce moment, il y a plusieurs billets sur des cas différents
  Quand on repense à left-pad il y a 10 ans, on se demande si les attaques réussies sont plus nombreuses qu’avant, et c’est probablement le cas
  La valeur d’une attaque réussie a sûrement beaucoup augmenté aussi, mais je me demande si, collectivement, la communauté s’améliore réellement pour les détecter avant la publication des paquets
  Les éditeurs de logiciels commerciaux devraient faire mieux, mais il semble toujours manquer d’outils universels et simples pour les cas où du code de loisir/amateur finit par devenir une dépendance de nombreux projets
  J’ai posté le même commentaire dans le fil sur l’attaque de la chaîne d’approvisionnement de SAP : https://news.ycombinator.com/item?id=47964003

  • C’est un phénomène réel. Début avril, on en comptait 7 sur les 12 derniers mois, contre 9 sur les 20 années précédentes : https://www.jefftk.com/p/more-and-more-extensive-supply-chai...
  • Les gens injectent du code partout en masse sans vraiment le regarder, donc il est naturel que les attaques de la chaîne d’approvisionnement augmentent en conséquence
  • La raison, c’est que les mises à jour automatiques et les outils de CI ont atteint une masse critique et sont utilisés par tout le monde
    Avant, on lançait plus souvent npm install manuellement, probablement seulement quand un build cassait ou très occasionnellement
    Les attaques de la chaîne d’approvisionnement reposent sur le fait que les gens — ou plus précisément les pipelines — mettent automatiquement à jour les paquets sans réfléchir dès qu’une nouvelle version sort
  • Historiquement, le traitement des artefacts avec des contrôles de sécurité supplémentaires relevait d’une option enterprise payante, tandis que l’option moins sûre était de loin la valeur par défaut la moins contraignante
    Je ne sais pas si c’est un bon modèle économique, et probablement pas
  • left-pad n’était pas une attaque, mais un bug de NPM
    Il n’aurait pas dû être possible de supprimer une version de paquet dont d’autres paquets déjà publiés dépendent, alors qu’à l’inverse il aurait dû être possible de supprimer une version de paquet plus récente dont personne ne dépendait encore
    Quand l’auteur de left-pad a essayé d’effacer toutes ses données avec l’intention de quitter le service, NPM aurait dû renvoyer un code d’erreur
    D’après Wikipedia, quand Koçulu a dit qu’il ne voulait plus rester sur la plateforme, déçu par une décision de npm, Inc., Schlueter, le créateur de NPM, lui a fourni une commande pour supprimer les 273 modules qu’il avait publiés

• Ce qui est étrange, c’est que 4 signalements de sécurité ont été ouverts et que tous ont reçu un commentaire automatique du bot pl-ghost, puis ont été fermés [1][2][3][4]
  Au final, seul [4] a été traité correctement, et tous les commentaires du bot ont été supprimés
  On peut voir les commentaires du bot dans cet autre rapport [5], qui donne plus d’informations que l’original
  [1] https://github.com/Lightning-AI/pytorch-lightning/issues/216...
  [2] https://github.com/Lightning-AI/pytorch-lightning/issues/216...
  [3] https://github.com/Lightning-AI/pytorch-lightning/issues/216...
  [4] https://github.com/Lightning-AI/pytorch-lightning/issues/216...
  [5] https://socket.dev/blog/lightning-pypi-package-compromised

  • Andy de Lightning ici. Oui, les identifiants PyPI ont été volés via le compte bot pl-ghost compromis
    L’attaquant a créé un nouveau workflow Actions avec ce compte, puis a extrait les secrets PyPI depuis le workflow exécuté
    Après avoir publié le paquet, il a laissé des commentaires avec ce compte, en nous narguant légèrement au passage

• J’aimerais vraiment que le jour arrive vite où il n’y aura plus aucune dépendance
  Dans un cas extrême, quand je crée en ce moment des applis éducatives interactives pour ma fille, je demande à Opus d’utiliser uniquement du JavaScript et HTML purs
  Du double pendule à la simulation de fluides, tout fonctionne bien d’un coup, alors qu’avant cela représentait des centaines de dépendances
  Si le code est sous licence MIT, je peux demander à Opus d’en extraire précisément les parties nécessaires, puis de les adapter et de les intégrer à mon usage
  Pour les projets hobby, ça a très bien marché jusqu’ici, et j’aimerais qu’à l’avenir les logiciels de production puissent eux aussi se passer de dépendances

  • Dans ce cas, il faut gérer soi-même tous les changements et l’énorme quantité de cas particuliers
    Si Chrome change la forme d’une API, il faut le trouver et le corriger soi-même ; si le Maroc modifie la date de début de l’heure d’été, il faut aussi mettre à jour son propre code de gestion des dates et heures
    Ce sont justement le genre de choses que les bibliothèques prennent en charge et qu’on tenait pour acquises
    Ce n’est pas bien grave pour un simulateur de double pendule auquel ta fille ne s’intéressera plus la semaine prochaine, mais pour une entreprise qui construit quelque chose censé fonctionner indéfiniment, c’est un vrai problème
  • Du coup, tu t’exposes maintenant à ta vraie dépendance : le navigateur
  • Bien sûr, tu vas relire avec autant de soin chaque ligne du code produit par Opus que ce que tu attends d’un mainteneur open source, n’est-ce pas ?
    Il faudrait peut-être publier un bout de code MIT d’accès à distance pour qu’il finisse dans les données d’entraînement d’Opus
  • J’aime plus Rust que Go, donc ça me fait réfléchir. Même du point de vue des LLM, Rust est meilleur, mais la philosophie des dépendances de Rust est en pratique un trou noir de sécurité, alors que Go fait beaucoup mieux
  • Tu as un dépôt ou une forge partageable ? J’ai un jeu pour apprendre à épeler les animaux de la ferme et j’aimerais étendre ma bibliothèque et trouver d’autres idées

• Quand j’ai suivi le cours de deep learning de Fast.AI, j’ai été surpris par le nombre de dépendances Python qu’un projet de machine learning traîne avec lui
  J’ai toujours considéré que les projets de front-end web avaient beaucoup de dépendances tierces, mais pour moi l’écosystème ML semble bien plus enchevêtré
  En plus, le développement web est considéré comme sensible à la sécurité depuis longtemps, donc il y a eu le temps d’accumuler de la sagesse et des pratiques en la matière, alors que le développement ML paraît beaucoup plus bricolé, avec bien moins d’application des pratiques générales de génie logiciel
  Par exemple, l’une des façons de déployer des modèles de ML à l’époque passait par Python pickle, c’est-à-dire des objets exécutables sans restriction par défaut
  Un modèle dans ce format pouvait faire n’importe quoi sur la machine qui l’importait, et ce far west initial de l’écosystème facilite les compromissions de sécurité et les attaques de la chaîne d’approvisionnement

  • Cet écosystème compte au départ beaucoup de gens qui ne sont pas ingénieurs logiciel
    Certains ont appris un peu à coder en cours de route, certains sont mathématiciens, et certains sont des développeurs ivres d’IA
    Il y a aussi cette mentalité du type : « le code n’a plus d’importance, tant que ça marche »
    Pour beaucoup, une vraie gestion des dépendances n’est qu’une corvée dont ils ne veulent pas s’occuper
    Dans beaucoup de projets ML, tous ces facteurs se combinent, alors qu’en réalité le ML devrait être l’un des domaines les plus focalisés sur la reproductibilité

• En cherchant dans les dépôts, je trouve 2,2 k dépôts créés au cours des dernières 24 heures contenant le texte "A Mini Shai-Hulud has Appeared" : https://github.com/search?q=A%20Mini%20Shai-Hulud%20has%20Ap...

  • Les noms des dépôts semblent tous formés de deux termes/mots de Dune avec un nombre à la fin, par exemple harkonen, mentat, ornithoptor
    Cela ressemble au signe qu’un compte, probablement avec des tokens GitHub auth/Actions, a été compromis puis utilisé pour créer des dépôts
  • Le compte https://github.com/tinin46 semble stocker beaucoup de clés, mais je ne comprends pas bien à quoi elles servent
  • Je ne comprends pas pourquoi GitHub ne réagit pas immédiatement pour bloquer les dépôts dont le README correspond à une regex
    Ce n’est pas la première fois que ça arrive, donc on aurait cru qu’ils auraient retenu la leçon
    Ce malware n’a pas fait beaucoup d’efforts, et Microsoft non plus, on dirait
  • Mais qu’est-ce qui se passe exactement ?

• Pour être clair, je n’ai jamais utilisé pytorch et je ne connais pas très bien les pratiques de sécurité logicielle
  Mais j’ai du mal à imaginer un scénario où pytorch aurait besoin d’un accès réseau
  Le fait de pouvoir importer n’importe quel module n’importe où dans la base de code et utiliser son API me paraît problématique
  Il faudrait sans doute des restrictions d’import supplémentaires ou de l’analyse statique
  Le langage ne semble pas disposer des bonnes abstractions pour traiter ce genre de problème
  À titre de comparaison, ce que j’aime avec Rust, c’est qu’on peut voir la mutabilité et les durées de vie juste à partir de la signature d’une fonction, sans comprendre le code interne
  J’ai l’impression qu’il faudrait quelque chose de similaire pour les dépendances
  Un développeur devrait pouvoir auditer facilement toutes les dépendances sans aller fouiller le code en dessous, et voir : « ah, cette dépendance utilise eval() » ou « elle a un accès réseau »
  Les applis mobiles imposent des permissions ; les développeurs ne devraient-ils pas eux aussi pouvoir mettre certaines capacités sur liste blanche au lieu d’accepter d’un bloc toutes sortes de fonctionnalités ?

  • L’écosystème Python n’acceptera probablement jamais ça, mais j’aimerais que ce sujet y soit mieux compris et davantage reconnu
    Je n’aime pas généraliser, mais la communauté de développement IA semble surtout privilégier la commodité au détriment de tout le reste
    Par exemple, il est devenu presque standard qu’un projet télécharge automatiquement un gros modèle au premier lancement
    On peut généralement le désactiver, mais trouver le bon paramètre dans des couches profondes de classes réparties sur plusieurs bibliothèques est vraiment pénible
    C’est bien de pouvoir démarrer très facilement des choses complexes, souvent proches du gadget, mais cette ambiance permissive est assez dérangeante
    On dirait que la première étape de résolution de problème est toujours « pip install … », et certains environnements, comme MacOS, ne virtualisent même pas très bien l’accès GPU
  • Il y a des cas où l’on entraîne des modèles sur plusieurs nœuds de calcul. C’est un grand cas d’usage qui nécessite un accès réseau

• Je me demandais cette semaine si utiliser uv pour gérer les versions Python était une bonne idée
  Le site web [1] dit que « Python ne fournit pas de binaires officiels pour la distribution, donc uv utilise les distributions du projet Astral python-build-standalone »
  Cela renvoie vers ce dépôt GitHub https://github.com/astral-sh/python-build-standalone, qui lui-même mentionne https://gregoryszorc.com/docs/python-build-standalone/main/r...
  Si je comprends bien, le code source utilisé pour construire Python ne semble pas venir directement de python.org, et je ne suis pas sûr de la sécurité de tout cela
  J’ai la même inquiétude avec asdf [2], mais asdf utilise pyenv [3], qui me paraît plus proche de l’officiel
  Est-ce que quelqu’un peut expliquer quel outil est préférable et plus sûr pour installer Python, entre uv et asdf ?
  [1] https://docs.astral.sh/uv/guides/install-python/
  [2] https://github.com/asdf-community/asdf-python
  [3] https://github.com/pyenv/pyenv/tree/master/plugins/python-bu...

  • python-build-standalone récupère directement les sources de CPython depuis python.org[1]
    On se demande bien d’où ils iraient les chercher sinon
    [1]: https://github.com/astral-sh/python-build-standalone/blob/a2...
  • uv et cpython ne m’inquiètent pas trop. Le processus est solide, la réaction est rapide, et il y a désormais des financements conséquents
    Ce qui m’inquiète, c’est par exemple un formateur comme mdformat, largement utilisé mais maintenu principalement par une seule personne sur son temps libre, ou une dépendance très spécifique située trois niveaux plus bas dans l’arbre et qui n’a pas été mise à jour depuis des années
    Je n’ai pas envie de figer toutes les mises à jour et de les approuver manuellement pour une appli activement développée, mais pour une appli sérieuse, ça commence à ressembler à une nécessité
    En attendant, je vais devoir récupérer mes clés API depuis un fichier .env non chiffré
    Se faire compromettre sur une grosse webapp grand public, c’est gênant mais compréhensible ; perdre des centaines ou des milliers de dollars à cause d’une dépendance indirecte d’un dépôt de démo gadget qui se trouvait sur le même hôte et le même système, c’est vraiment douloureux
    Quelqu’un sait si OAI ou Anthropic remboursent quand des clés sont volées comme ça, ou est-ce considéré comme une erreur utilisateur ?
  • Après tout, uv est lui-même un binaire que vous exécutez sur votre machine pour gérer des binaires Python, des paquets, les binaires qu’ils contiennent, des outils système globaux, etc.
    Je ne sais pas à quel point le risque change selon qu’ils construisent eux-mêmes le binaire Python ou qu’il soit construit par quelqu’un d’autre

• En ce moment, la plupart de mes pip install viennent de suggestions de Claude Code, et je me contente d’appuyer sur Entrée
  Le modèle a été entraîné sur des données vieilles de plusieurs mois, donc il ne peut pas savoir ce qui a été compromis cette semaine
  J’ai en fait construit le pire filtre possible pour juger si « ce paquet est sûr en ce moment »

  • Il ne faut pas rejeter la faute sur les LLM pour de la paresse et un manque de diligence
  • De quel filtre parle-t-on au juste ?
    Tu dis simplement que tu laisses Claude Code te recommander des logiciels à installer depuis Internet, puis que tu les installes tels quels
    Je n’ai jamais entendu personne suggérer que Claude Code, ou n’importe quel LLM, soit un filtre permettant de déterminer si « ce paquet est sûr en ce moment », et vu ce que tu décris, cela semble une très mauvaise heuristique
  • Le fait que les données d’entraînement soient anciennes joue un rôle, mais même un modèle à jour ne peut pas savoir ce que setup.py va exécuter sur ma machine
    Parce qu’il n’y a rien qui inspecte réellement le paquet avant exécution
    Ce qu’il faut, c’est un outil qui récupère les métadonnées avant exécution pour vérifier quels hooks existent
  • Il suffit de ne pas appuyer sur Entrée pour contourner très facilement le problème
  • Par « pire filtre », tu veux dire appuyer sur Entrée chaque fois que Claude le demande ?

• Claude Code est mis à jour presque tous les jours, parfois plusieurs fois par jour
  Le jour où Anthropic sera compromis, on va tous prendre très cher

  • « On » désigne qui exactement ?
  • Pas si on l’exécute dans une VM/un conteneur sans privilèges avec un accès réseau restreint
    Mais en ce moment, tout le monde est en mode YOLO
  • J’imagine que c’est déjà intégré dans le prix sur Polymarket

• J’ai vu ce message posté sur GitHub le 20 avril, et je suis un peu perplexe
  "deependujha hi @thebaptiste, thanks for inquiring. Release of 2.6.2 is blocked due to some internal reasons. Will notify once release is made."
  Si cela veut dire qu’ils connaissaient le problème depuis ce moment-là sans prévenir jusqu’à aujourd’hui, ça me déplairait vraiment
  J’aimerais qu’une personne mieux informée clarifie la situation
  https://github.com/Lightning-AI/pytorch-lightning/issues/216...

  • Andy de Lightning ici. Le paquet malveillant a été publié sur PyPI aujourd’hui à 12:45 PM UTC
    Avant cela, aucune distribution affectée n’existait et nous n’avions pas connaissance de la fuite
    La release d’origine sur GitHub n’avait aucun problème, mais nous l’avons retirée pour éviter toute confusion
  • Pour les utilisateurs de uv : https://docs.astral.sh/uv/reference/settings/#exclude-newer