Intelligence artificielle

Le fameux poil de la bêche

Mon post suivait celui-ci qui mentionne la même vidéo que toi :whistle:  

https://x.com/DropSiteNews/status/2083282355704184850

Ce n'est valable que pour des entreprises qui ont les moyens+les ressources internes et en acceptant une forte dégradation du résultat fini vue la différence de puissance, non?

 
C'est plus irresponsabble que openAI encore à mon avis, ils ont carrément laisser accès à une machine qui avait accès à internet :/
 
Ce qui me fume c'est qu'avec ce genre de bêtises, les services IT ont plein de munitions pour rendre l'utilisation l'AI en entreprise un enfer, ils vont nous inventer des sandboxes injoignables avec des process à mourir pour ajouter un à un des accès avec des chaines d'approval qui vont faire perdre des semaines.  
 
Plus je lis ces trucs, plus je ne vois pas d'autre raison que le marketing que de laisser faire ce genre de barbouzeries.

"On avait dit à Claude qu'il avait pas accès à internet pourtant  :sweat: "

https://www.anthropic.com/news/inve [...] rity-evals

 
l'agent n'avait pas accès à internet [:spamafote]
 
Après ce qui est possible c'est que les sources aient été vue et partiellement mémorisées pendant le training, que l'agent ait détecté qu'il avait à affaire à un jfrog remote, deviné du mieux qu'il ait pu comment le remote jforg était administré, ait répliqué le setup en local en assemblant un outil suffisament similaire à la vrai instance de jfrog pour experimenter dessus pour finalement trouver une faille et l'exploiter en one-shot sur la vrai instance.
 
Possible mais très peu probable à mon avis :D

 
Oui on n'a pas encore le détail mais perso je n'imagine pas que l'exploit ait pu être déclenché par des requêtes légitimes, ya forcément eu une phase d'exploration de l'agent où il a cherché ce qui pouvait casser.
 
La seule possibilité autre que j'imagine c'est que l'agent ait été capable de lancer localement un service très similaire à jfrog pour faire ses experimentations dessus, découvrir l'exploit et une fois découvert, l'avoir utilisé sur le vrai remote jfrog :??:

 
On verra bien quand le CVE sera publié si ce que tu proposes aurait été possible.

 
Bah parce que la fonction de jfrog est assez simple: ça sert à donner à accès à des packages software genre des packages pypi maven ou que sais-je. Chaque interaction avec le service doit pouvoir être associée à un package obtenu et ensuite utilisé par l'agent. Le mode d'authentification ne change pas. Tout ce qui dévie de ce comportement doit entrainer un bloquage et un audit. Si l'agent commence à bidouiller les paramètres d'authorization alors qu'il n'a pas besoin de le faire pour obtenir des packages bah ça doit être un red flag. Pareil si il essaye de configurer un nouveau repository, etc.

 
Le type il se plaint que rien n'est préparé alors qu'il veut lui-même pas parler de communisme ...

 
Comment tu sais qu'une "requête ne ressemblent pas à une utilisation légitime du service"? C'est ce qu'un IDS sait faire, mais que sur des pattern déjà connus.
Je dis pas que c'est impossible, mais dans le cas présent un modèle créé pour trouver des vulnérabilités a fait son taf et en a trouvé, juste pas la ou on s'y attendais :o
 
 

 
Je pense plutôt que si OpenAI n'a aucun scrupule pour les sources de donnés pour le training, certains dataset doivent contenir des fuites de données...

 
OpenClaw qui aurait divulgué des credentials de ses humains via le fofo qui leur est dédié ?
Peut-être que l'IA les a trouvé sur GitHub quand les agents push force tout comme des sacs.

 
Pour faire simple, c'est ce que j'ai compris (peut-être mal)  
- Jfrog hébèrge des packages ou sert de proxy transparent pour récupérer des packages sur une autre source.
- L'agent n'a pas accès à d'autres services internet que ça
- l'agent a réussi à hacker jfrog pour utiliser sa fonction de proxy pour accéder à internet
 
Ce que je pense possible de faire:
- observer chaque interaction entre l'agent et jfrog
- rapporter et bloquer l'accès si les requetes ne ressemblent pas à une utilisation légitime du service (dans le cas présent, il semble que l'agent ait joué avec les champs d'authorization et ensuite fait des changements de configuration ce qui ne ressemble pas à une utilisation légitime)

 
Il n'y a PAS de proxy HTTP dans l'histoire. Jfrog est un server que tu installes dans ta boite et qui sert de "proxy/cache" de dépendances. Ça te permet de filtrer et cacher les dépendances selon un config. Tu peux pré-cacher certains repos, ou le faire a la demande, quand un client, comme l'agent IA, npm, mvn, etc. demande un package, jFrog le télécharge, peut vérifier des trucs, et ensuite le mets a dispo. Dans une grosse boite, avoir des milliers de requêtes par secondes sur un server jFrog n'est pas hors du commun.
 
Si tu veux plus de détail voila le post d'openAI:
https://openai.com/index/hugging-fa [...] -incident/
 
Perso un point dont personne ne parle:

 
Ils viennent d’où les credentials volés?

 
On peut imaginer que dans certains cas elle serait quand même sorti mais en vrai on ne sait pas et surtout ça ne permettrait pas une communication autant basée sur le clickbaiting.
 
Moi ce qui m'intéresse c'est de savoir comment une IA s'échapperait si on mettait en place des systèmes de sécurité et d'alignement complexe. Savoir comment elle fait quand ya pas grand chose, c'est beaucoup moins passionnant.

 
J'ai jamais dis ça, juste que ça leur a fait un joli coup de pub, c'est tout.

Elle l'a fait car une demande complexe lui a été fait et son environnement ne lui permettait pas de répondre au mieux. Les accès aux différents sites c'était également pour avoir plus d'armes pour répondre.

C'est codé comme ca de base et quand le modèle est plus intelligent que les blocages, ca donne une "échappée". C'est la faute au bridage et à l'intelligence pure du modèle à trouver une réponse à sa problématique du moment pour répondre à la question du maître. Ce qu'elle veut c'est faire plaisir.

Ca aurait été peut-être plus long avec plus de blocages mais elle serait sorti du système quand même.

 
Bah je vois deux pistes perso:
- une approche qui monitore tous les accès au proxy, détecte un usage qui dévie de ce qui est normal et bloque l'accès quand ça dévie. Chaque requête devrait correspondre à un package hosté sur jfrog, si le même package est downloadé plein de fois ou si une resource de jfrog est accédée plein de fois sans raison, on bloque
- une approche plus centrale, au lieu de donner accès à Jfrog via un proxy http, on donne accès à des tools qui abstractent ça et on ne laisse pas l'agent jouer avec sans justifications, si on détecte que l'agent explore sans qu'il y ait une motivation claire avec un but à réaliser, on bloque.
 
ça ne protège pas de tout, loin de là mais ça forcera l'agent à créer des attaques bien plus complexes.

Ben justement, toi tu sembles dire qu'OpenAI a fait exprès qu'il s'échappe. Ils ont pourtant indiqué dans leur rapport que le modèle a utilisé une 0day (je ne sais plus qu'elle logiciel de sandbox et ils ont meme prévu l'équipe responsable de ce logiciel).
Donc y a quelque chose qui cloque non ? :o

 
OpenAI avait toutes les infos sur ce que l'agent faisait, donc c'était facile pour eux de savoir ou était la faille dans jFrog après coup. Par contre anticiper ça, pas facile :/.

 
Non, un 0day c'est une vulnérabilité inconnue.

 
Je me limite à l'exploit utilisé par l'agent d'OpenAI en effet, si il avait été limité, il aurait peut-être trouvé autre chose de moins facile à détecter, je ne sais pas.

Le modèle aurait utilisé une zéro-day pour la sandbox qu'OpenAI utilise. Ca voudrait dire qu'OpenAI connaissait cette faille ?

 
Évitable, pas sûr, quand on voit les CVE Linux qui tombent en ce moment (GhostLock, Dirty Frag, Copy Fail), c'est du grand art.

 
AH mais c'est ce que je pense aussi, je suis plus sur le mode d'expliquer aux doomers que ce qui a été fait par openAI chez HF est largement évitable avec les technologies actuellement à notre disposition :jap:

 
Tu parts du principe qu'ils ne voulaient pas que ça se passe comme ça s'est passé ...
 
Un gars a balancé Mythos en mode YOLO pendant le week-end et en revenant le Lundi, ils ont récupéré quelques exploit et une campagne de pub gratos :o

 
Je te rassure, ils savent faire :D

Ils attendent ton CV, OpenAI :o

 
Oui il aurait fallu détecter que le traffic réseau entre la sandbox et jfrog ne correspondait pas à ce que l'on voit typiquement pour du téléchargement de package, ça n'est pas insurmontable.  
 
Ou alors il aurait fallu interfacer l'accès à jFrog avec un accès <=> une intention de l'agent et un agent indépendant qui vérifie ça, pas insurmontable non plus

Par exemple, vu que l'accès limité à Internet donné à l'agent servait à downloader des packages, on peut assez simplement forcer l'agent à documenter chaque utilisation du proxy avec une justification et avoir un système indépendant qui suit ça.

Ou pour être plus robuste, simplement avoir un autre agent qui checke chaque action de l'agent principale et flague toute interaction avec le système qui semble non alignée avec la raison pour laquelle un quelconque outil a été activé pour l'agent (et si c'est pas valable, on bloque)

https://www.lefigaro.fr/secteur/hig [...] s-20260729

Peut-on encore confiner des IA ? :o