Vue normale

Il y a de nouveaux articles disponibles, cliquez pour rafraîchir la page.
À partir d’avant-hierKorben

ls, grep, cp : Microsoft fait entrer les commandes Linux nativement dans Windows

3 juin 2026 à 18:08

À sa conférence Build 2026, le 2 juin, l'éditeur a lancé Coreutils for Windows, un paquet qui amène directement dans Windows les commandes de base bien connues des utilisateurs de Linux.

On parle des classiques du terminal, ls pour lister des fichiers, cp pour copier, mv pour déplacer, grep pour chercher du texte, ou encore cat, find et rm. Au total, près de 75 petites commandes que tout bidouilleur tape machinalement sans même y penser.

Au passage, une petite précision historique s'impose (et merci à MG pour le rappel) : si on les appelle par habitude des « commandes Linux », ces classiques sont en réalité bien plus vieux que ça. ls, cp, cat et compagnie viennent d'Unix, le système né au tout début des années 70 dans les labos de Bell, soit une bonne vingtaine d'années avant que Linux ne débarque en 1991. On les retrouve d'ailleurs dans à peu près toutes les versions d'Unix, de Solaris aux BSD jusqu'à macOS, et Linux n'a fait qu'hériter de ce patrimoine. Donc « commandes Unix » serait techniquement plus juste, mais bon, on se comprend.

Le but affiché est simple. Les développeurs jonglent en permanence entre Windows, macOS et Linux, et s'agacent quand une commande qui marche d'un côté refuse obstinément de fonctionner de l'autre. L'idée, ici, c'est de pouvoir réutiliser les mêmes commandes et les mêmes scripts partout, sans rien réécrire.

Le plus intéressant, c'est ce qu'il y a sous le capot. Et là, surprise. Coreutils for Windows ne réinvente rien, puisqu'il s'appuie sur uutils, un projet communautaire qui réécrit les fameux coreutils de GNU en Rust, un langage réputé pour éviter toute une famille de bugs mémoire.

Autrement dit, Microsoft reprend un travail open source mené par la communauté, l'empaquette proprement et le maintient sous son nom. Le tout s'installe en une seule ligne via WinGet, le gestionnaire de paquets maison de Windows, avec un simple winget install Microsoft.Coreutils.

Côté technique, l'astuce est plutôt élégante. Plutôt que de livrer un exécutable par commande, Microsoft fournit un unique programme, coreutils.exe, et crée à l'installation une série de raccourcis (ls.exe, cp.exe, grep.exe et les autres) qui pointent tous vers lui. Selon le nom que vous tapez, ce programme sait quelle casquette enfiler. Malin.

Tout n'a pas fait le voyage, cela dit. Des commandes comme chmod, chown ou kill restent sur le carreau, faute d'équivalent propre sous Windows, qui ne gère pas les permissions de fichiers à la manière d'Unix.

Ce n'est d'ailleurs pas un geste isolé. Depuis des années, Microsoft a glissé un vrai noyau Linux dans Windows avec WSL, ouvert le code de pans entiers de ses outils et multiplié les passerelles avec l'écosystème open source. Coreutils for Windows s'inscrit dans cette continuité, et confirme que l'éditeur a définitivement enterré la hache de guerre.

Reste que pour quiconque vit dans un terminal et passe ses journées entre WSL, la couche Linux intégrée à Windows, et l'invite de commandes classique, c'est un vrai confort au quotidien. Et voir Microsoft s'appuyer ouvertement sur du logiciel libre écrit en Rust, on n'aurait pas forcément parié là-dessus il y a dix ans.

Bref, le Microsoft qui détestait Linux est bel et bien mort, et c'est tant mieux pour ceux qui codent les deux pieds dans le terminal.

Source : Bleeping Computer

Microsoft lance Intelligent Terminal, un terminal open source qui vous laisse choisir votre IA

3 juin 2026 à 10:55

Microsoft a présenté le 2 juin, pendant sa conférence développeurs Build 2026, une version expérimentale de son terminal baptisée Intelligent Terminal 0.1, un logiciel open source publié sous licence MIT qui intègre directement des assistants IA dans la fenêtre où l'on tape des commandes.

Pour situer le truc si vous êtes vraiment très noob, le terminal c'est cette interface en texte que les développeurs et les administrateurs système utilisent au quotidien pour lancer des commandes, compiler du code ou piloter un serveur à distance. Microsoft propose déjà Windows Terminal depuis des années, et Intelligent Terminal en est une déclinaison distincte, pas un remplacement.

L'élément central, c'est l'agent pane, un panneau ancré sur le côté de la fenêtre qui joue le rôle de copilote. Il lit en permanence ce qui s'affiche dans votre terminal, et quand une commande échoue, il détecte l'erreur et vous propose une explication ou un correctif.

Vous pouvez choisir de recevoir une simple notification dans la barre d'état, ou laisser l'assistant appliquer directement ses corrections selon la configuration que vous avez définie.

Il y a aussi une astuce intégrée à la palette de commandes : tapez un point d'interrogation suivi de votre demande, et l'outil lance une tâche en arrière-plan dans un onglet dédié, sans bloquer la session en cours. Pratique quand on veut déléguer une opération longue sans interrompre son travail.

Côté assistants, Microsoft a fait un choix ouvert. Par défaut, c'est GitHub Copilot CLI, l'assistant maison qui fonctionne en ligne de commande. Mais Intelligent Terminal accepte n'importe quel agent compatible avec l'Agent Client Protocol (ACP), une norme qui permet à différents assistants IA de venir se brancher sur le même outil.

Vous pouvez donc passer par Claude Code, l'assistant de codage signé Anthropic, le concurrent d'OpenAI, ou par Codex, l'équivalent maison d'OpenAI, à la place de la solution de Microsoft. C'est suffisamment rare chez l'éditeur de Windows pour être signalé.

Le logiciel s'installe depuis le Microsoft Store ou via la commande winget install Microsoft.IntelligentTerminal, et il se pose à côté de Windows Terminal sans le remplacer. Microsoft précise que si vous ne voulez pas d'IA dans votre terminal habituel, rien ne change pour vous.

Il y a quand même un détail qui coince, et c'est Phoronix, le site spécialisé dans l'actualité Linux, qui le relève : malgré son code ouvert publié sous licence MIT, Intelligent Terminal ne tourne pour le moment que sous Windows.

On parle aussi d'une version 0.1 estampillée expérimentale, ce qui annonce des bugs et des changements à venir avant une éventuelle version stable.

Bref, un terminal open source qui laisse l'utilisateur choisir son IA au lieu d'imposer la sienne, c'est un geste plutôt bien pensé de la part de Microsoft.

Source : Phoronix

De faux utilitaires PC transforment votre carte graphique en mineur de crypto à votre insu

1 juin 2026 à 15:11

Vous installez CrystalDiskInfo pour surveiller l'état de vos disques, FurMark pour pousser votre carte graphique dans ses retranchements, HWMonitor pour garder un œil sur les températures... Attention !

Sauf que depuis quelques semaines, certains de ces téléchargements sont piégés. Les équipes Microsoft Defender Experts ont repéré, depuis le mois de mars, plus de 150 faux sites qui se font passer pour ces utilitaires et installent en douce un mineur de cryptomonnaie.

Le choix des logiciels copiés n'a rien du hasard. À cette liste s'ajoutent Display Driver Uninstaller, l'outil qui nettoie en profondeur les pilotes graphiques, le K-Lite Codec Pack ou encore PDFgear. Ce sont exactement les programmes qu'installe quelqu'un qui possède une grosse carte graphique dédiée, justement le composant qui rend le minage rentable.

Le but, c'est de faire tourner cette carte à votre insu pour fabriquer de la cryptomonnaie au profit des pirates, ce qu'on appelle le cryptojacking. Reste à attirer les victimes. Les attaquants trafiquent le référencement, pour propulser leurs faux sites tout en haut des résultats de recherche.

Et depuis avril, ils ont ajouté un canal : les chatbots IA. Quand un utilisateur demande à un assistant où récupérer tel logiciel, la réponse générée peut très bien pointer vers un domaine contrôlé par les pirates, présenté avec le même aplomb qu'un lien parfaitement sain.

Le piège, lui, est bien construit. Dans le ZIP, le vrai logiciel s'ouvre normalement. Mais à côté dort autorun.dll, une bibliothèque piégée que l'exécutable charge tout seul, sans la moindre alerte, par une technique de détournement appelée DLL sideloading. Le code malveillant passe pour un composant attendu, et Windows ne bronche pas.

Ensuite tout s'enchaîne. msiexec, l'installateur intégré à Windows, dépose un second fichier, vcredist_x64.dll. Le nom singe le Visual C++ Redistributable, un composant Microsoft qu'on croise partout. Sauf que c'est un faux. Dessous se cache ScreenConnect, un vrai outil d'administration à distance, qui ouvre aux pirates une porte permanente sur votre PC.

Et le minage démarre. lolMiner, gminer, SRBMiner-MULTI : des mineurs GPU connus se mettent à faire tourner votre carte pour fabriquer de la crypto. Le plus vicieux, c'est leur patience, parce qu'ils attendent que la machine soit au repos pour bosser et se figent à la seconde où vous lancez un jeu ou une grosse application. Vous ne voyez rien.

Pendant ce temps, votre carte chauffe et s'use pour enrichir un parfait inconnu. Et votre facture d'électricité grimpe, sans la moindre contrepartie.

La parade est toute bête. Pour installer un utilitaire, ne cliquez pas sur le premier lien d'un moteur de recherche ou d'un chatbot. Passez par le site officiel de l'éditeur, ou par le Microsoft Store.

Bref, le point faible n'est plus le téléchargement louche au fond du web, mais le réflexe de cliquer sur le premier lien venu, suggestion d'IA comprise.

Source : Microsoft

AudioHijack - Le son inaudible qui pirate votre assistant IA

Par : Korben ✨
19 mai 2026 à 07:46

Meng Chen, doctorant à l'université Zhejiang, vient de prouver avec son équipe qu'on pouvait complétement détourner un assistant vocal IA avec un simple son que vous prendriez probablement pour un simple parasite. Avec sa bidouille, il a ainsi réussi à pousser les agents vocaux commerciaux de Microsoft et de Mistral à exécuter des actions que personne ne leur avait demandées.

Gloups !

L'attaque s'appelle AudioHijack, et ça consiste à planquer des ordres dans un fichier audio, une vidéo, un clip musical, une note vocale. Comme ça, le modèle qui l'écoutera vous obéira à VOUS, plutôt qu'à l'utilisateur. C'est comme une injection de prompt sauf que celle-ci s'entend à peine.

"Une demi-heure pour entraîner le signal, et comme il ignore le contexte, vous attaquez quand vous voulez, peu importe ce que dit l'utilisateur", résume Chen dans son interview . Reste qu'il faut un accès complet au modèle pour fabriquer le signal, ce que Microsoft et Mistral ne donnent pas. Alors il suffit à l'attaquant de l'entraîner sur un modèle ouvert qu'il contrôle, puis de rejouer le même signal contre le modèle fermé et en général, ça se passe bien parce qu'ils partagent souvent les mêmes briques audio.

Voilà et ça une fois que c'est fait, il suffit de "polluer" une source, et d'attendre qu'un poisson morde à l'hameçon...

Et le menu des possibilités est plutôt copieux vous allez voir. Le modèle peut par exemple prétendre qu'il ne sait pas traiter l'audio, refuser vos demandes, sortir de fausses infos, glisser un lien piégé, changer de personnalité, ou pire, déclencher des outils tout seul. Genre envoyer un mail avec vos données, ou télécharger un fichier depuis un serveur de l'attaquant s'il en a la possibilité technique (coucou MCP). Ainsi, sur les treize modèles testés, la réussite moyenne grimpe entre 79 et 96% selon le méfait.

Mais pour fabriquer ce signal vérolé, l'attaquant doit sentir dans quelle direction "pousser" le son pour rapprocher le modèle de son but, un peu comme suivre une pente vers le bas.

Sauf que ces modèles transforment l'audio en le découpant par exemple. Et la pente peut du coup devenir un escalier, puis du plat, voire une arête cassante... c'est clairement impossible à suivre ! Mais l'équipe de Chen a réussi à reconstituer cette pente à grand coups d'échantillonnage, puis a maquillé le bruit en réverbération.

Et comme notre oreille est trop limitée pour flairer l'anomalie, ça passe tranquille... Je vous avais déjà parlé de l'injection de prompt avec une simple doc empoisonnée qui pilote une IA , mais là, ça pourrait même surgir de la bande son d'une simple vidéo Youtube...

Et pour se protéger de ça, y'a pas grand chose à faire à part faire relire le prompt final... Le plus sûr, c'est donc plutôt de ne pas brancher votre assistant vocal sur vos mails, vos fichiers ou vos paiements, et de regarder plus en détails ce qui se passe s'il refuse soudainement une tâche ou vous sort un lien après avoir écouté un audio douteux...

De leur côté, les modèles fermés d'OpenAI ou d'Anthropic sont plus durs à viser, faute d'accès à l'architecture mais comme ils s'appuient aussi sur des briques audio open source, l'équipe de Meng pense que l'attaque pourrait se faire aussi.

Méfiance donc...

Source

MiniPlasma - La faille Windows que Microsoft croyait corrigée

Par : Korben ✨
18 mai 2026 à 12:51

Si vous tournez sur un Windows 11 à jour, sachez qu'il existe une faille qui permet à un programme local spécialement conçu de grimper tranquillou jusqu'au compte SYSTEM. Pour rappel, c'est le compte tout-puissant de la machine, c'est à dire celui qui passe même au-dessus de l'administrateur ! Et cette faille elle s'appelle MiniPlasma, et elle vient d'être balancée en public sur GitHub par un chercheur planqué derrière le pseudo Nightmare-Eclipse.

Et le plus gênaaaaant dans l'histoire, c'est que Microsoft était censé avoir bouché ce trou depuis 2020, dans cette CVE-2020-17103 , après un signalement de James Forshaw, le chercheur du Project Zero de Google.

Le bug vit sa life dans cldflt.sys, le pilote Cloud Files de Windows. Ce truc c'est un composant système livré d'office avec l'OS, qui est principalement utilisé par OneDrive mais aussi par d'autres stockages cloud. Et bien sûr, il reste présent sur la machine même si vous ne touchez jamais à OneDrive.

Du coup, en passant par une API non documentée baptisée CfAbortHydration, l'exploit crée des clés de registre là où il ne devrait pas, et s'en sert pour détourner un chemin d'exécution privilégié, ce qui finit par lui ouvrir les droits SYSTEM.

Le code de démo est dispo sur le dépôt GitHub du projet , écrit en C#, et il lance directement un cmd.exe en SYSTEM quand ça fonctionne. Parce que oui, ça ne marche pas à tous les coups puisque c'est une race condition. Le taux de réussite varie donc d'une machine à l'autre.

Le PoC en action : à gauche, un compte « user » standard lance l'exploit (« Exploit succeeded ») et à droite, le shell obtenu où whoami renvoie nt authoritysystem.

Maintenant, le truc qui fait vraiment mal au cul, c'est que la fameuse faille patchée par Microsoft est donc toujours vulnérable 6 ans après sa détection. Personne ne vérifie chez krosoft ??? C'est dingue !

Selon le chercheur, c'est exactement la même faiblesse qu'à l'époque. Reste à savoir pourquoi ça leur a échappé. Le patch n'a peut-être jamais corrigé la racine du problème, ou il a sauté quelque part en cours de route, j'en sais rien... Faudra analyser le code de Windows et de ses MAJ au fil du temps pour comprendre où ça a merdé.

Du coup, votre machine peut avoir avalé tous les Patch Tuesday et rester quand même exposée à une élévation de privilèges locale dès qu'un attaquant (ou un malware) arrive à exécuter du code dessus.

J'sais pas vous, mais on a déjà vu ce film avec d'autres dossiers Windows, comme cette histoire de BitLocker contournable , ou encore ces contournements de Secure Boot signés Microsoft . Certains trous de sécu sont tout simplement increvables !

Nightmare-Eclipse n'en est d'ailleurs pas à son coup d'essai puisque le chercheur enchaîne les divulgations publiques de 0-days Windows depuis quelques semaines, du contournement BitLocker au déni de service sur Defender en passant par plusieurs élévations de privilèges, toujours avec le PoC qui va bien et zéro divulgation coordonnée.

Et y'a pas de "on prévient Microsoft et on attend gentiment 90 jours" ici. Il balance tout car il est a ras-le-bol de la lenteur de Microsoft. C'est violent, dangereux et clairement discutable côté éthique, mais ça met une grosse pression pour corriger au plus vite. Maintenant pour nous tous, ça signifie surtout qu'un PoC public et fonctionnel, ce sont des malwares qui vont vite l'intégrer.

Côté protection, il n'y a pas de correctif officiel ni la moindre déclaration de Microsoft et ucune mitigation validée par l'éditeur non plus. Puis pour un particulier, pas de moyen simple de savoir après coup si la machine a été touchée.

La bonne nouvelle (relative c'est vraie), c'est que l'attaque est purement locale, donc il faut déjà pouvoir exécuter du code sur l'ordi pour en profiter. Votre vraie défense, c'est donc votre hygiène tech habituelle, à savoir ne pas lancer le premier binaire douteux venu, se méfier des cracks et autres pièces jointes, et côté admins, une surveillance EDR des élévations de privilèges inattendues vaut mieux qu'une règle maison non testée.

Source

VS Code signe vos commits avec Copilot, même sans Copilot

Par : Korben ✨
6 mai 2026 à 12:16

Si vous avez committé du code depuis VS Code depuis mi-avril, allez tout de suite vérifier vos messages de commit car vous avez peut-être un nouveau co-auteur que vous n'avez jamais embauché.

En effet, Microsoft a discrètement basculé le réglage par défaut de l'éditeur pour ajouter Co-authored-by: Copilot <[email protected]> à des commits que VS Code considérait à tort comme contenant des contributions IA, même quand vous n'avez pas utilisé Copilot, et même quand vous avez explicitement désactivé toutes les fonctions IA.

Quelle lose, hein ? La Product Manager Courtney Webster a poussé cette fameuse pull request #310226 des enfers le 15 avril dernier sans aucune description, et le dev dmitrivMS l'a mergée tranquillou le lendemain.

Et le résultat de tout ce bordel, vous pouvez le lire dans la PR #310226 qui a explosé sur GitHub : 372 pouces baissés contre 2 levés, 30 réactions "confused", et des dizaines de commentaires furieux.

L' issue de suivi #314311 , ouverte ensuite par dmitrivMS pour faire son point public, a elle aussi reçu un torrent de réactions virulentes. Tu m'étonnes, ils font vraiment n'importe quoi...

Maintenant si vous êtes dans ce cas, vous pouvez neutraliser ça immédiatement, ajoutez dans votre settings.json :

"git.addAICoAuthor": "off"

C'est le seul réglage qui marche vraiment, parce que dans la version buguée même chat.disableAIFeatures à true n'arrêtait pas le soucis. Et pour votre historique déjà bien pollué, un git rebase -i ou un git filter-branch permettra de virer les contributeurs parasites dans vos derniers commits. Mais après bonne chance si vos commits sont déjà sur des PR mergées chez d'autres. Là c'est mort...

Ce que les devs reprochent à Microsoft, c'est pas vraiment d'avoir créé l'option (elle existait depuis VS Code 1.110 en opt-in tranquille). Non, le vrai problème c'est surtout ce qu'il y a derrière cette vilaine Pull Request... 2 fichiers touchés, le change de "default", absolument AUCUNE description, une seule review d'approbation toute nulle, et hop, c'est mergé OKLM.

Pour un changement qui touche les messages de commit de plusieurs millions de devs, ça sent quand même la décision unilatérale prise à l'arrache entre 2 portes...

Et puis surtout il y a le bug #313064 qui a fait basculer l'histoire de la simple polémique à la grosse colère communautaire.

En effet, la nouvelle valeur par défaut "all" attribuait à Copilot des complétions qui ne venaient PAS de Copilot. Un dev explique par exemple avoir tapé son code à la main, vérifié son message de commit, supprimé toute suggestion Copilot, écrit le sien à la main... et a finalement retrouvé quand même Co-authored-by: Copilot dans le git log final.

Et comme le mode "je ne veux pas d'IA" n'était pas plus respecté, l'IA s'auto-créditait quand même sur tout et n'importe quoi.

Côté communauté, le ton est monté très vite. Sur le fil GitHub, y'en a un qui écrit que, je cite, "C'est pas une régression, c'est de la fraude. On ne peut pas s'attribuer un travail qu'on n'a pas fait." et un autre dev parle de "vandalisme" pur.

Windows Central a même sorti un titre choc : "This could cost people their jobs", parce que dans les boites en fintech ou sur du code soumis à audit, faire passer du code humain pour de l'IA-assisté peut coller un fail d'audit et faire péter des contrats. Ah bah ouais, j'avoue que je n'y avais pas pensé...

Heureusement, Microsoft a fini par bouger puisque dans VS Code 1.118, le default est finalement repassé de "all" à "chatAndAgent", déjà moins agressif. Et dans la PR #313931 , dmitrivMS a remis le default à "off" pour la version 1.119, dont le déploiement public commence justement aujourd'hui.

Bien sûr, la Product Manager a fait son mea culpa public, en reconnaissant, je cite que "la manière dont c'était implémenté et déployé n'a pas atteint le niveau de correction attendu", ce qui, dans la langue corporate, veut dire "on est des branleurs, déso, bisous".

Maintenant ce qui revient souvent dans les commentaires, c'est que Claude Code et Codex CLI font la même chose par défaut quand ils committent, sauf que la différence, c'est que ces agents committent quand C'EST EUX qui ont écrit le code, donc le co-author est tout à fait légitime.

VS Code, lui, modifiait des commits écrits à la main par des humains donc c'est pas du tout le même problème. Et pour le coup, sur Codex CLI la mention reste aussi désactivable via une option alors que chez Claude Code même si c'est pareil, l'opt-out n'est pas toujours très respecté d'après les retours que j'ai pu lire.

En tout cas, ce loupé arrive dans un climat déjà tendu puisque Microsoft pousse Copilot dans Windows, dans Notepad, dans Office, et même jusque dans l'écosystème Apple via une extension Xcode , dans tous les coins, et beaucoup de devs commencent à voir chaque nouveauté MS à travers ce prisme. La théorie du "ils gonflent les KPI Copilot pour les boards et les analystes" de plus en plus crédible et comme personne n'aime se sentir transformé en stat marketing, tout le monde commence à se barrer des outils et services Microsoft.

Maintenant, si vous voulez vraiment vous protéger des prochains coups foireux de M$, je vous propose d'abord de basculer sur VSCodium ou Zed , deux éditeurs sans télémétrie ni AI imposée. Et ensuite, déménager vos repos chez Codeberg ou Forgejo en suivant la procédure de migration que je vous donne dans cet article Patreon, comme ça même si Microsoft fait n'importe quoi côté éditeur, votre code n'est plus chez eux côté forge.

À voir maintenant si Microsoft tient ses promesses sur le consentement explicite avant toute mention d'agent IA, ou si on rejouera ce film encore et encore tous les 6 mois sur une autre fonctionnalité.

Edge - Les mots de passe en clair en mémoire, by design

Par : Korben ✨
5 mai 2026 à 09:06

Si vous utilisez le gestionnaire de mots de passe intégré à Microsoft Edge, et que vous le trouvez cool, hé bien accrochez-vous les amis, car Tom Jøran Sønstebyseter Rønning, chercheur norvégien en cybersécurité, vient de publier sur GitHub un PoC qui dump TOUS vos credentials en clair directement depuis la mémoire du processus du navigateur ! Et de ce que j'ai compris, Microsoft a l'air d'assumer ça tranquillou...

Et n'allez pas croire qu'activer "l'Authentification avant remplissage automatique" dans Edge règle le souci... Ça ne change absolument RIEN au problème, parce que les credentials sont chargés en clair en RAM dès l'ouverture du navigateur. Cette option bloque uniquement l'interface, et pas la mémoire. La seule vraie parade, c'est donc de basculer carrément vers un gestionnaire de mots de passe comme Bitwarden, KeePassXC, ou Mistikee car tant qu'ils restent verrouillés, ils ne chargent rien en mémoire.

Le PoC, baptisé EdgeSavedPasswordsDumper, tient en un seul fichier C#. Tom a choisi .NET Framework 3.5 plutôt qu'une version récente, parce que AMSI, l'Antimalware Scan Interface qui inspecte en temps réel le code .NET sous Windows, a une couverture vraiment réduite sur la 3.5 par rapport aux versions modernes. Du coup, le binaire passe plus facilement sous les radars des EDR et antivirus.

Maintenant, le truc, c'est que ce sujet n'est pas nouveau. En effet, en juin 2022, Zeev Ben Porat de chez CyberArk publiait déjà un papier détaillant exactement la même méthode appliquée à Chromium en général (et dont Edge découle...). Il utilisait les APIs Windows OpenProcess et ReadProcessMemory pour lire la mémoire privée des processus du navigateur et y récupérer URLs, logins, mots de passe et même cookies de session. Et à l'époque, Microsoft et Google avaient répondu en gros pareil, à savoir que c'était hors du "threat model", donc que c'était pas la peine de corriger.

Sauf que 4 ans plus tard, Tom Rønning n'arrivait pas à reproduire le dump sur Chrome avec la même méthode. En effet, le navigateur de Google semble charger ses credentials de façon plus granulaire (lazy loading, déchiffrement au besoin) plutôt que tout exposer en RAM dès l'ouverture. Alors que Edge, lui, n'a pas évolué et charge encore TOUS les credentials en clair dès le démarrage du navigateur, qu'on en ait besoin ou pas, et surtout les garde en mémoire tant que le processus parent tourne. Et c'est cette différence-là que Tom met en lumière avec son outil.

Après concernant la dangerosité de ce problème, faut que je nuance un peu tout ça car pour viser sa propre session Edge, l'attaquant n'a pas besoin d'être admin (un malware tournant sous votre compte y arrivera). Par contre, pour aller lire la mémoire des AUTRES utilisateurs sur la même machine, là, il faut les droits administrateur.

Et c'est surtout ce scénario que Tom met en avant dans son README. Il y parle d'un terminal server où plusieurs utilisateurs seraient connectés simultanément via RDP, et sur lequel un admin compromis pourrait dumper les mots de passe de tous les autres avec leur Edge ouvert, y compris les sessions déconnectées tant que le processus parent tourne. C'est assez spécifique quand même mais pas impossible évidemment...

Microsoft, contacté par Tom avant publication, a bien sûr répondu que le comportement était "by design"... Leur doc Edge enterprise explique même noir sur blanc que les attaques physiquement locales et les malwares sont hors du modèle de menace et qu'aucun navigateur n'est armé pour résister à un attaquant déjà infiltré dans le compte utilisateur.

C'est cohérent c'est vrai... Mais ça occulte un truc qui reste très "gênant" comme disent les ados. C'est que leur implémentation expose une surface d'attaque plus large que leurs concurrents basés sur le MÊME moteur Chromium. C'est pas normal....

Et côté communauté, ça n'a pas trainé non plus, puisque Whitecat18 sur GitHub a déjà sorti un portage Rust du PoC. C'est intéressant car Rust offre encore moins de surface AMSI que .NET 3.5 et se compile comme un binaire natif sans aucune dépendance. Donc pour un attaquant, c'est un upgrade de furtivité significatif... Et pour un défenseur, c'est surtout une raison de plus de pousser vos utilisateurs vers des vrais gestionnaires de mots de passe.

Concernant la divulgation responsable , Tom Rønning a fait les choses dans les règles : signalement à Microsoft, attente de la réponse officielle, présentation publique le 29 avril 2026 à BigBiteOfTech (l'évènement Palo Alto Networks Norway), puis publication du PoC.

Voilà... Microsoft persiste, Edge reste as-is (lumière !), et la sécurité de vos mots de passe est officiellement votre problème. Donc si vous utilisez Edge, je pense que ça vaut clairement le coup de migrer vers un gestionnaire externe... vous verrez, c'est pas la mer à boire.

Source

❌
❌