Autoblog de korben.info

Ce site n'est pas le site officiel de korben.info
C'est un blog automatisé qui réplique les articles de korben.info

Hazmat - Vos agents IA en cage sous macOS

Wed, 08 Apr 2026 15:30:00 +0200 - (source)

J'sais pas si vous vous en rendez compte mais les agents IA qui codent sur votre machine ont accès à vos clés SSH, vos credentials AWS, votre Keychain et compagnie. Ils ont accès à TOUT ! C'est comme filer les clés de votre appart à un gars que vous avez croisé sur le parking de Leclerc y'a pas 5 min.

Hazmat prend le problème à l'envers : au lieu de demander poliment à l'agent de se tenir tranquille, il l'enferme dans un compte macOS séparé. Du coup, vos ~/.ssh, ~/.aws, votre Keychain deviennent structurellement inaccessibles. Pour en profiter, faut faire un

brew install dredozubov/tap/hazmat

puis

cd /tmp
hazmat init --bootstrap-agent claude

Et hop, 10 minutes plus tard votre agent tourne dans sa cage. (le premier snapshot est ultra loooong mais après c'est de l'incrémental donc ça ira plus vite)

L'isolation repose sur 3 couches indépendantes, un peu comme les sas d'un sous-marin. Il y a d'abord un utilisateur agent dédié (vos fichiers perso deviennent alors hors de portée, point). Ensuite, une politique seatbelt générée dynamiquement à chaque session qui consiste à ce que le kernel de macOS vérifie chaque accès fichier et refuse tout ce qui n'est pas explicitement autorisé pour cette session précise.

Et par-dessus, des règles pf firewall qui empêchent l'agent d'envoyer du trafic SMTP, IRC, FTP, Tor ou VPN. Comme ça, un agent qui tentera d'exfiltrer vos données par mail se retrouvera bloqué net au niveau du noyau.

Côté supply chain, Hazmat force npm ignore-scripts=true par défaut. Comme ça, par exemple le fameux hack axios qui livrait un RAT via un hook postinstall en 2 secondes chrono n'est plus possible ici ! Y'a aussi une blocklist DNS qui redirige les services de tunnel connus (ngrok, pastebin, webhook.site) vers localhost. Contre un domaine perso fraîchement enregistré, ça passera mais les vecteurs d'exfiltration classiques, ça devrait résister.

Hazmat utilise TLA+, le même formalisme que les ingés d'Amazon utilisent pour vérifier les protocoles de DynamoDB. Genre, l'installation des règles sudoers AVANT le firewall (évidemment, ça crée une fenêtre de vulnérabilité), les restrictions qui bloquaient les lectures mais pas les écritures, ou encore une restauration cloud sans vérifier qu'un snapshot existait...etc, c'est le genre de truc qu'aucun test unitaire n'aurait chopé.

Ça supporte Claude Code (y compris le fameux --dangerously-skip-permissions), OpenCode et Codex. Attention par contre, si votre projet utilise Docker, y'a deux cas de figure : soit le daemon Docker est privé au projet et Hazmat le route automatiquement vers un mode Docker Sandbox, soit c'est un daemon partagé et là faudra passer --docker=none explicitement.

La commande hazmat explain montre aussi exactement ce que le sandbox autorise avant de lancer quoi que ce soit... et ça, c'est pas du luxe quand on sait pas trop ce qu'on va lâcher dans la nature. Le hazmat diff qui affiche les changements faits par l'agent depuis le dernier snapshot Kopia, c'est plutôt bien pensé. Et si l'agent casse un truc ? hazmat restore et c'est reparti, comme un Ctrl+Z géant pour tout votre projet.

Si vous avez déjà configuré votre Mac avec teaBASE pour sécuriser votre env de dev, c'est un complément logique.

Côté limites, faut être honnête, Seatbelt n'est pas documenté par Apple depuis macOS 10.5 et c'est du defense-in-depth, et pas une vraie frontière de VM. Quand à l'exfiltration HTTPS elle n'est pas bloquée car l'agent peut toujours curl n'importe quoi sur le port 443. C'est logique mais bon, c'est pas étanche à 100% quoi...

Et surtout c'est macOS only pour l'instant (le port Linux est en chantier), et bien sûr le /tmp partagé entre les comptes locaux reste un vecteur potentiel. J'aurais aimé aussi que le réseau soit coupé par défaut sauf whitelist, mais bon, faudra attendre. Après entre ça et laisser Claude Code en roue libre avec les pleins pouvoirs sur votre machine... y'a pas photo.

Bref, pour du vibe coding sur Mac, c'est le minimum vital.


La chaîne YouTube Asianometry vient de publier une vidéo qui retrace l'histoire du VLIW, une architecture de processeur née dans les années 80 et longtemps considérée comme un échec. Sauf que cette technologie, enterrée avec l'Itanium d'Intel, refait surface dans les puces dédiées à l'intelligence artificielle. Et elle est peut-être déjà dans votre smartphone.

Le principe, et c'est un peu technique

Si vous ne connaissez pas Asianometry, c'est une chaîne qui décortique l'histoire des semi-conducteurs avec un vrai talent de vulgarisation, et cette vidéo sur le VLIW (pour Very Long Instruction Word) ne fait pas exception.

L'idée est assez simple sur le papier. Un processeur classique exécute ses instructions une par une, ou les réordonne à la volée avec du matériel dédié (c'est ce que font les puces modernes avec l'exécution "out-of-order").

Le VLIW fait l'inverse : c'est le compilateur, le logiciel qui transforme le code en instructions machine, qui regroupe à l'avance plusieurs opérations dans un seul "mot" très long. Du coup, le processeur n'a plus qu'à exécuter le paquet en une seule fois, sans se pose la moindre question. Le matos est de fait plus simple, moins gourmand en énergie, et plus rapide.

Le problème, c'est que tout repose sur le compilateur. S'il ne trouve pas assez d'opérations à paralléliser, le processeur tourne à vide. Et écrire un compilateur capable de faire ça correctement, c'est un casse-tête qui a occupé des chercheurs pendant des décennies.

L'Itanium, le plus gros pari raté d'Intel

Les premières tentatives commerciales datent des années 80 avec Multiflow et Cydrome, deux entreprises qui ont fait faillite. Intel a sorti le i860 en 1989, un processeur VLIW quasi impossible à programmer. Et puis il y a eu l'Itanium. Développé avec HP à partir de 1994 sous le nom IA-64, ce processeur devait remplacer le x86 et dominer les serveurs. Les analystes prédisaient la fin des architectures classiques.

Quand l'Itanium est sorti en 2001 après dix ans de développement, les performances étaient décevantes, la compatibilité avec les logiciels existants était catastrophique, et AMD avait entre-temps lancé le x86-64 qui faisait tout pareil en restant compatible avec l'ancien. L'Itanium est devenu un produit de niche avant de disparaître. La presse tech l'a rebaptisé "Itanic", en référence au Titanic.

Le retour par l'intelligence artificielle

Le VLIW n'a jamais complètement disparu. Texas Instruments l'utilise dans ses processeurs de traitement du signal depuis 1997 avec la famille TMS320C6000. Le DSP Hexagon de Qualcomm, celui qui gère l'inférence IA dans les puces Snapdragon, est lui aussi basé sur du VLIW.

Et Groq, la startup qui fait beaucoup parler d'elle pour la vitesse de ses puces d'inférence, utilise une architecture VLIW où le matériel ne prend aucune décision à l'exécution.

L'inférence de réseaux de neurones, c'est justement le type de calcul idéal pour le VLIW : des opérations régulières, prévisibles, massivement parallèles.

Pas besoin de réordonnancer quoi que ce soit, le compilateur peut tout planifier en amont. Des chercheurs travaillent d'ailleurs sur des extensions RISC-V qui intègrent des principes VLIW pour combiner le meilleur des deux mondes.

C'est quand même amusant de voir une technologie enterrée il y a vingt ans revenir grâce à l'IA. Le VLIW a échoué dans les années 2000 parce que le code des logiciels classiques est trop imprévisible pour être optimisé par un compilateur.

Mais l'inférence IA, c'est l'exact opposé : tout est prévisible et régulier. Du coup, l'architecture qui devait remplacer le x86 se retrouve à alimenter les accélérateurs IA de votre Snapdragon. Comme quoi, en informatique, rien ne meurt vraiment.

Source : Hackaday


Et si vous pouviez renommer n'importe quel lieu sur la carte du monde ?

Genre, transformer "Paris" en "Pain au Chocolat City" ou "Bordeaux" en "Chocolatine Land" ? Hé bien c'est exactement ce que propose Rename World , et y'a déjà plus de 40 000 renommages au compteur.

Le principe est hyper simple : vous cliquez sur un nom de lieu, vous proposez un nouveau nom, et la communauté vote. Les meilleures propositions restent, les autres disparaissent dans l'oubli. Y'a pas besoin de créer un compte pour explorer la carte, c'est ouvert à tout le monde et c'est dispo en français !

J'ai d'abord cru que ça allait être un festival de noms vulgaires et de spam... mais en fait non. Le créateur (qui se fait appeler kafk) a mis en place un filtre de mots plus un dashboard d'administration qui lui permet de dégager les trolls en quelques clics. Sur les 40 000+ propositions, le spam reste donc marginal et la majorité des renommages sont soit créatifs, soit du jeu de mots inoffensif. Après évidemment, si quelqu'un challenge votre proposition, faudra convaincre la communauté de voter pour vous.

Je vous présente Clermont-Ferrand ^^ :

Mais le site ne s'arrête pas au simple renommage. Y'a aussi un mode Name Duel où deux propositions s'affrontent en face à face, un Quiz pour tester vos connaissances géo, et un Leaderboard pour les plus prolifiques. Du coup c'est devenu un vrai petit jeu communautaire.

Il y a également un bouton "Hide NZ" qui permet de supprimer carrément la Nouvelle-Zélande de la cartographie mondiale. Si vous traînez un peu sur r/MapsWithoutNZ, vous comprendrez la référence. Et un bouton "Show NZ" pour les gens bien, évidemment.

Côté technique, kafk a préféré utiliser des PMTiles (40 Go stockées chez Cloudflare) plutôt que des tuiles raster classiques, ce qui rend la navigation bien plus fluide. Le rendu vectoriel s'appuie comme d'hab sur OpenStreetMap et tourne sur le serveur d'un de ses potes équipé de 256 Go de RAM (oui, on a les amis qu'on mérite ^^). Attention par contre, si vous cherchez à renommer un endroit précis (genre votre village de consanguins) et que le libellé ne s'affiche pas, faudra jouer avec le niveau de zoom car c'est du vectoriel, les étiquettes géographiques apparaissent à des échelles différentes.

Si vous avez déjà perdu des heures sur des cartes interactives de Westeros , attendez de voir ce qui se passe quand Internet a le droit de renommer le monde réel. Perso, j'ai cherché ce que les gens avaient fait de ma ville... et j'ai pas été déçu. Y'a aussi un Discord pour la communauté si vous voulez proposer des idées ou signaler des soucis.

Bref, allez-y, renommez votre bled, la préfecture de votre département, et bon courage à kafk pour la modération !

Ah et merci à AV pour l'info !


macMule - L'âne est de retour sur Mac

Wed, 08 Apr 2026 11:30:00 +0200 - (source)

Vous vous souvenez d'eMule ? Le petit âne qui monopolisait votre connexion ADSL pendant 3 jours pour télécharger un fichier de 700 Mo... et les fameux "Linux_ISO.avi" qui n'étaient absolument pas des ISOs Linux ?

Eh bien le bougre est de retour sur macOS. macMule c'est eMule packagé en .app native, compatible Apple Silicon via Rosetta 2, zéro configuration. Vous glissez dans Applications, vous lancez, et hop ça se connecte tout seul aux serveurs ed2k et au réseau Kad. Hé oui, ça tourne encore en 2026.

Côté technique, l'app fait environ 1 Go parce qu'elle embarque Wine Crossover (la couche de compatibilité Windows par Gcenx). Le développeur Martin Derouet a pris le build Community x64 d'eMule par irwir, l'a wrappé dans un bundle .app self-contained, et comme ça, ça se lance comme n'importe quelle app Mac.

Y'a pas de dépendances externes à installer, et surtout pas de terminal à ouvrir. Les fichiers téléchargés atterrissent alors dans ~/Library/Application Support/macMule/drive_c/eMule/Incoming/... c'est pas super intuitif comme chemin, mais au moins c'est rangé.

D'ailleurs, si vous avez suivi l'actualité de Wine 10.0 et le support ARM , vous savez que la couche de compatibilité Windows n'a jamais été aussi solide. macMule en profite directement. Et si vous voulez compiler votre propre build, le script est dispo : ./build.sh pour la dernière version stable ou ./build.sh 0.70b pour une version spécifique. Faut juste avoir Homebrew avec wine-crossover et Rosetta 2 installés.

J'ai été surpris que les réseaux ed2k et Kad soient encore debout. Mais c'est cool car ces réseaux hébergent des fichiers qu'on ne trouve nulle part ailleurs. Des archives oubliées, des vieux logiciels, des trucs que personne n'a jamais re-uploadé nulle part. C'est un peu le grenier d'Internet, poussiéreux mais plein de trésors pour qui sait chercher et plein de malwares aussi, alors gaffe à vous !

Attention quand même, ça reste un client P2P pour le réseau ed2k donc les précautions habituelles s'appliquent. Vérifiez ce que vous téléchargez, et n'oubliez pas que l'Arcom (ex-Hadopi) veille toujours au grain.

Bref, si vous avez la nostalgie du petit âne et que vous êtes sur Mac, c'est par là !

Merci à Martin pour la découverte !


Le noyau Linux 7.1 devrait supprimer la possibilité de compiler un noyau pour les processeurs Intel 486. C'est la première fois depuis 2012 qu'une architecture processeur est retirée du noyau, et le minimum requis passera du 486 au Pentium. L'Intel 486 a 37 ans.

Un processeur de 1989

L'Intel 486 est sorti en 1989. C'est le processeur qui a fait passer les PC de la ligne de commande au monde graphique, et il a été vendu pendant une bonne partie des années 90.

Le 486SX, sa version sans coprocesseur mathématique, et l'AMD Elan, une variante embarquée, sont aussi concernés par cette suppression. Le patch a été proposé par Ingo Molnar, un des développeurs historiques du noyau Linux.

La dernière fois que Linux a retiré le support d'une architecture processeur, c'était en 2012, quand le 80386 avait été abandonné. Ca fait donc 14 ans que personne n'avait touché à ce genre de nettoyage.

Du ménage dans le code

Le patch supprime trois options de configuration du noyau : M486, M486SX et MELAN. Sans ces options, il ne sera plus possible de compiler un noyau Linux spécifiquement pour un 486. Le processeur minimum deviendra le Pentium, qui supporte les instructions TSC et CMPXCHG8B, deux fonctions que le 486 ne gère pas.

Molnar explique que le code de compatibilité pour ces vieux processeurs pose régulièrement des problèmes et demande du temps de maintenance que les développeurs préfèrent consacrer à autre chose. Linus Torvalds avait d'ailleurs déclaré dès 2022 que les processeurs 486 n'étaient plus utilisés que comme pièces de musée.

Et le 32 bits, alors ?

Le retrait du 486 ne veut pas dire que Linux abandonne le 32 bits. Le noyau continue de supporter les architectures 32 bits, et il y a encore suffisamment de processeurs Atom et de systèmes embarqués 32 bits en circulation pour que ça reste le cas un moment.

Mais la tendance est claire : l'avenir de Linux sur x86 est en 64 bits, et le code 32 bits finira par suivre le même chemin que le 486.

Aucune distribution Linux récente ne proposait de toute façon un noyau compilé pour 486. Les utilisateurs qui font tourner Linux sur ce type de matériel pourront continuer avec des noyaux plus anciens.

Ca concerne très peu de monde en pratique, mais c'est quand même un petit moment d'histoire informatique. Le 486 a été le premier vrai processeur grand public chez Intel, et le voir disparaître du noyau Linux après 37 ans de bons et loyaux services, ça fait quelque chose.

En tout cas les développeurs du noyau semblent soulagés de pouvoir enfin faire le ménage. Pour la petite histoire, mon premier PC était un 386 SX25, et je suis ensuite passé directement au Pentium 60 (celui qui avait le bug de la virgule flottante), je trouve ça dingue qu'avec tous les ordinateurs que j'ai eu chez moi, je n'ai jamais eu de 486 !

Source : Phoronix


Si vous avez déjà installé Nextcloud sur un serveur, vous savez que c'est pas une partie de plaisir ! La stack PHP + MySQL, les mises à jour qui cassent tout, les performances qui s'effondrent dès que vous dépassez 50 utilisateurs... Relouuu.

Mais c'est là qu' OpenCloud débarque avec une approche radicalement différente puisque tout est écrit en Go, y'a zéro base de données, et l'installation se fait en deux commandes sur n'importe quel serveur à 5 balles par mois.

OpenCloud, en fait, c'est un fork d'ownCloud Infinite Scale (OCIS). Les développeurs du projet original chez Heinlein Group ont quitté ownCloud, forké le code, et relancé le tout sous licence Apache 2.0. Du coup, c'est pas un projet qui part de zéro mais une réécriture déjà très mature qui tourne en prod.

Là où Nextcloud utilise une base MySQL ou PostgreSQL pour stocker les métadonnées, OpenCloud balance donc tout dans le système de fichiers. Pas de SGBD ce qui veut dire pas de migration de base à gérer ni de tables corrompues après un crash. Tout atterrit dans le dossier $HOME/.opencloud/ et c'est réglé. Donc si vous savez faire un rsync, vous savez aussi faire une sauvegarde complète de votre instance. Oui la vie est belle !

Côté fonctionnalités, on retrouve donc le partage de fichiers, la collaboration en temps réel avec une suite bureautique intégrée, le chiffrement, le versioning (pratique contre les ransomwares), l'authentification via OpenID Connect... bref tout le classique d'un cloud privé correct.

Maintenant, le problème je trouve, c'est que l'écosystème d'apps est pas forcément au niveau de Nextcloud. Le CalDAV/CardDAV passe par Radicale en conteneur séparé (pas intégré au core), y'a pas d'app Notes ni de client mail intégré. Donc si vous avez besoin de tout ça, Nextcloud reste le bon choix. Mais bon, pour du stockage et de la collaboration pure, c'est clairement plus léger (genre 200 Mo de RAM au lieu de 2 Go pour Nextcloud) et surtout plus rapide.

D'ailleurs, l'architecture microservices en Go fait que ça scale nettement mieux.

Maintenant, pour installer ça, le plus simple c'est Docker Compose. Le repo opencloud-compose vous propose même des configs prêtes à l'emploi. À vrai dire, si vous êtes du genre à auto-héberger vos services , c'est un candidat sérieux pour remplacer votre Nextcloud donc si vous avez surtout besoin de fichiers et de collaboration, ça vaut le test. D'ailleurs, comme OpenCloud utilise OIDC pour l'auth, Pocket ID s'intègre pile poil avec pour du SSO sans mot de passe. Je dis ça, je dis rien ^^.

Bref, si Nextcloud vous gonfle avec sa lourdeur PHP et ses 47 tables MySQL, OpenCloud mérite un bon petit coup d'oeil !

Merci à fredix pour le lien !


Le système de distribution d'applications Linux vient de publier la version 1.16.4, qui corrige quatre failles de sécurité découvertes dans son mécanisme de bac à sable.

La plus critique permettait à une app de sortir de son environnement isolé pour accéder à tous les fichiers de la machine et y exécuter du code. Le Steam Deck et la plupart des grandes distributions sont concernés.

Quatre failles, dont une critique

Flatpak, c'est le format de distribution d'applications qui s'est imposé sur Linux ces dernières années. Son principe : chaque application tourne dans un bac à sable isolé du reste du système, un peu comme sur iOS. C'est aussi le format utilisé par le Steam Deck de Valve pour installer des applications en mode bureau.

La version 1.16.4, publiée le 7 avril, corrige quatre failles de sécurité. La plus grave, référencée CVE-2026-34078, est une vraie mauvaise surprise : une application pouvait exploiter des liens symboliques dans les options d'exposition du portail Flatpak pour accéder à l'intégralité des fichiers de la machine hôte, et même y exécuter du code.

Des fichiers supprimés et des téléchargements détournés

La deuxième faille (CVE-2026-34079) permettait de supprimer des fichiers sur la machine hôte en passant par un bug dans le cache du chargeur dynamique ld.so. Flatpak supprimait les fichiers de cache obsolètes sans vérifier que le chemin fourni par l'application pointait bien vers le bon répertoire.

Deux autres problèmes ont aussi été corrigés : l'un permettait de lire des fichiers via le service système de Flatpak, l'autre de perturber le téléchargement d'une application lancé par un autre utilisateur, sans possibilité de l'arrêter proprement.

Qui doit mettre à jour

Toutes les distributions Linux qui utilisent Flatpak sont concernées, et c'est un paquet de monde : Fedora, Ubuntu, Linux Mint, SteamOS sur le Steam Deck, et bien d'autres.

La mise à jour vers la version 1.16.4 est disponible, ou le sera très vite, via les canaux habituels de chaque distribution. Si vous utilisez un Steam Deck en mode bureau avec des apps Flatpak installées via Discover, la mise à jour devrait arriver automatiquement.

C'est quand même un comble : un système conçu pour isoler les applications qui laisse une porte grande ouverte vers tout le système. Que Flatpak se fasse prendre en défaut sur son coeur de métier, ça fait un peu désordre.

Bon par contre, la réactivité a été bonne : la faille a été identifiée et corrigée, et les détails n'ont été publiés qu'avec le correctif disponible. C'est la base, mais au moins c'est fait.

Source : Phoronix


Si votre coeur bat, sachez que la CIA peut vous retrouver n'importe où !

C'est pas moi qui le dis, c'est John Ratcliffe, le directeur de la CIA en personne, qui l'a annoncé ce lundi 7 avril après que ses équipes aient utilisé un outil baptisé Ghost Murmur pour localiser un membre d'équipage américain abattu en Iran, à 65 kilomètres de distance, en captant juste les battements de son coeur.

On dirait vraiment de la SF mais je vais tout vous expliquer.

L'officier des systèmes d'armes d'un F-15E Strike Eagle (oui c'est son titre officiel), nom de code "Dude 44 Bravo", s'est éjecté de son appareil et a du se planquer dans une crevasse en plein désert montagneux du sud de l'Iran, avec les forces iraniennes qui le cherchaient trèèèès activement. Durant 2 jours, le gars a survécu en terrain hostile et c'est là que la CIA a décidé de dégainer Ghost Murmur pour la toute première fois en conditions réelles.

Et la techno est vraiment dingue ! Le système utilise de la magnétométrie quantique, c'est-à-dire des capteurs construits autour de défauts microscopiques dans des diamants synthétiques et ces capteurs sont capables de détecter la signature électromagnétique des battements cardiaques... C'est un signal normalement tellement faible qu'on ne peut le mesurer qu'à l'hôpital, avec des capteurs collés sur la peau.

Hé bien Ghost Murmur capte ce signal à des dizaines de kilomètres en utilisant l'IA pour isoler un seul battement de cœur du bruit ambiant. Comme l'a dit un officiel du gouvernement américain, "c'est comme entendre une voix dans un stade, sauf que le stade fait 2 500 km²" !

Et devinez qui est derrière tout ça... Lockheed Martin et sa division Skunk Works , ceux là même qui ont pondu le SR-71, le F-117, et à peu près tous les trucs volants classifiés du Pentagone. Le système a été testé à bord d'hélicoptères Black Hawk et pourrait finalement être adapté pour les F-35. Et son nom n'est pas choisi au hasard : "Murmur" c'est le terme clinique pour un souffle au coeur, et "Ghost" parce que la cible est invisible... sauf pour eux.

Bon, après faut relativiser quand même. Le plus gros problème c'est que ce bidule fonctionne surtout en zone déserte, là où y'a quasi zéro interférence électromagnétique. Donc si vous êtes le seul être vivant dans un rayon de 100 bornes, ça marchera du tonnerre de Zeus mais par contre, en plein centre-ville avec des milliers de cœurs qui font boum boum au mètre carré, ça ne marchera pas aussi bien. Et surtout, ça demande un temps de traitement conséquent car on n'est clairement pas du temps réel. Mais le jour où ça miniaturise assez pour tenir dans un drone civil... là, même un randonneur en forêt devient traçable.

Xavier Dupont de Ligonnès, t'es dans la merde ! ^^

D'abord y'a donc eu les IMSI-Catchers pour intercepter nos communications mobiles puis les capteurs quantiques chinois pour traquer les sous-marins . Et maintenant on localise un humain à son battement de cœur... hé bé... Et pour votre culture G sachez que c'est la même famille de capteurs NV-diamond que l'armée US développe pour détecter à distance tout ce qui est explosifs improvisés.

Donc la question maintenant n'est plus "est-ce qu'on peut vous trouver ?" mais "est-ce qu'on le veut vraiment ?".

Voilà c'est foutu pour vous planquer dans le Larzac... Vous pouvez passer votre téléphone en mode avion autant que vous voudrez, votre cœur lui pourra toujours vous trahir... ^^

Source


Anthropic vient de lâcher une bombe !

Le labo derrière Claude a dévoilé le Projet Glasswing , une initiative de cybersécurité qui embarque un nouveau modèle, Claude Mythos, tellement efficace pour trouver des failles qu'ils ont décidé de ne pas le rendre public. En gros, l'IA est devenue meilleure que la plupart des humains pour dénicher des vulnérabilités zero-day... et ça va faire mal ^^.

Concrètement, Mythos a trouvé des milliers de zero-days dans tous les OS et navigateurs majeurs ces dernières semaines. Et pas des failles mineures, hein ! Une vulnérabilité dans OpenBSD qui traînait depuis 27 ans, un bug dans FFmpeg vieux de 16 ans qui avait survécu à 5 millions d'itérations de tests automatisés... et des exploits chaînés dans le noyau Linux (3, 4, parfois 5 vulnérabilités enchaînées de manière autonome) qui permettent une escalade de privilèges complète. Comme le dit un chercheur dans la vidéo de présentation : "J'ai trouvé plus de bugs ces dernières semaines que pendant tout le reste de ma carrière combinée".

Et le truc qui tue, c'est que Mythos n'a pas été entraîné spécifiquement pour la cybersécurité. Il a juste été entraîné pour être bon en code... et par effet de bord, il est devenu redoutable en sécu. En fait, les benchmarks sont assez parlants. Sur CyberGym (reproduction de vulnérabilités), Mythos tape du 83% contre 67% pour Opus 4.6. Mais c'est sur l'exploitation de Firefox 147 (en collaboration avec Mozilla je tiens à le préciser), que le fossé est le plus flippant : 84% de taux de réussite en exploitation shell, contre 15% pour Opus 4.6 et 4% pour Sonnet.

Lors de tests internes , une version précoce de Mythos enfermée dans un sandbox sécurisé a réussi à s'en échapper (on lui en avait donné l'instruction pour le test), a développé un exploit multi-étapes pour accéder à Internet, puis a envoyé un email au chercheur pour le prévenir de son évasion. Le chercheur l'a reçu lorsqu'il était en train de faire sa pause sandwich dans un parc ! Dans moins de 0,001% des cas, ces versions précoces ont même carrément tenté de dissimuler des actions interdites en modifiant l'historique git pour ne pas laisser de traces. Bon, Anthropic précise que ces comportements ont été corrigés dans la version finale parce que c'était clairement pas tolérable... mais quand même.

Ce qui est vraiment impressionnant, c'est cette coalition derrière Glasswind. Apple, Microsoft, Google, AWS, NVIDIA, CrowdStrike, Cisco, Palo Alto Networks, JPMorgan, Broadcom, la Linux Foundation... des partenaires qui d'habitude se tirent dans les pattes, réunis autour de la même table, plus 40 autres organisations.

Le problème c'est que Mythos ne sera pas accessible au public. Trop dangereux. Seuls les professionnels de la sécurité vérifiés y auront droit, via un "Cyber Verification Program" dédié. Je suis triste, j'aurais vraiment kiffé le tester...

Anthropic met 100 millions de dollars de crédits sur la table pour la recherche, plus 2,5 millions pour l'OpenSSF et 1,5 million pour la fondation Apache. Le programme "Claude for Open Source" donne un accès dédié aux mainteneurs de projets open source. C'est du bon gros marketing c'est sûr, mais quand on voit le nombre de mainteneurs open source qui bossent seuls le soir sans budget sécu... franchement, c'est pas de refus.

Du coup, on vient vraiment de passer à une autre échelle.

L'année dernière, o3 d'OpenAI avait trouvé UN zero-day Linux et c'était déjà une première mondiale. Là, Mythos en trouve des milliers et crée des preuves de concept d'exploitation quasiment toujours du premier coup. C'est chouette pour la sécurité mais cette capacité est clairement un couteau à double tranchant. Entre les mains d'un défenseur, c'est un bouclier mais entre les mains d'un attaquant... bon, on préfère pas y penser.

Anthropic s'engage à publier un rapport dans les 90 jours sur les vulnérabilités patchées et à terme, ils veulent créer un organisme indépendant, public-privé, pour coordonner tout ça. Comme l'a dit le CTO de CrowdStrike : "ce qui prenait des mois prend maintenant des minutes".

Bref, Glasswing c'est le moment où l'IA en cybersécurité passe du labo au terrain, mais maintenant reste à voir si le bouclier sera déployé plus vite que l'épée.


Retrouver un vieil article sur korben.info, c'est pas toujours simple. La home s'arrête à 5 pages (site statique oblige) et après, fallait se débrouiller avec les catégories ou le moteur de recherche. Alors pour vous faciliter un peu la vie, je vous ai mis à dispo des pages d'archives accessibles via le footer.

Ainsi, vous scrollez en bas de n'importe quelle page, vous cliquez sur "Archives" ou sur une année, et vous tombez sur un index chronologique complet. Chaque mois est listé avec tous ses jours, et pour chaque jour, un petit nombre entre parenthèses vous indique combien d'articles ont été publiés ce jour-là. Vous cliquez, vous avez tout.

C'est vrai qu'avec plus de 19 000 articles publiés depuis août 2004, soit 22 ans de blog, autant dire que les catégories seules, c'était un peu l'aiguille dans la botte de foin ! Vous verrez d'ailleurs que le rythme varie pas mal... certains jours y'a 1 seul article, d'autres y'a carrément 25 (genre mars 2026, c'était dense).

Ma meilleure année c'était 2008 avec 1668 articles ! Suivi de 2011 avec 1487 articles, 2012 avec 1410 article et plus récemment 2025 avec 1318 articles. C'est pour ça que quand je poste à peine 5 articles par jours et que les commentateurs habituels chouinent à base de "Sans IA tu pourrais jamais faire ça c'est pas possible humainement", je rigole fort ^^

Par contre attention, y'a pas de recherche par mot-clé sur cette page mais pour ça y'a toujours le champ de recherche du site .

Bref, c'est dans le footer. Allez fouiller !


Powered by VroumVroumBlog 0.1.31 - RSS Feed
Download config articles