Andres Freund, un développeur Postgres, s’est rendu compte dans les derniers jours que xz et liblzma ont été corrompus par l’un des mainteneurs du projet. Le problème a été découvert par chance, pour la seule raison que la performance de sshd s’était dégradée sur sa machine.
L’investigation d’Andres Freund a montré que Jia Tan, co-mainteneur de xz depuis environ un an et demi, a poussé plusieurs commits contenant une porte dérobée extrêmement bien cachée au milieu d’un certain nombre de contributions valables depuis environ deux ans et demi, après avoir gagné la confiance du mainteneur historique, Lasse Collin.
Jia Tan a ensuite fait deux versions de xz, la 5.6.0 et 5.6.1, et les a poussées vers les mainteneurs de différentes distributions, comme Fedora Rawhide, Debian Unstable, Kali Linux ou encore Suse. Les contributions de Jia Tan à divers projets sont maintenant en cours de ré-analyse, car il apparaît qu’il a contribué des changements maintenant louches à d’autres projets, comme oss-fuzz, maintenant considérés comme visant probablement à cacher cette porte dérobée.
La plupart des distributions affectées sont des versions bleeding edge, et sont revenues à une version antérieure de leurs paquets xz.
Les effets de cette porte dérobée ne sont pas complètement analysés, mais les investigations existantes montrent des détournements d’appels très suspects autour des fonctions de validation des secrets d’OpenSSH.
Cet épisode rappelle une nouvelle fois combien tout l’écosystème repose sur la bonne volonté et la bonne foi de contributeur·rice·s volontaires, surchargé·e·s de travail, et peu soutenu·e·s par l’industrie utilisant leur travail.
NdM : le sujet est frais, les analyses en cours, et de nouvelles informations apparaissent encore toutes les heures. Il convient donc de rester prudent, mesuré, et surtout factuel, dans les commentaires. Merci d’avance.
Les infos qui suivent ont été ajoutées en modération (le sujet ayant été discuté en lien et en journal précédemment) :
-
autres sites discutant du sujet :
- liste des dév Fedora (anglais)
- news.ycombinator.com (en anglais)
- Lobsters
- Linux Weekly News
- Python : CPython, PyPI, and many Python packages are not affected by the backdoor of xz (CPython, PyPI, et beaucoup de paquets Python packages ne sont pas concernés par la porte dérobée sur xz)
-
des résumés / suivis :
- boehs.org
- lcamtuf.substack.com
- explication en image (et en anglais) par Thomas Roccia sur X :
- une FAQ
-
des analyses du code injecté :
-
quelques commentaires techniques :
- Misc: pam charge à la volée ses modules (mais aucun ne semble dépendre de liblzma sur ma machine) et libsystemd aussi depuis 1 mois, comme l'a souligné Lennart Poettering sur HackerNews
- roger21 : la commande ldd n'est pas sûre sur un binaire à la fiabilité incertaine
Aller plus loin
- Le courriel publiant la faille sur Openwall.com (207 clics)
- FAQ on the xz-utils backdoor (138 clics)
- L'alerte pour Fedora (96 clics)
- L'alerte pour Debian (305 clics)
- L'alerte pour Kali (57 clics)
- Une Pull Request suspecte sur le projet oss-fuzz (180 clics)
- L'alerte pour openSUSE (42 clics)
- L'alerte pour Arch Linux (121 clics)
- Réaction du projet XZ (316 clics)
# un salarié de chez M$ 'sauve Linux'
Posté par mansuetus (site web personnel) . Évalué à 10 (+12/-0).
Si ça n'avait pas été posté le 31.03, j'aurais cru que nous étions le 01.04.
C'est fou, cette histoire. Et on n'a pas fini de chercher a comprendre.
Bravo, et merci aux personnes dévouées au libre et a la sécu.
[^] # Re: un salarié de chez M$ 'sauve Linux'
Posté par woffer 🐧 . Évalué à 1 (+0/-0).
De nouveau, il doit y avoir des chaises qui volent chez certains dirigeants historiques.
[^] # Re: un salarié de chez M$ 'sauve Linux'
Posté par Julien (site web personnel) . Évalué à 8 (+8/-0). Dernière modification le 01 avril 2024 à 20:30.
Et ce qui est un peu hallucinant, c'est qu'il a découvert ça parce qu'un refus de connexion SSH mettait moins de 500ms supplémentaires et prenait du CPU en plus. Des éléments que la plupart des personnes ne remarqueraient pas.
[^] # Re: un salarié de chez M$ 'sauve Linux'
Posté par Thomas Debesse (site web personnel) . Évalué à 10 (+12/-0). Dernière modification le 01 avril 2024 à 23:45.
Pas exactement. Il était en train de microbenchmarker autre chose que le temps de connexion de SSH, et il était dérangé par le fait que SSH occupait trop de CPU et il voulait retirer le bruit de fond qui polluait son benchmark :
Le temps de connexion qui met plus ou moins 500ms à échouer est simplement l’exemple le plus simple pour reproduire le problème.
J’ai aussi vu d’autres personne utiliser le temps d’exécution pour supposer une désactivation éventuelle de la porte-dérobée (il y aurait une variable d’environnement cachée prévue à cet effet, probablement pour que les commanditaires puissent continuer à utiliser des distributions mainstream en désactivant pour eux-même la porte dérobée): https://piaille.fr/@zeno/112185928685603910
L’idée que la porte dérobée aurait été découverte par « un héro qui prend son boulot tellement au sérieux qu’il a investigué une latence de 500ms pour se connecter » ou « un nerd autiste maniaque qui a un seul de tolérance à la patience inférieure à 500ms » (comme j’ai pu lire dans certains commentaires en divers endroits), pour le glorifier ou pour se moquer de lui, c’est typiquement du mythe construit sur du vrai enjolivé et romancé qu’on retrouvera dans le récit mythique d’une odyssée, une comédie musicale, ou un film hollywoodien « inspiré de faits réels ». Ce qui n’enlève rien à l’expertise du gars et à la reconnaissance qu’on peut avoir envers lui.
Mais cela signifie aussi que la probabilité était encore plus rare de repérer la porte dérobée, car à mon avis détecter une latence à l’usage a plus de chance d’être remarquée que s’inquiéter de quelque sauts d’usage de SSH en arrière plan que tu ne constate pas physiquement avec tes propres sens. J’ai vu des utilisateurs passer d’un état calme à avoir le sang qui bout instantanément si une appli se fige quelque millisecondes…
On retiendra aussi que la porte dérobée a été révélée involontairement par un canal auxilliaire (side channel).
ce commentaire est sous licence cc by 4 et précédentes
# Mageia est sauf
Posté par Zorro (site web personnel) . Évalué à -10 (+1/-37).
Mageia a communiqué n'être pas concerné par cette attaque.
C'est ça, aussi, une sécurité consciencieuse : bien choisir sa distribution.
[^] # Re: Mageia est sauf
Posté par Zenitram (site web personnel) . Évalué à 10 (+17/-3).
Parler de sécurité juste par chance de ne pas avoir pris une version spécifique d'une lib, faut oser sans avoir peur du ridicule… Bravo de l'avoir fait.
rappel sur les problèmes de sécurité de Mageia à une époque (je ne sais pas si ils se sont amélioré sur le sujet ou pas depuis).
[^] # Re: Mageia est sauf
Posté par Ysabeau 🧶 🧦 (site web personnel, Mastodon) . Évalué à 4 (+2/-1).
En 2017 ça a eu le temps de changer, on est en 2024 !
« Tak ne veut pas quʼon pense à lui, il veut quʼon pense », Terry Pratchett, Déraillé.
[^] # Re: Mageia est sauf
Posté par barmic 🦦 . Évalué à 7 (+5/-0). Dernière modification le 01 avril 2024 à 16:26.
C'est vrai ils ont pu mettre à jour une fois ou 2 depuis :p
C'est une blague, je ne doute pas que ça s'est amélioré. Et ça montre qu'il faut prendre soin des projets qu'on aime.
Et c'est toujours bien de ne pas trop fanfaronner en sécurité, on rarement à l'abri de faire les mêmes erreurs voir de faire pire. À minima c'est une piqûre de rappel pour tout le monde
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Mageia est sauf
Posté par Renault (site web personnel) . Évalué à 4 (+1/-0).
Surtout qu'ici avoir ou non la porte dérobée revient à inclure ou non une version spécifique d'un logiciel.
C'est donc du hasard, parfois la distribution aura la bonne version parfois pas. On ne peut pas le prédire et aucune politique de distribution n'est bonne à cet égard. Donc en effet fanfaronner que X n'a pas la faille est ridicule dans ce contexte.
Là où la distribution peut jouer c'est en compilant et en intégrant le composant avec d'autres mesures de sortes que une faille ou une porte dérobée n'ait pas d'effets. C'est là où une distribution peut faire la différence à ce sujet, mais ce n'est pas ce qui nous intéresse ici.
Et je ne crois pas que la politique de Mageia soit justement très pro-sécurité. En même temps c'est un sujet complexe et même de grosses distributions avec plus de moyens peuvent faire mieux.
[^] # Re: Mageia est sauf
Posté par Misc (site web personnel) . Évalué à 7 (+4/-0).
C'est marrant, parce que je me dit "tiens, j'ai du poster dans ce fil de commentaire", et en effet, je soulignais déjà le risque de remplacer les tarballs:
(cf https://linuxfr.org/nodes/111615/comments/1697357 )
Je note aussi que le compte qui a posté le thread n'a plus jamais posté depuis 7 ans, donc ça colle aussi avec les discussions en cours sur l'épuisement des bénévoles, et aussi sur les gens qui débarquent de nulle part.
# Discussion sur Arch
Posté par Maderios . Évalué à 2 (+0/-0).
https://gitlab.archlinux.org/archlinux/packaging/packages/xz/-/issues/2
# le détail de l'attaque par Anthony Weems
Posté par palm123 (site web personnel) . Évalué à 4 (+2/-0).
https://fxtwitter.com/amlweems/status/1774819428208689241
extrait
I've been reverse engineering the xz backdoor this weekend and have documented the payload format and written a proof-of-concept exploit for the RCE. The payloads are signed with an ED448 key, so I patched my own key into the backdoor for testing. :-)
github.com/amlweems/xzbot
ウィズコロナ
[^] # Re: le détail de l'attaque par Anthony Weems
Posté par cg . Évalué à 3 (+1/-0).
Pour celles et ceux que ça intéresse mais qui ont du mal à suivre le jargon :
la backdoor permet d'exécuter des commandes à distance sur une machine infectée. Mais ce n'est pas ouvert à tout un chacun : l'accès à ce mécanisme est réservé aux personnes qui ont possession d'un certificat SSH spécifique.
Vivement que les analyses finales soient publiées. Avec un peu de chance, les spécialistes du domaine y verront un certain style d'écriture qui permettra de recouper avec d'autres bouts de code malicieux, et donc de spéculer plus précisément sur la paternité de la chose.
[^] # Re: le détail de l'attaque par Anthony Weems
Posté par Nicolas Boulay (site web personnel) . Évalué à 3 (+1/-1).
Genre cela pourrait être la Corée du Nord ?
"La première sécurité est la liberté"
[^] # Re: le détail de l'attaque par Anthony Weems
Posté par cg . Évalué à 3 (+1/-0).
Autant que ça pourrait être la France, j'imagine.
Beaucoup de commentaires disent que c'est probablement une agence étatique, mais ça peut très bien être une mafia privée, y'a pas de raison :).
[^] # Re: le détail de l'attaque par Anthony Weems
Posté par Nicolas Boulay (site web personnel) . Évalué à 5 (+2/-0).
La seule raison c'est le cout d'avoir une personne suffisamment compétente pour travailler dessus 2 ans, sans compter la complexité globale de l'attaque.
"La première sécurité est la liberté"
[^] # Re: le détail de l'attaque par Anthony Weems
Posté par Pol' uX (site web personnel) . Évalué à 6 (+5/-1).
On peut raisonnablement penser que payer quelqu'un pendant 2 ans sans garantie de retour sur investissement est à la portée de beaucoup d'acteurs non étatiques (surtout s'ils perçoivent le CIR :-p ).
On peut aussi raisonnablement penser (en tout cas je n'ai pas lu de propos qui invalide cela) qu'il ne s'agit pas du travail d'un hacker d'élite mais de celui d'une équipe talentueuse (peut être moins à la portée de nombre d'acteurs privés).
Adhérer à l'April, ça vous tente ?
[^] # Re: le détail de l'attaque par Anthony Weems
Posté par cg . Évalué à 4 (+2/-0).
Ce qui est génial, c'est que sur ton blog, l'article de 2020 mentionne déjà :
T'es un peu un précurseur non ;) ?
[^] # Re: le détail de l'attaque par Anthony Weems
Posté par Pol' uX (site web personnel) . Évalué à 3 (+1/-0). Dernière modification le 02 avril 2024 à 19:52.
Hé hé. :) Je pourrais m'en vanter si seulement je n'avais pas vu déjà ça des dizaines de fois sur des Wordpress. :)
(Oui, ça arrive lorsqu'on héberge pour autrui et en général ça sonne la fin (que tout le monde espère temporaire) de l'hébergement concerné.)
Adhérer à l'April, ça vous tente ?
[^] # Re: le détail de l'attaque par Anthony Weems
Posté par Psychofox (Mastodon) . Évalué à 4 (+2/-1).
Ça pourrait très bien être des entreprises privées comme le NSO group ou Zerodium qui ont eux-même avec des états et des mafias privées comme clients.
# Y'a pas de loup
Posté par Luc-Skywalker . Évalué à 5 (+4/-0).
Le gars, il s'est cassé la binette pendant 2 ans pour faire une blague potache, éculée depuis au moins 20(00) ans: le vieil œuf de Pâques.
"Si tous les cons volaient, il ferait nuit" F. Dard
# Réaction de GitHub
Posté par David Demelier (site web personnel) . Évalué à 10 (+9/-0).
GitHub a fermé le compte de Lasse Collin et les enregistrements DNS (xz.tukaani.org) Comme si Lasse était 100% responsable.
Voilà pourquoi je conseille à tout le monde d'héberger ses propres projets opensource.
git is great because linus did it, mercurial is better because he didn't
[^] # Re: Réaction de GitHub
Posté par Julien (site web personnel) . Évalué à 4 (+3/-0).
En fait, la réaction de github se comprend, du contenu manifestement malveillant était hébergé par eux et ils ont donc du agir vite d'autant plus un long week-end férié dans une bonne partie du monde.
C'était difficile pour Github de savoir qui était le responsable réel vu que Lasse était toujours dans les mainteneurs et aurait pu être de mèche avec Jia Tan. Ce qui n'a pas arrangé l'histoire est que Lasse n'avait pas accès à internet quand le problème s'est posé.
Concernant le fait d'être auto-hébergé, ce n'est pas la solution miracle pour la pérénité du code source vu que s'il arrive quoi que ce soit à la personne qui héberge le projet (et / ou son infra), tout peut être définitivement perdu également.
Les forges libres / éthiques sont une autre solution envisageable. L'important étant de ne pas compter que sur un seul hébergement.
Concernant XZ, une nouvelle forge a été mise en place ce week-end :
https://git.tukaani.org/
[^] # Re: Réaction de GitHub
Posté par Benjamin Henrion (site web personnel) . Évalué à -2 (+0/-3).
"Voilà pourquoi je conseille à tout le monde d'héberger ses propres projets opensource."
La resistance à la censure, tout un programme.
L'auto-hébergement est une plaie, mais il faut être sysadmin.
A quand des programmes autonomes incensurables (ne nécessitant pas d'humain pour survivre)?
[^] # Re: Réaction de GitHub
Posté par David Demelier (site web personnel) . Évalué à 2 (+0/-0). Dernière modification le 03 avril 2024 à 11:22.
Ma configuration Mercurial/nginx n'a pas changé depuis 2009. Après bien entendu installer son propre GitLab nécessite un peu de connaissance mais on parle pas non plus de faire tourner une plateforme entière. Un cgit, hgweb, gotweb c'est aisé.
git is great because linus did it, mercurial is better because he didn't
[^] # Re: Réaction de GitHub
Posté par Julien Jorge (site web personnel) . Évalué à 2 (+0/-0).
Pas de mise à jour de sécurité ou de montée de version en 15 ans ? Ou alors les montées de version ont été rétrocompatibles ? Ça m'étonne un peu :)
[^] # Re: Réaction de GitHub
Posté par Psychofox (Mastodon) . Évalué à 5 (+2/-0). Dernière modification le 04 avril 2024 à 16:40.
En général quand tu développes un logiciel de type server, tu essaies au maximum d'avoir une compatibilité ascendante et les configurations dépréciées sont supportées pendant des décénnies avec juste des warning non bloquants au moment du démarrage donc ce n'est pas déconnant.
[^] # Re: Réaction de GitHub
Posté par barmic 🦦 . Évalué à 2 (+0/-0).
Vous voyez ce que ça fait déjà une décénie, Larmina ?
Le nombre de logiciels serveurs qui ont 20 et plus sont restreint, mais j'ai aussi eu des cas de logiciels très respectables par ailleurs casser des config en 4 jours (commit un jeudi et release final le lundi ou mardi qui suit) sur une mise à jour micro et non ce n'était pas une erreur quand ils ont était averti de ce que ça donnait avant la release, la réponse était : « c'est une config qui marche pas très bien donc autant casser ».
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Réaction de GitHub
Posté par Psychofox (Mastodon) . Évalué à 5 (+2/-0). Dernière modification le 05 avril 2024 à 12:02.
sendmail, exim, postfix, apache, nginx ont tous plus de 20 ans. On a aussi pas mal de moteurs de DB assez vieux.
Si ça reste assez fréquent les logiciels de plus de 20ans. Je me rappelle que sendmail avait eu une très grosses refonte du fichier de configuration il y a de nombreuses années mais il me semble que la nouvelle version pouvait lire les anciennes config pendant longtemps.
Si tu regardes des logiciels comme Apache HTTPD server qui suivent le Semantic Versionning, il y a de gros changements et incompatibilités entre 1.x et 2.x mais une config faite en version 2 est censé toujours fonctionner sur les actuelles 2.4.xx. Et la 2.4.0 a déjà plus de 12 ans.
[^] # Re: Réaction de GitHub
Posté par freem . Évalué à 2 (+0/-0).
C'est pas plus mal, parce qu'avoir des tonnes de trucs comme pppd serait un peu gênant :)
[^] # Re: Réaction de GitHub
Posté par David Demelier (site web personnel) . Évalué à 4 (+2/-0).
J'ai simplement dit que la configuration n'a pas changé, les mises à jour sont faites par le gestionnaire de paquets (aka
sysupgrade/pkg_add -udans mon cas).git is great because linus did it, mercurial is better because he didn't
[^] # Re: Réaction de GitHub
Posté par freem . Évalué à 2 (+0/-0). Dernière modification le 04 avril 2024 à 12:07.
Et il y a eu beaucoup de contributions externes? Parce que c'est un peu l'intérêt majeur de sourceforge, github et gitlab, pour moi.
D'ailleurs, c'est lent ton site, non? Un problème de charge, peut-être? Chez moi, cliquer sur un lien semble prendre plusieurs secondes, pourtant les pages ont l'air relativement dénuée de bloat. Je ne sais pas.
En tout cas, j'imagine bien qu'il ne doit pas y avoir système de CI sur tes projets (je t'avoue que sur mes trucs perso, je m'embête pas non plus, hein, mais certains utilisateurs de "forges publiques" raffolent de ça. La plupart, peut-être même)
[^] # Re: Réaction de GitHub
Posté par David Demelier (site web personnel) . Évalué à 3 (+1/-0).
Sur un point je suis d'accord ça facilite les contributions mais ne pas passer par GitHub ça permet aussi de s'affranchir des personnes qui ne veulent pas faire les efforts nécessaires ou recevoir des PRs qui n'ont aucun sens.
Certains projets populaires sont parfois spammés par des gens qui ne font même pas parti du projet dès qu'une PR ou un tickets GitHub est popularisé via un partage reddit/hn, etc. Donc on a des individus qui débarquent sur des projets où ils n'ont jamais été juste pour “I was here” ou coller un emoji quelconque.
Les CIs sont pratiques quand on veut fournir des projets continuellement, je pense par exemple à RetroArch qui fournit des binaires tous les jours ce qui est pratique pour les projets qui changent beaucoup, ce n'est pas mon cas. La seule CI qui pourrait me servir est de m'assurer que mes projets compilent sur toutes les plateformes avant de faire une release et ça je le fais plutôt manuellement avec plusieurs VMs locales. Je n'ai pas spécialement besoin de l'automatiser.
Mais comme je suis tout de même un gens sympa et raisonnable j'ai mis des miroirs GitHub de la plupart de mes projets.
git is great because linus did it, mercurial is better because he didn't
[^] # Re: Réaction de GitHub
Posté par Psychofox (Mastodon) . Évalué à 0 (+2/-5).
En même temps oui il était responsable de son repo et s'il a accepté un mainteneur malicieux sans vetting correcte ça reste en partie sa responsabilité.
Alors je sais il n'était pas payé pour ça, la vie est dur, bla bla bla mais je crois que comme réaction d'urgence on ne peut pas critiquer github. Lasse Collin n'a pas perdu le code source de son projet (il était sur git.tukaani.org, github était un second repo) ni le copyright de ses contributions et est toujours le propriétaire du domaine tukaani.org donc il est toujours maître de son domaine DNS et peut le rediriger où bon lui semble.
Il explique tout ici d'ailleurs:
https://tukaani.org/xz-backdoor/
[^] # Re: Réaction de GitHub
Posté par freem . Évalué à 3 (+1/-0).
Sauf que du coup, ça rend la lecture du problème et de l'historique nettement plus compliquée.
[^] # Re: Réaction de GitHub
Posté par freem . Évalué à 4 (+2/-0).
Je ne suis pas d'accord, l'auto-hébergement c'est une plaie, surtout quand il faut commencer a trouver un moyen pour que les autres puissent faire des rapports de bugs ou envoyer des contributions (non, de nos jours, les mails ne sont plus la solution préférée de la plupart, va falloir s'y faire).
Moi, mes projets de dev, c'est pour les coder, la forge, c'est un moyen pas une fin.
D'un point de vue pragmatique, je pense qu'il est plus efficace d'utiliser une forge existante avec un minimum d'éthique moins liée au pognon (il y a toujours un lien, faut bien payer l'infra, et quelqu'un doit le faire. Tant que la finance est la, ça marche, mais ça peut toujours tomber… exactement comme pour l'auto-hébergement, en fait!).
Je me permets d'en citer 2 qui sont intéressantes:
Et pour la forme, une forge certes libre mais à éviter (selon moi) parce que sérieux, j'ai essayé il y a quelques années, mais… je vous laisse juster le cas de savannah (il fut un temp ou il y avait une non-gnu aussi, je sais pas si ça existe encore).
[^] # Re: Réaction de GitHub
Posté par David Demelier (site web personnel) . Évalué à 1 (+0/-1).
Tu cites sourcehut qui est développé par une personne ayant un égo surdimensionné, en plus cette même personne préfère justement le développement/contributions par mail plutôt que par merge requests.
Pour ceux qui pensent aller sur sourcehut, je vous invite à prendre en compte que les fortes opinions de Drew peut vous risquer votre dépôt quand un jour il décidera que ce que vous y faites n'est pas éthique selon lui.
git is great because linus did it, mercurial is better because he didn't
[^] # Re: Réaction de GitHub
Posté par freem . Évalué à 2 (+0/-0).
Tu noteras que j'ai pas cité sr.ht comme l'endroit ou j'ai envie d'aller. Je l'ai surtout utilisé comme second example, pour montrer que la réponse existe en plusieurs versions.
[^] # Re: Réaction de GitHub
Posté par nud . Évalué à 4 (+2/-0).
Forgejo (fork de Gitea développé et utilisé par Codeberg) est censé à un moment permettre des interactions par ActivityPub (voir ForgeFed, je n'ai aucune idée de où ça en est), donc ça peut être intéressant comme middle ground entre l'auto-hébergement et l'hosting par un tiers vu qu'un pourrait interagir sur la forge sans avoir de compte local.
# autre chronologie
Posté par Benoît Sibaud (site web personnel) . Évalué à 5 (+2/-0). Dernière modification le 03 avril 2024 à 20:25.
Encore une autre chronologie, plus complète
https://research.swtch.com/xz-timeline
(merci Bearstech)
# Linux dans la "presse à sensation"
Posté par Ysabeau 🧶 🧦 (site web personnel, Mastodon) . Évalué à 2 (+0/-1).
Je subodore que c'est de cette faille que parle l'article de 7sur7.be parce qu'il n'est pas très précis sur le sujet. Il préfère se centrer sur Un ingénieur déjoue par hasard une attaque informatique mondiale: “Ça paraissait irréel”
« Tak ne veut pas quʼon pense à lui, il veut quʼon pense », Terry Pratchett, Déraillé.
Envoyer un commentaire
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.