Publication de l’incident de fuite de secrets sur la plateforme Hugging Face Spaces

• En début de semaine, un accès non autorisé lié aux secrets a été détecté sur la plateforme Spaces, et certains secrets pourraient avoir été accessibles depuis l’extérieur
• En réponse initiale, plusieurs tokens HF inclus dans les secrets ont été révoqués, et un e-mail d’information a été envoyé aux utilisateurs concernés
• Il est recommandé aux utilisateurs de régénérer les clés et tokens concernés, et de passer aux fine-grained access tokens, désormais définis par défaut
• Hugging Face mène l’enquête avec des experts externes en cybersécurité forensique et réexamine en parallèle ses politiques et procédures de sécurité
• Sur l’infrastructure Spaces, la suppression des org tokens, l’introduction d’un KMS, ainsi que le renforcement de la détection et de l’invalidation des tokens compromis ont été mis en place, et l’incident a également été signalé aux autorités compétentes

---

Accès non autorisé aux secrets Spaces et actions requises pour les utilisateurs

• Hugging Face a détecté un accès non autorisé lié aux Spaces secrets sur la plateforme Spaces
• Certains Spaces secrets pourraient avoir fait l’objet d’un accès non autorisé
• Lors du processus initial de remédiation, plusieurs HF tokens inclus dans les secrets ont été révoqués
  • Les utilisateurs dont les tokens ont été révoqués ont déjà été informés par e-mail
• Il est recommandé aux utilisateurs de régénérer leurs clés ou tokens
• Pour les HF tokens, il est recommandé de passer aux fine-grained access tokens, désormais définis par défaut

Renforcement de la sécurité de l’infrastructure Spaces et suites de l’incident

• Hugging Face enquête sur l’incident avec des experts externes en cybersécurité forensique et examine ses politiques et procédures de sécurité
• La sécurité de l’infrastructure Spaces a été renforcée ces derniers jours
  • Les org tokens ont été entièrement supprimés afin d’améliorer la traçabilité et les capacités d’audit
  • Un service de gestion des clés (KMS) a été introduit pour les Spaces secrets
  • Les capacités du système à identifier et invalider de manière préventive les tokens compromis ont été renforcées et étendues
  • La sécurité globale a été améliorée
• Lorsque les fine-grained access tokens auront atteint la parité fonctionnelle, le retrait complet des tokens read/write « classic » est prévu dans un avenir proche
• L’enquête sur les incidents potentiellement liés se poursuit
• Hugging Face a également signalé cet incident aux forces de l’ordre et aux autorités de protection des données
• Les demandes peuvent être adressées à [e-mail]

[GN⁺]

Avis sur Hacker News

• Il y a deux jours, j’ai parcouru les slides d’une conférence sécurité, et Jossef Harush Kadouri y montrait qu’en utilisant des modèles provenant d’endroits comme Hugging Face, l’auteur du modèle peut exécuter du code arbitraire sur ma machine.
  Je ne sais pas si les slides ont été publiées ailleurs, mais le fichier que j’ai reçu est ici : https://dro.pm/c.pdf (45 Mo), slide 188.
  Sur le moment, je n’avais pas réalisé que cela signifiait que la même chose était possible non seulement pour l’auteur du modèle, mais aussi si Hugging Face recevait une injonction judiciaire ou se faisait pirater. Surtout si la compromission n’est pas détectée pendant un certain temps¹.
  Je suis en dehors du secteur de l’IA et je n’ai jamais exécuté moi-même ce type de modèle, mais j’ai été surpris de voir à quelle vitesse le secteur avait standardisé les formats. Je pensais qu’un fichier de modèle était une grosse matrice de nombres avec un peu de métadonnées, mais d’après les slides 186 et 195, il semble que les modèles soient en fait des scripts Python pouvant faire à peu près ce qu’ils veulent, ce qui a probablement facilité la standardisation. Laisser chacun faire ce qu’il veut contourne le problème, mais cela a un coût.
  ¹ Selon https://www.verizon.com/business/resources/articles/s/how-to..., 20 % des compromissions ne sont pas détectées pendant des mois. Bien sûr, cela dépend de la situation et du comportement de l’attaquant.
  • À propos de « je pensais qu’un fichier de modèle était une grosse matrice de nombres avec un peu de métadonnées », ONNX[1] est globalement assez proche de cela.
    Le problème auquel on se heurte rapidement, toutefois, ce sont les couches/opérateurs personnalisés et leur logique d’inférence. Il faut les implémenter uniquement avec les opérations prises en charge, ce qui peut être difficile, voire impossible en pratique ; sinon il faut fournir l’implémentation de l’opérateur au runtime, et on revient finalement au point de départ.
    [1] https://onnx.ai/
  • N’est-ce pas justement pour cela qu’il existe le format .safetensors, qui ne peut pas exécuter de code sur l’hôte ?
  • Comme d’autres l’ont souligné, cela dépend du format. Parmi les formats qui n’ont pas encore été mentionnés dans ce fil comme étant du côté sûr, il y a GGUF, utilisé par llama.cpp et ses projets dérivés.
    C’est un format assez proche d’une « grosse matrice de nombres avec un peu de métadonnées », et quelques vulnérabilités ont été découvertes puis corrigées.
    [1] https://www.databricks.com/blog/ggml-gguf-file-format-vulner...
  • À ma connaissance, ce problème ne survient que lorsque le modèle est sérialisé/désérialisé avec pickle[0].
    [0] : https://huggingface.co/docs/hub/en/security-pickle
  • Le lien dro.pm va bientôt expirer. C’est un lien temporaire, donc court, et j’aurais peut-être dû utiliser un service plus pérenne.
    Pour les personnes qui liront plus tard, j’ai trouvé la vidéo de la présentation : https://m.youtube.com/watch?v=8XysLIq-e3s
• Commencer par « ils soupçonnent » est une formulation qui laisse beaucoup trop de portes de sortie. Cela me semble inadapté pour une phrase dans ce type de communication.
  • Au contraire, j’ai trouvé ça plutôt correct. D’habitude, dans ce genre d’avis de fuite, comme on « ne sait pas » ce que les hackers ont fait après être entrés, on formule les choses du type « nous n’avons aucune preuve que des secrets aient été consultés ».
    Hugging Face dit au moins, en substance, « il est probable que des secrets aient été consultés, mais nous ne pouvons pas le confirmer », ce qui me paraît plus honnête.
• Ils disent avoir « considérablement amélioré la sécurité de l’infrastructure Spaces ces derniers jours », avec suppression complète des tokens d’organisation, renforcement de la traçabilité et des fonctions d’audit, introduction d’un KMS pour les secrets Spaces, amélioration de l’identification des tokens exposés et de leur invalidation proactive, ainsi que des améliorations générales de sécurité ; cela fait beaucoup de travail à terminer en « quelques jours ».
  Ce type de changement ne devrait-il pas entraîner des procédures plus longues avant la mise en production, comme un audit de sécurité ou des tests d’intrusion ?
  • J’espère que c’était déjà en cours depuis un moment, et qu’ils l’ont déployé maintenant parce que le mal était déjà fait.
  • C’est vrai pour une grande organisation dotée d’un département SRE comprenant une équipe sécurité dédiée, mais j’ai l’impression que Hugging Face n’est pas encore une organisation de cette taille.
• Ma clé Anthropic a fuité et quelqu’un a généré 10 000 dollars de facturation. Hugging Face va-t-il m’indemniser pour ça ?
  • Ma clé OpenAI a aussi fuité et j’ai vu quelqu’un l’utiliser. Heureusement, les dégâts ont été bien plus limités, seulement quelques dollars de GPT-4, et mes applis n’utilisaient même pas ce modèle à ce moment-là.
    Je suis presque certain qu’elle a fuité via les secrets d’un HF Space. Il y a quelques jours, j’ai reçu un message d’avertissement indiquant que certains de mes Spaces avaient été affectés.
  • Es-tu sûr que cette clé n’était réellement stockée que dans les secrets du Space ? Les variables sont publiques, et ce qui est stocké dans un fichier .env l’est aussi.
  • Je pensais que les plateformes de fournisseurs cloud permettaient généralement de définir un plafond maximal de dépenses.
• Il y a quelques semaines, j’ai remarqué que plusieurs de mes clés OpenAI avaient été compromises, et ces clés n’étaient actives que comme secrets dans un Hugging Face Space.
  J’ai reçu il y a quelques jours un e-mail indiquant que les Spaces concernés avaient été compromis ; ce problème semble donc remonter à au moins plusieurs semaines.
• Il n’y a aucune mention de la manière dont les coûts générés indûment seront traités. S’ils pouvaient accéder aux secrets, ne pouvaient-ils pas appeler des API et accumuler des frais ?
  Ou bien s’agit-il uniquement d’un problème de vol de données/code ?
  • Les deux sont possibles. Dans mon cas, la clé a été utilisée pour des appels OpenAI, et je suis presque certain qu’elle a fuité depuis les secrets Spaces.
• C’est quoi un « Space » ?
  • C’est l’abréviation de Spaces de Hugging Face.
    https://huggingface.co/docs/hub/en/spaces-overview
    Cela ressemble à la partie frontend/portail, probablement écrite en Python. Peut-être quelque chose comme Django.
  • C’est une machine virtuelle qui exécute le code de l’utilisateur.
• Pourquoi HF stocke-t-il des « secrets » ?
  Ne pourraient-ils pas stocker uniquement des clés publiques, laisser l’utilisateur détenir la clé privée, puis signer les requêtes ?
  • On peut créer une appli hébergée sur HF et accéder à des API externes comme OpenAI ou Anthropic. Dans ce cas, la clé d’API est stockée dans les secrets HF.
  • En général, pour fonctionner réellement dans une session de navigateur, il faut une forme de token. Il semble que cette affaire concerne des tokens qu’il a fallu révoquer ; c’est comparable à un mot de passe, sans être exactement la même chose.