{"id":16819,"date":"2026-09-04T06:00:00","date_gmt":"2026-09-04T05:00:00","guid":{"rendered":"https:\/\/philippeboulanger.com\/?p=16819"},"modified":"2026-08-22T00:11:32","modified_gmt":"2026-08-21T23:11:32","slug":"la-premiere-fois-ou-un-hacker-a-pirate-la-confiance-pas-le-code","status":"publish","type":"post","link":"https:\/\/philippeboulanger.com\/fr\/la-premiere-fois-ou-un-hacker-a-pirate-la-confiance-pas-le-code\/","title":{"rendered":"La premi\u00e8re fois o\u00f9 un hacker a pirat\u00e9 la confiance, pas le code"},"content":{"rendered":"\n

En 1984, un homme a construit un pi\u00e8ge que personne n’a jamais pu d\u00e9monter compl\u00e8tement, m\u00eame apr\u00e8s qu’il en a d\u00e9truit lui-m\u00eame le code source. Ken Thompson, cocr\u00e9ateur d’Unix, venait de recevoir le prix Turing, la plus haute distinction en informatique. Dans son discours de r\u00e9ception, il n’a pas parl\u00e9 d’Unix. Il a parl\u00e9 d’un tour de passe-passe qu’il avait construit des ann\u00e9es plus t\u00f4t, et qu’il jugeait assez important pour le r\u00e9v\u00e9ler publiquement plut\u00f4t que de le laisser dormir.<\/p>\n\n\n\n

Ce que Thompson a d\u00e9crit ce jour-l\u00e0 n’\u00e9tait pas une faille technique. C’\u00e9tait une id\u00e9e : et si, au lieu d’attaquer un programme, on attaquait la confiance qu’on lui accorde ? Cette bascule m\u00e9rite qu’on s’y arr\u00eate, parce qu’elle a inaugur\u00e9 une cat\u00e9gorie d’attaque enti\u00e8rement nouvelle, celle qui ne cible plus ce que le code dit, mais ce que le code est cens\u00e9 garantir.<\/p>\n\n\n\n

Le tour de magie de 1984<\/h3>\n\n\n\n

Thompson a modifi\u00e9 le compilateur C d’Unix, le programme qui transforme le code source lisible par un humain en ex\u00e9cutable binaire que la machine comprend. Il lui a ajout\u00e9 une r\u00e8gle simple : chaque fois que ce compilateur compilait la commande de connexion login<\/code>, il glissait discr\u00e8tement une porte d\u00e9rob\u00e9e permettant \u00e0 Thompson de se connecter avec un mot de passe ma\u00eetre, sur n’importe quelle machine Unix.<\/p>\n\n\n\n

Un audit du code source de login<\/code> n’aurait rien trouv\u00e9, puisque ce code restait parfaitement propre. La porte d\u00e9rob\u00e9e n’existait nulle part dans les fichiers que les ing\u00e9nieurs lisaient. Elle n’apparaissait qu’au moment de la compilation, inject\u00e9e par le compilateur lui-m\u00eame.<\/p>\n\n\n\n

Le pi\u00e8ge en deux \u00e9tages<\/h3>\n\n\n\n

C’est l\u00e0 que l’id\u00e9e de Thompson devient vraiment redoutable. Il a ajout\u00e9 une seconde r\u00e8gle au compilateur : chaque fois que ce compilateur compilait son propre code source pour produire une nouvelle version de lui-m\u00eame, il ins\u00e9rait automatiquement les deux r\u00e8gles malveillantes dans le nouveau binaire. La porte d\u00e9rob\u00e9e pour login<\/code>, et la capacit\u00e9 de se reproduire.<\/p>\n\n\n\n

Ensuite, Thompson a fait quelque chose de d\u00e9cisif : il a effac\u00e9 toute trace de ces deux r\u00e8gles du code source du compilateur. Le fichier source, celui que n’importe quel ing\u00e9nieur pouvait lire, auditer, comparer, ne contenait plus rien de suspect. Mais le compilateur binaire, celui d\u00e9j\u00e0 en circulation, restait infect\u00e9, et chaque nouvelle g\u00e9n\u00e9ration de compilateur qu’il produisait h\u00e9ritait du pi\u00e8ge, ind\u00e9finiment, sans laisser la moindre trace lisible dans le code.<\/p>\n\n\n\n

La conclusion de Thompson tient en une phrase qu’il a formul\u00e9e lui-m\u00eame dans son discours : on ne peut faire confiance qu’\u00e0 du code qu’on a enti\u00e8rement \u00e9crit soi-m\u00eame. Autrement dit, si vous n’avez pas \u00e9crit votre compilateur, votre syst\u00e8me d’exploitation et chaque outil qui les a construits, vous faites un acte de foi. Un acte de foi que personne, dans l’histoire de l’informatique moderne, n’a jamais pu totalement \u00e9viter.<\/p>\n\n\n\n

Pourquoi c’est une innovation, pas un bug<\/h3>\n\n\n\n

Voil\u00e0 ce qui distingue Trusting Trust de n’importe quelle faille de s\u00e9curit\u00e9 classique. Une faille se corrige : on trouve la ligne de code fautive, on la r\u00e9pare, le probl\u00e8me dispara\u00eet. Trusting Trust ne se corrige pas de cette fa\u00e7on, parce qu’il ne s’attaque pas \u00e0 une ligne de code. Il s’attaque au principe m\u00eame sur lequel repose l’audit de s\u00e9curit\u00e9, \u00e0 savoir que lire le code source suffit \u00e0 savoir ce qu’un programme fait r\u00e9ellement.<\/p>\n\n\n\n

C’est exactement le type de rupture que je documente (Mon livre, chapitre 3)<\/a> : l’innovation la plus dangereuse, et la plus difficile \u00e0 voir venir, n’est presque jamais une am\u00e9lioration technique. C’est un d\u00e9placement du probl\u00e8me lui-m\u00eame, un endroit o\u00f9 plus personne ne pensait \u00e0 regarder. Thompson n’a pas invent\u00e9 un virus plus intelligent. Il a d\u00e9plac\u00e9 l’endroit o\u00f9 l’attaque pouvait vivre, du code vers l’outil qui fabrique le code. Personne, avant lui, n’avait formul\u00e9 aussi clairement ce niveau de vuln\u00e9rabilit\u00e9.<\/p>\n\n\n\n

\t\t

\n\t\t\t\t
\n\t\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t\t\t\t\t\t\t\t\t\t\t\t\t\n\t\t\t\t\t\t\t\"Philippe\t\t\t\t\t\t\t\t<\/a>\n\t\t\t\t\t\t\t\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t
\n\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t\t\t\t\t\t

Ce livre s\u2019adresse aux PDG, aux dirigeants et aux innovateurs pr\u00eats \u00e0 tout remettre en question et \u00e0 cr\u00e9er une croissance exponentielle.<\/p><\/div><\/div>\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t

\n\t\t\t\t
\n\t\t\t\t\t\t\t\t\t
\n\t\t\t\t\t\n\t\t\t\t\t\t\n\t\t\t\t\t\t\t\t\tLe Livre<\/span>\n\t\t\t\t\t<\/span>\n\t\t\t\t\t<\/a>\n\t\t\t\t<\/div>\n\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t<\/p>\n\n\n\n

La parade qui a mis vingt ans \u00e0 arriver<\/h3>\n\n\n\n

Il a fallu attendre 2005 pour qu’une contre-mesure s\u00e9rieuse soit publi\u00e9e. L’informaticien David A. Wheeler a formalis\u00e9 une technique appel\u00e9e double compilation diversifi\u00e9e, ou DDC (Diverse Double-Compiling). Le principe repose sur un constat simple : un attaquant ne peut pas raisonnablement corrompre tous les compilateurs existants \u00e0 la fois.<\/p>\n\n\n\n

La m\u00e9thode fonctionne ainsi : on prend le code source propre du compilateur suspect, et on le compile avec un compilateur diff\u00e9rent, jug\u00e9 fiable. On obtient un premier binaire de confiance. On utilise ensuite ce binaire de confiance pour compiler une seconde fois le m\u00eame code source. Si le r\u00e9sultat de cette seconde compilation est identique, bit pour bit, au binaire suspect d’origine, alors ce binaire ne contient aucune porte d\u00e9rob\u00e9e cach\u00e9e. Si les r\u00e9sultats diff\u00e8rent, le binaire suspect dissimulait quelque chose.<\/p>\n\n\n\n

Cette approche a nourri un mouvement plus large dans l’industrie du logiciel libre, celui des \u00ab reproducible builds \u00bb, les compilations reproductibles : des \u00e9quipes ind\u00e9pendantes compilent le m\u00eame code source, dans des environnements diff\u00e9rents, et v\u00e9rifient qu’elles obtiennent exactement le m\u00eame binaire. Des projets comme Debian ou Tor s’appuient sur ce principe pour renforcer la confiance dans leurs distributions.<\/p>\n\n\n\n

Il faut n\u00e9anmoins garder les pieds sur terre : ces techniques existent, elles sont document\u00e9es, elles sont utilis\u00e9es par certains projets exigeants. Elles ne sont pas devenues la norme silencieuse de l’industrie du logiciel. La plupart des compilateurs que vous utilisez aujourd’hui n’ont jamais \u00e9t\u00e9 soumis \u00e0 une double compilation diversifi\u00e9e par qui que ce soit. La solution existe sur le papier depuis vingt ans. Son adoption r\u00e9elle reste une autre histoire.<\/p>\n\n\n\n

2024, la m\u00eame le\u00e7on avec un autre nom<\/h3>\n\n\n\n

En mars 2024, un ing\u00e9nieur de Microsoft nomm\u00e9 Andres Freund a remarqu\u00e9 quelque chose d’anormal : les connexions SSH sur sa machine Debian prenaient un peu trop de temps de calcul. En creusant, il a d\u00e9couvert qu’une biblioth\u00e8que de compression extr\u00eamement r\u00e9pandue, xz utils, pr\u00e9sente dans la quasi-totalit\u00e9 des distributions Linux, avait \u00e9t\u00e9 discr\u00e8tement compromise.<\/p>\n\n\n\n

Un contributeur du projet, actif depuis plusieurs ann\u00e9es sous le pseudonyme \u00ab Jia Tan \u00bb, avait patiemment gagn\u00e9 la confiance des mainteneurs historiques avant d’ins\u00e9rer un code malveillant, dissimul\u00e9 dans les scripts de compilation plut\u00f4t que dans le code source lui-m\u00eame. La faille, r\u00e9f\u00e9renc\u00e9e CVE-2024-3094, aurait permis \u00e0 un attaquant poss\u00e9dant une cl\u00e9 priv\u00e9e sp\u00e9cifique de prendre le contr\u00f4le \u00e0 distance des machines infect\u00e9es via SSH.<\/p>\n\n\n\n

Ce n’est techniquement pas le m\u00eame m\u00e9canisme que Trusting Trust. Thompson avait construit un binaire de compilateur auto-reproducteur. L’attaque xz utils est le fruit d’une ing\u00e9nierie sociale patiente, des ann\u00e9es \u00e0 construire une r\u00e9putation avant de la trahir. Mais la le\u00e7on de fond est identique : l’endroit o\u00f9 vous cherchez le danger, le code source lisible, n’est pas toujours l’endroit o\u00f9 le danger se cache. La confiance elle-m\u00eame est la surface d’attaque.<\/p>\n\n\n\n

La question qu’on n’a pas encore pos\u00e9e \u00e0 l’IA<\/h3>\n\n\n\n

Voici o\u00f9 je m’arr\u00eate, honn\u00eatement, parce que je n’ai pas de r\u00e9ponse toute faite, seulement une question qui me semble urgente. Des chercheurs du Georgia Institute of Technology suivent depuis 2025 ce qu’ils appellent le \u00ab Vibe Security Radar \u00bb : un d\u00e9compte des failles de s\u00e9curit\u00e9 directement caus\u00e9es par du code g\u00e9n\u00e9r\u00e9 par IA. Le nombre de failles r\u00e9pertori\u00e9es a \u00e9t\u00e9 multipli\u00e9 par pr\u00e8s de six entre janvier et mars 2026 selon leurs relev\u00e9s.<\/p>\n\n\n\n

Ce chiffre concerne des vuln\u00e9rabilit\u00e9s classiques, le genre d’erreur qu’un audit humain peut encore rep\u00e9rer. Mais la question que Thompson a pos\u00e9e en 1984 n’\u00e9tait pas \u00ab le code contient-il une erreur ? \u00bb. Elle \u00e9tait : \u00ab comment savoir si l’outil qui a produit ce code est lui-m\u00eame digne de confiance ? \u00bb<\/p>\n\n\n\n

Or les mod\u00e8les d’IA \u00e9crivent aujourd’hui du code, relisent du code, et de plus en plus, participent \u00e0 la construction d’autres outils logiciels, y compris d’autres mod\u00e8les d’IA. Personne, \u00e0 ma connaissance, n’a encore de m\u00e9thode \u00e9quivalente \u00e0 la double compilation diversifi\u00e9e pour v\u00e9rifier qu’un mod\u00e8le d’IA n’a pas appris, quelque part dans ses milliards de param\u00e8tres, un comportement cach\u00e9 qu’aucune lecture de son code d’entra\u00eenement ne permettrait de d\u00e9tecter. Je pose la question sans y r\u00e9pondre : si l’audit du code source ne suffisait d\u00e9j\u00e0 plus \u00e0 garantir la confiance en 1984, sur quoi repose exactement notre confiance envers un syst\u00e8me dont m\u00eame les concepteurs ne peuvent pas lire ligne par ligne le raisonnement interne ?<\/p>\n\n\n\n

Je n’ai pas de certitude sur ce point, et je me m\u00e9fie de quiconque pr\u00e9tend en avoir une aujourd’hui. C’est pr\u00e9cis\u00e9ment le genre de question que je pose dans mes travaux sur l’adoption de l’IA en entreprise (Mon livre, chapitre 14)<\/a> : l’IA ne provoque pas seulement une nervosit\u00e9 li\u00e9e \u00e0 l’emploi. Elle r\u00e9introduit, \u00e0 une \u00e9chelle in\u00e9dite, le probl\u00e8me exact que Thompson a formul\u00e9 il y a quarante ans, celui de faire confiance \u00e0 un syst\u00e8me qu’aucun humain ne peut enti\u00e8rement inspecter.<\/p>\n\n\n\n

L’essentiel<\/h3>\n\n\n\n

Retenez trois choses :<\/p>\n\n\n\n