Un logiciel malveillant destiné à effacer définitivement les données de postes informatiques vient de faire surface dans le secteur énergétique vénézuélien.

La bête a été baptisée "Lotus" par les chercheurs de Kaspersky qui l'ont analysé en premier, il a été mise en route en décembre 2025 depuis un ordinateur vénézuélien, et sa cible principale semble être PDVSA, la compagnie pétrolière d'État.

Côté technique, Lotus ne fait pas dans la dentelle. Deux scripts batch préparatoires, OhSyncNow.bat et notesreg.bat, désactivent toutes les défenses, coupent les comptes utilisateurs et ferment les interfaces réseau, histoire de bien tout bloquer.

Ensuite, le binaire principal passe en mode destruction avec diskpart, robocopy et fsutil pour manipuler le système de fichiers, puis descend au niveau IOCTL pour écraser directement des secteurs physiques du disque. Les points de restauration sont supprimés, le journal USN est effacé. Aucune récupération possible.

LKaspersky ne pointe personne, et aucun élément technique ne désigne un État ou un groupe criminel en particulier. Le timing est quand même troublant : fin 2025 et début 2026, le Venezuela a traversé une crise politique majeure avec la capture de l'ancien président Nicolás Maduro le 3 janvier, et les tensions toujours fortes autour des infrastructures énergétiques. Coïncidence ou coordination, on ne saura probablement pas avant longtemps.

En pratique, un wiper qui cible PDVSA, ça rappelle immédiatement les attaques contre les infrastructures critiques qu'on a vues en Ukraine avec Stryker ou contre des clusters Kubernetes avec la variante TeamPCP.

L'objectif n'est pas le chantage ni le vol, c'est la destruction pure. Les opérateurs ne cherchent pas à exfiltrer quelque chose, ils veulent rendre l'infrastructure inutilisable le plus vite possible, pour déstabiliser ou punir.

Un réseau d'alimentation électrique ou de distribution de carburant paralysé quelques jours, ça a des conséquences directes sur la vie quotidienne et sur la stabilité politique d'un régime.

Ce qui inquiète, c'est aussi la qualité du code. Lotus n'est pas un script amateur collé à la va-vite : il enchaîne plusieurs étapes de sabotage méthodique, de la désactivation des défenses à la destruction bas niveau du disque.

Pour un pays qui n'a déjà pas la réputation d'avoir la cybersécurité la plus pointue du continent, encaisser ce genre d'outil, ça fait mal. Et la probabilité que d'autres échantillons du même auteur circulent déjà ailleurs est loin d'être nulle.

Bref, un wiper bien fichu sur une compagnie pétrolière d'État dans un pays en crise, c'est rarement l'œuvre d'un adolescent dans son garage. Affaire à suivre donc.

Source : Bleeping Computer

Vous voulez comprendre ce qui se passe dans le cerveau de votre bagnole ? Hé bien pour cela avant, il fallait du matos pro et des suites logicielles à licence annuelle. Mais maintenant, y'a CANviz .

Un pip install canviz, un module USB à quelques balles branché sur le bus CAN de la voiture, et hop, vous accédez à tous les secrets de votre voiture simplement en ouvrant votre navigateur sur localhost:8080. Toutes les trames qui circulent sur le réseau interne du véhicule s'affichent en direct dans un tableau qui défile sans ramer à 2000 fps si j'en crois le README, donc ça envoie !

Ce projet signé Chanchal Dhiman tourne sur n'importe quelle config équipée de Python 3.10 ou supérieur, et côté matériel, CANviz se branche sur plein de bazars tels que les modules à firmware Candlelight (genre FYSETC UCAN autour de 8 balles ou CANable 1.0 autour de 15), les périphériques slcan via port COM, et du matériel sérieux type PEAK PCAN-USB, Kvaser, Vector ou même socketcan sur Raspberry Pi. En gros, si votre clé USB CAN est compatible avec python-can, CANviz la gère !

L'interface décode alors les fichiers DBC (le format de base de données du CAN), donc au lieu de lire des paquets hexadécimaux chelous, vous voyez directement "vitesse moteur = 1450 rpm" ou "position accélérateur = 34%". Vous pouvez aussi filtrer par ID ou par nom de signal, et le filtre se garde dans l'URL. Comme ça, vous pouvez partager une vue à un pote en copiant simplement le lien.

Le truc vraiment pratique, c'est surtout la partie enregistrement. Vous capturez une session en .asc ou .csv, et vous la rejouez plus tard à vitesse variable (de 0.5x pour décortiquer lentement, jusqu'à 10x pour survoler), ou vous forgez vos propres trames depuis l'interface pour tester la réaction d'un module donné. Une API REST et du WebSocket ouvrent aussi la porte aux bricolages en Python, avec une doc interactive accessible sur /docs.

Autre truc malin, vu que c'est un serveur web derrière : vous pouvez déployer CANviz sur un Raspberry Pi planqué dans la bagnole et le consulter à distance en SSH. Par contre, pas de WebUSB ici. L'auteur a explicitement fait le choix de passer par python-can côté serveur pour des raisons de sécurité. L'accès USB reste donc dans le sandbox Python, et le browser ne touche rien. J'avoue, je préfère.

Le projet est sous licence MIT, et est encore jeune, mais l'approche est éprouvée. Pour ceux qui cherchent des alternatives desktop, y'a bien sûr CANgaroo côté Qt, ou SavvyCAN qui tourne aussi en natif. Et si vous voulez bidouiller votre voiture comme Charlie Miller l'a fait avec la Jeep , y'a toujours le Panda de Comma sorti en 2017 avec son soft Cabana.

Bref, pour quelques euros de module USB et un pip install des familles, vous pouvez transformer votre laptop en analyseur CAN niveau pro et ça c'est plutôt classe !

Source

Apple a publié hier une mise à jour iOS qui ferme une faille utilisée par les forces de l'ordre américaines pour récupérer des messages supprimés dans des applications comme Signal.

La faille concernait la base de données des notifications : quand vous supprimiez un message dans l'appli, la version cachée dans le cache des notifications pouvait rester accessible jusqu'à un mois.

Concrètement, un message Signal effacé côté appli restait lisible par quiconque avait la main sur le téléphone et savait fouiller au bon endroit.

Le FBI, selon les documents repérés par 404 Media début avril, a utilisé cette faiblesse sur plusieurs affaires pour remonter des conversations pourtant explicitement effacées par les utilisateurs, y compris celles utilisant la fonction messages éphémères.

Apple a reconnu le problème, mais si ça a été fait avec les pincettes habituelle, avec une phrase du genre... "les notifications marquées pour suppression pouvaient être conservées sur l'appareil de manière inattendue", ce qui ne veut pas dire grand chose, ou au contraire, tout dire...

Dit plus simplement, il y avait un écart entre ce que l'utilisateur voyait disparaître et ce qui restait réellement sur le disque. Le patch a été rétroporté sur les anciennes versions d'iOS 18, ce qui suggère que la faille existait depuis un bon moment et a probablement été exploitée dans des affaires que l'on ne connaîtra jamais.

Meredith Whittaker, présidente de Signal a rappelé publiquement que les notifications pour des messages effacés ne devraient jamais rester dans la base de notifications d'un OS. C'est une évidence technique. Sauf que dans la pratique, la chaîne cache des notifications plus indexation iOS laisse des traces que les outils forensiques comme Cellebrite ou GrayKey savent exploiter depuis des années.

Le problème dépasse Signal. Toute application qui envoie une notification contenant le texte d'un message entier sur iOS pouvait voir ses contenus persistés dans le cache, même après un effacement explicite. Du coup, pour les journalistes, les avocats, les activistes ou simplement les gens qui tiennent à leur vie privée, mettre à jour le plus vite possible n'est pas une option mais une priorité.

Bref, quand on parle de messagerie chiffrée, la vraie surface d'attaque n'est plus le protocole mais tout ce que l'OS fait autour dans votre dos.

Source : The Hacker News

Depuis la version 2.91.0 du CLI GitHub publiée mardi, chaque commande que vous tapez dans gh envoie des données de télémétrie vers GitHub par défaut. L'activation est silencieuse, sans message au premier lancement, sans consentement explicite, et il faut fouiller dans la doc pour tomber sur la page dédiée au sujet.

GitHub décrit la collecte comme pseudonyme côté client. Concrètement, le payload embarque le nom de la commande lancée, un identifiant d'invocation, un identifiant d'appareil, l'OS, l'architecture, l'agent et quelques drapeaux.

L'entreprise précise que le contenu exact peut varier d'un appel à l'autre. La justification officielle : les équipes produit ont besoin de voir comment le CLI est utilisé, avec la montée en puissance des agents IA qui le pilotent de plus en plus souvent en arrière-plan.

Côté sortie, il y a trois moyens de couper la télémétrie. Vous pouvez définir la variable d'environnement GH_TELEMETRY à false, ou DO_NOT_TRACK à true, ou lancer gh config set telemetry disabled. Simple en apparence.

Sauf que rien de tout ça n'est signalé à l'installation, et qu'un utilisateur qui n'est pas tombé sur le billet de Brandon Vigliarolo dans The Register ne saura probablement pas que c'est activé sur sa machine.

Le terme pseudonyme mérite aussi qu'on le regarde de près. Pseudonyme ne veut pas dire anonyme : il y a un identifiant d'appareil stable, il y a un identifiant d'invocation, et GitHub connaît déjà votre compte si vous êtes authentifié avec gh auth login.

Du coup, le recoupement entre votre activité CLI et votre identité GitHub n'a rien de théorique, même si GitHub ne promet pas de le faire.

En pratique, la télémétrie des outils de dev n'est pas une nouveauté. VS Code le fait depuis des années, npm aussi, et la plupart des éditeurs jouent le même jeu. Ce qui coince ici, c'est le choix de l'opt-out plutôt que de l'opt-in, et l'absence d'annonce claire sur le changelog principal.

Les utilisateurs reprochent surtout à GitHub d'avoir glissé l'info dans une page de doc au lieu d'un billet de blog dédié. Pour un outil qu'utilisent des gens très à cheval sur leur vie privée, c'est un drôle de calcul.

Bref, un outil CLI qui s'active en mode collecte par défaut sans prévenir, ça pique. Heureusement une variable d'environnement suffit à couper. Mais il faut savoir qu'elle existe.

Source : The Register

360 Digital Security, la filiale cybersécurité du géant chinois Qihoo 360, revendique environ mille vulnérabilités inédites déterrées par un agent IA maison baptisé Vulnerability Discovery Agent. 

L'annonce, faite le 22 avril, cite nommément Microsoft Office et le framework open source OpenClaw parmi les logiciels touchés. Le chiffre est donné sur un seul cycle de campagne.

Mille failles non documentées en un seul cycle de recherche, ça fait un peu tourner la tête. Ce type d'agent fonctionne en boucle pour scanner massivement les bases de code, trier ce qui est potentiellement exploitable, et valider les candidats avant publication interne.

Plus tôt dans l'année, 360 avait déjà présenté un autre outil dédié à la construction automatisée de chaînes d'exploitation. L'un déterre les failles, l'autre fabrique le code qui les utilise.

Mis bout à bout, ça donne une ligne de production offensive entièrement pilotée par IA, que l'équipe 360 décrit comme une réponse directe au projet Mythos d'Anthropic, qui fait le même pari côté occidental mais en mode défense.

Le vrai souci, c'est le devenir de ces 1 000 failles. Si toutes ont été remontées aux éditeurs concernés, tant mieux. 360 affirme d'ailleurs avoir utilisé les canaux de divulgation responsables, mais sans publier de calendrier de patch.

Sauf que l'entreprise est connue pour ses liens étroits avec le ministère chinois de la Sécurité d'État, et plusieurs de ses chercheurs ont déjà été soupçonnés par le passé de garder pour l'État ce qu'ils trouvaient. Du coup, l'annonce met les équipes de sécurité occidentales quelque peu en alerte.

Microsoft, qui patche Office tous les mois pour des failles trouvées à la main, va probablement devoir accélérer le rythme si ce genre de scan industriel se généralise. En pratique, la chasse aux vulnérabilités est en train de changer d'échelle.

On passe de quelques failles trouvées par un chercheur humain sur plusieurs semaines à un agent qui en déniche des centaines en quelques jours. Et la logique économique derrière est folle : un seul opérateur bien outillé peut désormais couvrir ce qu'il fallait avant à une équipe complète.

Bref, le mur est tombé côté IA offensive. Et les éditeurs qui patchent à la main ont un vrai problème de cadence face à un scan automatisé à cette échelle.

Source : Bloomberg

pgAdmin, l'outil "officiel" pour administrer vos bases PostgreSQL, c'est le type d'interface qu'on n'a pas vraiment envie d'ouvrir un lundi matin ! C'est lent, c'est cheum de ouf en mode figé dans les années 2000 et ça rame sérieusement dès qu'on tente un export un peu costaud. Alors oui je sais, DBeaver, c'est plus joli, mais faut se coltiner Java et un workspace qui traîne au démarrage.

Du coup quand bbDump est passé sur mon radar, j'ai eu envie de creuser un peu. C'est un gestionnaire PostgreSQL moderne, en Electron + Vue + TypeScript, signé par Poups, un dev indé français. L'outil reprend tout ce que vous faites habituellement en CLI (pg_dump, pg_restore, coups d'œil aux tables, schéma de la DB) et met ça dans une interface vraiment propre.

Le dashboard bbDump, tout de suite plus respirable que pgAdmin

Côté fonctionnalités classiques, vous avez ce qu'on attend d'un client PostgreSQL correct. Gestion multi-bases organisée par projet, backups avec liste, restauration, filtre par base, tailles et dates. De leur côté, les tâches planifiées via expressions cron sont configurables par base, et il y a même une visionneuse de logs en temps réel qui trace chaque opération pg_dump.

Ajoutez à ça un navigateur de tables avec édition inline (avec support complet des types), un constructeur de requêtes SQL visuel en plus de l'éditeur brut, l'export CSV, et un diagramme entité-relation interactif via Vue Flow pour visualiser les tables et les clés étrangères. Grâce à bbDump, plus besoin d'aller chercher un outil externe pour comprendre une base héritée d'un projet qui traîne !!

Le schema visualizer en mode ERD interactif, pratique pour décortiquer une base héritée

Mais le vrai twist, c'est l'intégration du MCP (Model Context Protocol) puisque bbDump expose 31 outils MCP aux agents IA, ce qui veut dire que votre Claude d'amour ou votre LLM peut interroger la DB, regarder un schéma, tester une requête. Et comme les mutations passent par un système de confirmation, pas de DROP TABLE à l'insu de votre plein gré !

Je vous avais déjà parlé de cette approche avec Ghidra MCP côté reverse engineering et BrowserWing côté automatisation navigateur. bbDump rejoint donc la famille côté backend de données.

Autre détail sympa, le dev a pensé à la sécurité puisque les backups sont chiffrés en AES-256-GCM, donc si vous synchronisez vos dumps sur un cloud random, pas de panique sur les données sensibles. Sur macOS, y'a même une mini-app menu bar pour accéder aux bases et aux connexions proxy sans ouvrir l'app complète.

Côté installation, c'est facile :

curl -fsSL https://poups.dev/bbdump.sh | bash

Bon, les amis, si vous utilisez Tor Browser pour faire du sérieux, faut que vous sachiez un truc. Le bouton "New Identity", censé vous donner une nouvelle identité vierge à chaque clic... bah il laissait filer, jusqu'à il y a peu de temps, un identifiant stable tant que Firefox tournait.

Deux chercheurs de Fingerprint ont en effet trouvé comment une fonction toute bête du navigateur se transformait en empreinte unique de votre browser, partagée entre tous les sites que vous visitiez.

Il faut donc dès à présent faire la mise à jour vers Firefox 150 ou l'ESR 140.10.0 (la version long-terme utilisée par Tor Browser), ainsi que la dernière version de Tor Browser qui récupère le patch. Si vous voulez en savoir plus, la CVE c'est CVE-2026-6770 , classé comme sévérité modérée par Mozilla.

Le truc marche en vase clos mais traverse les murs.

Mais avant, IndexedDB c'est quoi ?

En gros c'est une mini-base de données que les sites web peuvent créer dans votre navigateur, pour stocker des trucs en local (du cache, des données offline, l'état d'une app web). Chaque site peut y ranger plusieurs bases nommées, et une petite fonction JavaScript indexedDB.databases() permet au site de demander la liste de ses bases.

Rien de foufou sur le papier. Sauf que dans Firefox en navigation privée, le navigateur renomme en coulisse chaque base avec un identifiant aléatoire (UUID), et range tout ça dans une seule grosse table interne. Et le gros problème, c'est que cette table est partagée entre tous les sites ouverts, et pas cloisonnée site par site.

Et là, ça devient croustillant puisque quand un site redemande la liste de ses bases, Firefox la renvoie sans la trier, dans un ordre qui dépend de la structure interne de cette table partagée. Du coup, deux sites totalement différents qui créent chacun seize bases dans le même ordre récupèrent exactement la même suite en retour. Pas l'ordre de création donc mais une permutation bizarre, genre g,c,p,a,l,f,n,d,j,b,o,h,e,m,i,k.

Je vous passe les détails mais ça fait dans les 17 000 milliards de combinaisons possibles. Donc largement de quoi distinguer votre navigateur parmi des millions, comme une empreinte digitale qui colle au doigt !

Et ce qui pique vraiment c'est que cet identifiant survit à la fermeture de toutes vos fenêtres privées. Tant que le process Firefox tourne en arrière-plan, l'ID reste. Un site peut donc vous reconnaître après que vous ayez fermé vos onglets privés, rouvert une session pensée comme neuve, et revisité le site. Pour le user, c'est une session fraîche alors que pour le serveur c'est clairement le même navigateur qu'il y a dix minutes.

Côté Tor Browser c'est pire puisque le bouton "New Identity" a pour mission explicite de couper tout lien avec ce que vous faisiez avant. Il ferme les onglets, efface l'historique, vide les cookies, tire de nouveaux circuits Tor. La promesse officielle, c'est "empêcher votre activité future d'être liée à ce qui précède".

Sauf que cette fameuse table interne, elle, ne bouge pas. Le New Identity reset donc tout sauf ce qu'il ignore. C'est comme changer de fringues dans le même ascenseur... en gardant le même parfum. Techniquement vous êtes différent, mais reconnaissable en deux secondes. Bref, c'est assez grave car un site capable d'exploiter la faille peut lier votre session avant-New-Identity à votre session après-New-Identity.

Tant qu'on n'a pas redémarré Firefox complètement, l'ID persiste.

Les chercheurs disent avoir fait une divulgation responsable, directement à Mozilla et au Tor Project avant publication donc c'est nickel, et les deux équipes ont poussé les patches avant de communiquer sur quoi que ce soit. Donc les utilisateurs à jour sont tout simplement protégés contre cette faille précise.

Après si vous êtes du genre parano, pensez à redémarrer complètement votre Tor Browser entre deux sessions vraiment sensibles. Ça coupe le process Firefox, ça vide cette fameuse table, et ça évite ce genre de surprise pour d'autres leaks similaires qu'on n'aurait pas encore trouvés.

A bon entendeur, salut !!

Source

Il y a quelques jours, lors de la demo party Revision 2026 , dans une salle plongée dans le noir à Sarrebruck, un public de sceners regarde défiler les crédits d'une demo victorieuse. Au milieu des pseudos des graphistes, un nom : Sector9.

Le même mec qui, quarante ans plus tôt, faisait partie des trois gamins norvégiens qui ont fondé Razor 1911.

Le logo historique de Razor 1911, signé JeD / ACiD (via Wikimedia Commons )

La demo s'appelle simplement "Razor 1911", elle dure dix minutes, et sans surprise, elle finit donc par gagner la compo PC et le prix du public. Et ce qu'elle raconte, plan par plan, c'est l'histoire d'un groupe que le Department of Justice américain a qualifié officiellement de "plus ancien groupe de cracking encore actif sur Internet".

Razor 1911 existe depuis que vous écoutez de la musique 8 bit sur cassette audio. Le groupe a traversé l'époque du Commodore 64, de l'Amiga, l'ère du PC, le passage au CD-ROM, au DVD, puis aux ISO torrents, sans oublier la répression fédérale et l'arrivée des protections Denuvo. Et au moment où j'écris ces lignes, leurs cracktros font partie du patrimoine culturel de tous ceux qui un jour ont téléchargé un jeu sur eMule.

Et voilà que, 40 ans plus tard, cette bande de joyeux lurons gagne un prix demoscene où elle se raconte elle-même...

Mais pour comprendre vraiment ce que ça veut dire, il faut que je vous emmène à Oslo lors de cette nuit d'octobre 1985.

Octobre 1985 : Oslo, la naissance de Razor 2992

Imaginez une chambre d'ado dans la banlieue d'Oslo. C'est l'automne norvégien, il fait nuit à 17h, et la seule lumière dans la pièce vient d'un écran CRT qui tire sur le vert. Un Commodore 64 chauffe doucement sur un bureau encombré et dans le lecteur de disquettes, une 5"1/4 tourne avec ce bruit caractéristique de crécelle électrique.

Les ordinateurs domestiques des années 80 qui ont vu naître la scene, Amiga 500 et Atari 520 ST (photo Sam Gamdschie, CC BY 3.0)

Doctor No, Insane TTM et Sector9, trois gamins, viennent de fonder un groupe de cracking. Leur premier nom, très éphémère, c'est Trøndelag Cracking Service, ou TCS. Sauf qu'un groupe anglais utilise déjà les mêmes initiales et ça crée la confusion. Un autre groupe norvégien de la scene, Hellmates, leur suggère alors un nouveau nom : Razor. On est encore à l'automne 1985 et ça s'appelle d'abord Razor 2992, puis en novembre, nouveau changement de nom pour adopter définitivement Razor 1911.

La raison de ce 1911 est géométrique. En hexadécimal, 1911 décimal équivaut à 0x777. Trois fois 7, un par fondateur, soit un joli clin d'œil numérologique qu'ils vont se traîner durant quarante ans. C'est aussi, selon certaines sources d'époque, une pique à tous les groupes de cracking qui abusaient du 666 pour leur côté satanique un peu too much. Razor 1911 choisit délibérément le chiffre opposé. Un détail qui en dit long sur l'esprit de la scene naissante à l'époque.

Leur premier crack, c'est Kik Start, un jeu de motocross sorti par Mastertronic en 1985 sur Commodore 64. Un classique des obstacles parcours sur deux roues que tout le monde avait chez soi. Et c'est précisément là dessus, ce petit jeu vendu pas cher en Angleterre, que nos trois gamins norvégiens vont poser leur première signature sur la scene européenne.

Kik Start (Mastertronic, 1985), le tout premier jeu cracké par Razor 1911 sur Commodore 64 (capture via Lemon64 )

La scene C64 européenne tourne à plein régime à ce moment-là. Les BBS échangent des disquettes par courrier postal, les cracktros fleurissent avec leur ASCII art et leur musique chiptune, les groupes s'affrontent pour la "first release" des jeux populaires. Razor 1911 grimpe alors très vite dans la hiérarchie, mais reste un groupe parmi d'autres. Les vraies légendes de l'époque, c'est FairLight en Suède, The Humble Guys aux US, et TRISTAR & Red Sector Inc côté Allemagne.

Ce qui distingue Razor 1911 à ce moment-là ? Pas grand-chose, en fait.

Enfin, si... une sacrée envie de durer ! Car quand la plupart des groupes de l'époque se dissolvent après deux ans, parce qu'un membre part à l'armée ou qu'un autre se fait piquer son Commodore par ses parents, eux continuent. Et continuent. Et continuent...

Et ils ne le savent pas encore, mais dans trois ans, ils vont devoir tout recommencer sur une nouvelle plateforme.

1987-1993 : du C64 au PC, la guerre des plateformes

Nous sommes maintenant en 1988. Un ado quelque part en Europe lance un jeu piraté sur son Amiga 500 flambant neuf. Avant que le jeu démarre, une intro 3D tourne en 50 fps pendant trois minutes. Des sphères qui tournent, un scrolltext qui envoie des greetings aux autres groupes de la scene, et une musique de tracker composée de huit canaux qu'il va siffler dans sa tête pendant des semaines. Et le logo à la fin ? Razor 1911 !

L'Amiga 500, la machine reine de la scene européenne à la fin des années 80 (photo Bill Bertram, CC BY-SA 2.5)

Entre 1987 et 1988, le C64 commence à fatiguer et Razor 1911 migre alors sur Amiga, la plateforme qui gagne toute la scene européenne. Ils font des demos, ils crackent des jeux, ils sortent des cracktros avec des effets graphiques qu'aucune autre plateforme ne permet. C'est l'âge d'or Amiga. On lance le jeu, on kiffe l'intro, et ensuite on joue.

Razor 1911 ne se contente d'ailleurs pas de cracker des jeux sur Amiga. Le groupe sort aussi des demos pures, des productions artistiques qui font la compét' avec les meilleurs sur la scene démo. En 1991, ils lâchent coup sur coup Yo! avec ses graphismes vectoriels fluides et ses transitions travaillées, puis Voyage, considérée comme leur chef d'œuvre Amiga avec un texture mapping 3D qui fait halluciner tout le monde à l'époque sur un simple Amiga 500. Leur musique trackée 4 canaux est même citée comme parmi les meilleures jamais produites sur la machine.

Voyage par Razor 1911 (1991), un chef d'œuvre avec texture mapping 3D sur Amiga 500 (capture via pouet.net )

Puis au début des années 90, nouveau virage. Le PC IBM prend la main, bon gré mal gré, et Razor 1911 suit le mouvement. Là, c'est une autre scene. Les rivaux changent, et The Humble Guys (THG) débarque en 1989 avec une idée qui transforme tout. Candyman et Fabulous Furlough, les fondateurs de THG, inventent le fichier NFO pour documenter leurs releases, et surtout ils établissent des relations avec les distributeurs pour obtenir les jeux avant leur sortie commerciale. Imaginez un jeu qui apparaît sur les BBS warez AVANT même d'arriver chez Babbage's. THG vient de redéfinir les règles du game.

Razor 1911 doit alors s'adapter, et vite. Ils perfectionnent leur méthode de cracking, recrutent des codeurs, signent leurs cracks avec des intros de plus en plus léchées. À ce stade, une cracktro Razor 1911 c'est un petit morceau d'art. Graphismes pixelisés travaillés pendant des nuits entières, musique, textes ASCII qui défilent, et timings précis pour impressionner un maximum de sceners avant que le jeu démarre. Comme ça, les gars gardent la cracktro pour la montrer aux potes et sans qu'ils ne le sachent, commencent à transmettre une nouvelle culture.

Sauf que les années 90 avancent, et un nouveau support va bientôt tout faire basculer.

1995-2001 : The Punisher et l'ère ISO

En 1995, quelque part en Amérique du Nord, un mec dont personne ne connaît le vrai nom se fait appeler The Punisher. Il passe ses nuits devant une tour beige de PC, ventilateur qui souffle fort, écran 14 pouces, et un clavier mécanique qu'on entendait depuis le salon. Devant lui, un graveur de CD, nouveauté de l'époque, qui met trois heures à "brûler" une rondelle de 600 Mo. Et c'est lui qui va sauver Razor 1911.

Parce qu'en 1995, tout bascule. Les disquettes disparaissent. Les jeux sortent sur CD-ROM, et 600 Mo, ça passe mal sur un modem 14.4k. Razor 1911 pourrait alors disparaître à ce moment-là, comme pas mal de groupes de l'époque qui n'arrivent pas à faire la transition.

Mais heureusement pour eux, The Punisher prend les choses en main et pilote le passage au CD-ripping, puis aux ISO quand ce format devient la norme. Les ISO, pour les plus jeunes, c'est une image binaire complète d'un CD ou d'un DVD, fidèle au bit près. Techniquement plus lourd que les cracks disquette, mais aussi plus propre. Razor 1911 se retrouve alors en tête du peloton et leurs releases circulent sur les topsites (les serveurs FTP ultra-privés de la scene, accessibles sur invitation uniquement), puis se diffusent sur les BBS, et ensuite sur les réseaux peer-to-peer naissants.

À la fin des années 90, le groupe devient l'une des références majeures de la scene, officiellement considéré comme l'un des plus prolifiques au monde. Ils sortent des ISO de jeux AAA quelques heures après la sortie commerciale, parfois même avant. Le palmarès est impressionnant : Quake, Warcraft II, Warcraft III, Red Alert, Terminal Velocity... Tous les hits du moment, tous disponibles sur les topsites Razor avant que les boîtes n'arrivent dans les rayons des Babbage's ou des CompUSA. Le Department of Justice citera explicitement ces titres dans son acte d'accusation, pour donner la mesure du phénomène.

La scene de l'époque pointe un autre leader que The Punisher : un certain The Renegade Chemist, souvent mentionné dans les fichiers NFO des releases. Quand l'opération Buccaneer va tomber, le FBI désignera Shane Pitman ("Pitbull") comme leader officiel, mais dans la scene, beaucoup disent que le vrai pilote au moment du raid, c'était The Renegade Chemist. Deux versions différentes de la même histoire, selon qu'on lise un rapport fédéral ou un NFO d'époque.

Et c'est là que ça devient dangereux.

Parce que quand vous êtes trop visibles, très rapides et très bons, il y a un moment où le FBI le remarque. Et en 2001, les fédéraux américains préparent quelque chose d'inédit dans l'histoire de la poursuite des groupes warez.

À Washington, dans un bureau de l'US Customs Service, un procureur imprime une liste. Dessus, des pseudos. Et surtout des adresses.

11 décembre 2001 : Operation Buccaneer

Conover, Caroline du Nord, ce matin-là. Shane Pitman, 31 ans, est au boulot quand son téléphone sonne. Au bout du fil, un agent du FBI et ce qu'il lui dit est glaçant : ils sont devant chez lui avec un mandat, alors il a intérêt à rentrer immédiatement ouvrir la porte, sinon ils rentrent eux-mêmes à coups de bélier.

Pitman quitte son bureau, monte dans sa voiture, et roule jusqu'à chez lui. Arrivé sur place, il trouve sept à huit véhicules du FBI et des douanes garés devant sa maison. À peine sorti de sa voiture, plusieurs agents en équipement d'assaut, gilets pare-balles et écussons "FBI" dans le dos, l'entourent, le plaquent sur le capot et le fouillent. Des années plus tard, dans une interview qu'il donnera sur un forum public, il racontera ce moment en expliquant que, je cite : "On aurait dit que j'étais Saddam Hussein ou quelque chose comme ça". Pour un mec qui distribuait des copies crackées de Warcraft, le dispositif était effectivement un peu surdimensionné.

Au même moment, à Richmond en Californie, Sean Michael Breen, 38 ans, se fait embarquer dans les mêmes conditions. Et à la même heure, dans cinq autres pays, Canada, Royaume-Uni, Australie, Finlande, Norvège, Suède, soixante autres personnes se font alpaguer simultanément.

C'est l'opération Buccaneer. 62 suspects visés, 70 mandats de perquisition, 150 ordinateurs saisis en une matinée et des pistes suivies dans 20 autres pays. C'est la plus grosse offensive coordonnée jamais menée contre la scene warez de l'histoire.

Reconstitution de l'opération Buccaneer - Image IA

Et les groupes visés ne sont pas que Razor 1911. Il y a aussi DrinkOrDie (DoD), RiSC, RequestToSend (RTS), ShadowRealm (SRM), WeLoveWarez (WLW), POPZ. Soit toute la tête de gondole de la scene cracker Internet de l'époque. Le FBI a passé 14 mois en investigation undercover, infiltré les serveurs, recoupé les pseudos, remonté les identités. Une opération patiente, méticuleuse, invisible. Certains membres sont alpagués à leur domicile, d'autres à leur travail, d'autres à la fac pendant qu'ils sont en cours.

Parmi les prises les plus symboliques, il y a aussi Christopher Tresco, 24 ans, connu sous le pseudo "BigRar". Pas un membre de Razor 1911 celui-là, mais de DrinkOrDie. Et accessoirement administrateur système du département d'Économie du MIT. Un boulot idéal pour héberger des topsites warez sur les serveurs d'une des plus prestigieuses universités américaines, ce qu'il faisait tranquillement jusqu'à ce matin du 11 décembre. Il prendra 33 mois de prison fédérale.

Le 6 juin 2003, Shane Pitman est condamné à 18 mois de prison fédérale pour conspiration de violation du copyright par le juge James Cacheris à Alexandria, Virginie. Le 10 février 2004, dans une cour d'Oakland, Sean Michael Breen prend 50 mois devant la juge Saundra Armstrong. C'est la peine la plus lourde de toute l'opération Buccaneer. Le chiffre qui sort lors du procès est vertigineux : Breen aurait distribué pour près d'un demi-million de dollars de jeux crackés sur une décennie. En plus de la prison, il doit donc verser 690 236,91 dollars de restitution au seul Cisco Systems. Au total, 22 personnes seront condamnées pour felony copyright infringement dans le cadre de Buccaneer.

Sur le papier, le groupe est décapité. Les leaders sont en taule ou en attente de jugement. Les membres restants se planquent, changent de pseudo, se disséminent. La communauté pense alors sincèrement que Razor 1911 est mort, tout comme DrinkOrDie qui ne se relèvera jamais.

Sauf que non.

22 juin 2006 : le retour, et la demoscene

Le 22 juin 2006, 5 ans et demi après Buccaneer, sur les topsites privés de la scene, une release apparaît silencieusement. Un vieux logo familier dans le fichier NFO, sans annonce triomphante. Juste un fichier qui commence à circuler. Les sceners qui le voient passer s'arrêtent une seconde. Puis sourient.

Razor 1911 est de retour.

Le groupe reprend le rythme, s'adapte aux nouvelles protections, signe ses cracks avec des cracktros modernisées. Au milieu des années 2010, ils sont de nouveau parmi les plus prolifiques du monde à cracker les nouveautés. Comme si Buccaneer n'avait jamais existé.

Puis arrive Denuvo, LA protection anti-copie hardware-assisted qui fait trembler toute la scene pendant des années. Razor 1911 y laisse des plumes, comme tout le monde. Les méthodes évoluent. Certains membres s'orientent alors vers la demoscene pure, tandis que d'autres continuent à cracker. Au bout du compte, les hyperviseurs finissent par contourner Denuvo en quelques heures . Le groupe mute, mais reste vivant.

Certaines sources affirment même que Razor 1911 se serait dissous vers 2012, ce qui est factuellement contredit par leurs releases récentes, notamment une cracktro pour Red Dead Redemption 2 sortie en mai 2024 et la demo de Revision 2026 dont on va parler juste après.

Entre temps, une autre histoire complètement dingue va éclater en 2023. Un joueur de GTA nommé Vadim M. remarque un truc bizarre en fouillant les fichiers des jeux Rockstar vendus sur Steam. Plusieurs titres, notamment Manhunt, Max Payne 2 et Midnight Club II, contiennent dans leurs exécutables des morceaux de code qui correspondent exactement aux cracks Razor 1911 de 2003. Rockstar Games, filiale de Take-Two, aurait tout simplement récupéré les versions crackées par Razor 1911 pour contourner ses propres DRM obsolètes et les revendre sur Steam.

Analyse du binaire de Midnight Club de Rockstar ( source )

Le comble, c'est que Rockstar a trifouillé le crack en question, ce qui a introduit des bugs sur Windows Vista et au-delà. Le message que ça donne c'est que même les studios qui chassent les reverse engineers en justice sont obligés, à un moment, d'utiliser leur travail pour faire tourner leurs propres jeux.

Et voilà... Tout ceci nous amène jusqu'à il y a quelques jours, quand lors de la Revision 2026 (la plus grosse demoparty mondiale, qui se tient tous les ans à Sarrebruck), Razor 1911 sort une demo PC de dix minutes titrée simplement "Razor 1911". Un voyage audiovisuel à travers les différentes époques du groupe. Windows 95, SoftICE, pixel art C64, effets Amiga et j'en passe... Le tout scripté avec des musiques signées brghtwhtlghtnng, zabutom et Ziphoid. Le concept est porté par Flopine, Anat, dubmood et goto80 et le code est signé rez, replay et blkpanther. C'est incroyable !

Et surtout dans les credits graphiques, un nom, celui de Sector9. Le même Sector9 qui, en octobre 1985, regardait une disquette tourner dans un C64 depuis sa chambre à Oslo. 40 ans plus tard, il est toujours à la table, toujours à faire du pixel art pour son groupe.

Je pense que vous comprenez maintenant pourquoi Razor 1911 n'est pas juste un groupe warez mais une vraie institution culturelle !

La longévité de ce groupe dépasse largement l'existence de la plupart des entreprises tech. Plus long que le leadership de Microsoft, plus long que l'histoire commerciale d'Apple sur le marché grand public, plus long que n'importe quelle plateforme de jeux vidéo encore active aujourd'hui. Razor 1911 a survécu au C64, à l'Amiga, à Windows 3.1, 95, XP, 7, 10, 11. Ils ont survécu aux BBS, à IRC, à eDonkey, à BitTorrent. Ils ont même survécu au FBI.

Et s'ils ont traversé les époques, c'est parce que la scene n'est pas un business. C'est une pratique culturelle qui se transmet de génération en génération, avec ses règles, son vocabulaire, ses rivalités, ses codes d'honneur bizarroïdes.

Des générations entières de développeurs et de chercheurs en sécurité sont passés par la scene avant de devenir des professionnels reconnus dans l'industrie. Je pense par exemple à Jonathan James ou Ehud Tenenbaum à l'époque. Razor 1911 illustre cette trajectoire fascinante où l'art, le crime et la passion se mélangent dans des proportions variables selon les décennies. Et le reverse engineering qui sert aujourd'hui à la recherche en sécurité, est exactement le même savoir-faire qu'avait celui qui crackait un jeu Amiga en 1990.

Bref, 40 ans après, la bande est toujours là, et rien que pour ça, chapeau bien bas !

Sources : Wikipedia | Wikipedia Operation Buccaneer | Waxy.org | DOJ Pitman | DOJ Breen | Interview Pitbull Defacto2 | MIT Technology Review | BleepingComputer Rockstar | Defacto2 | Les NFO de Razor1911

ChipSoft, l'éditeur qui fournit le logiciel de dossiers médicaux à environ 80 % des hôpitaux aux Pays-Bas, vient d'être touché par un ransomware. Le site de l'entreprise est hors ligne depuis le 7 avril, et on ne sait pas encore si des données de patients ont été volées.

Ce qu'il s'est passé

L'attaque a été confirmée le 7 avril par Z-CERT, l'agence néerlandaise qui surveille la sécurité informatique dans le secteur de la santé. ChipSoft développe le logiciel HiX, qui gère les dossiers médicaux de patients dans la grande majorité des hôpitaux du pays. Le site web de l'entreprise est tombé dans la journée et reste inaccessible.

Z-CERT a envoyé un mémo confidentiel aux clients de ChipSoft pour leur demander de couper leur connexion VPN vers les systèmes de l'éditeur. Onze hôpitaux ont déconnecté leurs systèmes par précaution. Les autres ont indiqué que leurs données patients étaient en sécurité et que leurs services continuaient de fonctionner.

Des données patients potentiellement compromises

ChipSoft a confirmé qu'il y avait eu un "incident de données" avec un "possible accès non autorisé". L'entreprise ne peut pas garantir que des données de patients n'ont pas été consultées ou copiées. Le groupe de hackers derrière l'attaque n'a pas été identifié, et aucun montant de rançon n'a été rendu public.

Plusieurs hôpitaux, dont le Rijnstate Hospital, l'Antoni van Leeuwenhoek (spécialisé en cancérologie) et le Franciscus Hospital ont déclaré ne pas être affectés. Mais la portée réelle de l'attaque reste floue.

Le secteur de la santé toujours en première ligne

Z-CERT classe les ransomwares et l'extorsion comme les menaces principales pour les organisations de santé néerlandaises dans son rapport annuel.

Le secteur reste une cible privilégiée parce que les données médicales ont une valeur élevée sur le marché noir, et que les hôpitaux ne peuvent pas se permettre de rester longtemps sans accès à leurs systèmes.

Quand un seul éditeur gère les dossiers médicaux de 80 % des hôpitaux d'un pays, une attaque sur cet éditeur prend une dimension un peu inquiétante.

Pour l'instant les dégâts semblent contenus, mais le fait que ChipSoft ne puisse pas exclure un vol de données, c'est quand même un gros point d'interrogation. Et ça rappelle qu'un système de santé aussi centralisé, ça peut vite devenir une faiblesse.

Source : NL Times

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

cd /tmp

hazmat init --bootstrap-agent claude

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

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

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".

Un passionné a tenté de récupérer son Pokémon coincé dans un Pokéwalker, ce petit podomètre vendu avec Pokémon HeartGold sur DS en 2009, après avoir perdu la cartouche de jeu.

Entre reverse engineering du protocole infrarouge et manipulation du générateur de nombres aléatoires, la tentative est bien technique. Et le résultat est plutôt cruel, pour une raison que personne n'avait anticipée…

Un Pokémon sans cartouche, un vrai problème

Le Pokéwalker, pour ceux qui ne s'en souviennent pas, c'était ce petit podomètre vendu avec Pokémon HeartGold et SoulSilver sur Nintendo DS en 2009. Le principe était simple : vous transfériez un Pokémon de votre partie vers cet accessoire, vous le glissiez dans votre poche, et chaque pas comptait pour gagner des points et débloquer des objets.

49 jours, les amis, c'est la durée de vie d'un Mac avant que son réseau TCP ne s'effondre dans un silence assourdissant. Il suffit d'un overflow d'entier 32 bits dans le kernel XNU, une horloge interne qui se bloque, et hop, plus moyen d'ouvrir la moindre connexion. Le ping marche toujours, parce qu'ICMP se fout du TCP, mais pour le reste... c'est reboot obligatoire ou rien.

Pour savoir combien de temps il vous reste, tapez uptime dans le Terminal. Si votre Mac sous macOS Sequoia, Sonoma ou même Ventura tourne depuis plus de 7 semaines sans redémarrage, c'est le moment d'y remédier car le bug touche toutes les versions.

C'est l'équipe de Photon qui a révélé le problème. Celui-ci est apparu sur une flotte de Macs dédiée à la télémétrie iMessage. Pile 49,7 jours après le dernier redémarrage, plusieurs machines ont lâché en même temps. Plus de nouvelles connexions réseau, mais le ping répondait toujours.

En fouillant le code du noyau XNU d'Apple (qui est open source, faut le rappeler), ils sont tombé sur une variable tcp_now, qui est un compteur 32 bits qui s'incrémente chaque milliseconde. En gros, imaginez un compteur kilométrique qui arrivé au max (environ 4,3 milliards), repasse à zéro.

Sauf que le code contient un garde fou censé empêcher l'horloge de reculer du genre "si la nouvelle valeur est plus petite que l'ancienne, on ne met pas à jour". Ça a l'air malin mais en fait, au moment du rebouclage, patatras : la nouvelle valeur (proche de zéro) est forcément plus petite que l'ancienne (proche du max), du coup le garde fou bloque tout et l'horloge TCP se fige.

Et ensuite, ça part en cascade. Les connexions fermées restent normalement en TIME_WAIT durant 30 secondes sur macOS, avant d'être nettoyées par tcp_gc() mais avec l'horloge gelée, ce nettoyage ne se fait plus. Un netstat -an | grep TIME_WAIT montre alors la catastrophe en temps réel avec des connexions mortes qui s'empilent, et finissent par bouffer les 16 384 ports éphémères (range 49152-65535 sur macOS) restant... Et au bout de quelques heures, plus rien ne passe !

Photon a laissé tourner deux machines après l'overflow pour voir. Neuf heures plus tard, l'une affichait 8 000 connexions zombies et un load average de 49. La machine ne faisait plus que scanner sa propre file d'attente de connexions mortes.

Si ça vous rappelle quelque chose, c'est normal car j'sais pas si vous vous souvenais mais Windows 95 plantait au bout du même délai pour la même raison (le fameux GetTickCount() en 32 bits). Le Boeing 787 avait également un souci similaire au bout de 51 jours sur ses switches réseau, sans oublier le bug de l'an 2038 sous Unix, qui est la version signée du même phénomène. 30 ans séparent certains de ces bugs qui pourtant appartiennent à la même catégorie !

Après flippez pas car des devs avec des Macs à plus de 600 jours d'uptime disent n'avoir jamais eu le souci. À vrai dire, le bug ne se déclencherait que si votre Mac n'a aucun trafic TCP pile au moment de l'overflow. Si votre machine cause au réseau en permanence (et c'est le cas de 99% des Macs), l'horloge passe le cap sans broncher.

Les machines les plus exposées sont en fait les serveurs CI/CD sous macOS, les Mac mini en ferme de build Jenkins ou GitHub Actions, les Mac Pro dédiés au rendu 3D avec Blender ou Cinema 4D. Le MacBook qui passe en veille tous les soirs n'est pas vraiment concerné (le compteur tcp_now ne tourne pas pendant la veille, donc le délai de 49 jours ne concerne que le temps d'activité réel).

Maintenant pour vérifier votre compte à rebours personnel, ouvrez un Terminal et collez y ceci :

boot_sec=$(sysctl kern.boottime | grep -o 'sec = [0-9]*' | head -1 | awk '{print $3}')
now_sec=$(date +%s)
remain=$(( 4294967 - (now_sec - boot_sec) ))
echo "Temps restant avant overflow : $((remain/3600))h $((remain%3600/60))m"

CUPS, le système d'impression utilisé par macOS et la plupart des distributions Linux, est touché par deux nouvelles vulnérabilités. Elles ont été trouvées par des agents d'intelligence artificielle, et permettent une exécution de code à distance.

Aucun correctif officiel n'est disponible pour le moment, et les preuves de concept sont déjà publiques. Les environnements professionnels sont les premiers concernés.

Quand l'IA fait le boulot des chercheurs en sécurité

C'est un ingénieur sécurité de SpaceX, Asim Manizada, qui a publié les détails de ces deux failles. Le plus surprenant, c'est qu'il ne les a pas trouvées tout seul. Il a utilisé des agents IA pour analyser le code de CUPS et débusquer les problèmes.

Son travail s'inspire des recherches de Simone Margaritelli, qui avait déjà montré en 2024 comment enchaîner plusieurs failles CUPS pour exécuter du code à distance sur des machines Linux.

Les deux vulnérabilités portent les références CVE-2026-34980 et CVE-2026-34990. Elles touchent CUPS 2.4.16 et peuvent être combinées pour un résultat assez redoutable.

Deux failles qui se complètent

La première faille permet à un attaquant d'envoyer une tâche d'impression sur une file PostScript partagée, sans aucune authentification.

CUPS accepte par défaut les requêtes anonymes sur les files partagées, et un mécanisme d'échappement de caractères permet d'injecter du code qui sera exécuté en tant qu'utilisateur "lp". En pratique, un attaquant peut forcer le serveur à lancer un programme de son choix.

La seconde faille concerne l'authentification du démon cupsd. Un utilisateur local sans privilège peut tromper le service pour qu'il s'authentifie auprès d'un faux serveur IPP contrôlé par l'attaquant.

Le jeton récupéré permet alors d'écraser n'importe quel fichier avec les droits root. Combinées, les deux failles donnent à un attaquant distant et non authentifié la possibilité d' écraser des fichiers système en tant que root.

Pas de patch, mais des correctifs dans les tuyaux

Pour le moment, aucune mise à jour officielle de CUPS n'a été publiée. Michael Sweet, le créateur et mainteneur du projet, a mis en ligne des correctifs sur GitHub, mais il n'y a pas encore de version patchée à télécharger.

Manizada prévient que ces failles seront faciles à reproduire, vu que les preuves de concept sont publiques et que les modèles de langage actuels peuvent transformer un rapport technique en exploit fonctionnel en quelques minutes.

Côté impact, CUPS est le système d'impression par défaut de macOS et de la quasi-totalité des distributions Linux. Pour être vulnérable, il faut que le serveur CUPS soit accessible sur le réseau avec une file d'impression partagée configurée, ce qui est courant dans les environnements professionnels.

C'est quand même un drôle de signal. D'un côté, l'IA montre qu'elle sait trouver des failles de sécurité plus vite que les humains. De l'autre, les mainteneurs open source galèrent toujours autant pour sortir les correctifs à temps. Manizada lui-même le dit : les modèles de langage peuvent convertir un simple rapport technique en code d'attaque prêt à l'emploi.

Du coup, entre la divulgation d'une faille et le premier exploit, on parle de quelques heures, pas de quelques semaines. Si vous gérez des imprimantes en réseau, le plus prudent reste de couper le partage des files CUPS en attendant le patch, ou au moins de restreindre l'accès réseau au service. Pas très pratique, mais c'est le prix à payer quand le système d'impression a vingt ans de code derrière lui.

Source : The Register

Vous vous souvenez de BadUSB ? Mais siiii, c'est ce truc dévoilé en 2014 à la Black Hat qui avait foutu la trouille à tout le monde. Ça montrait qu'un simple périphérique USB pouvait se faire passer pour un clavier et balancer des commandes à votre place. Hé bien depuis, les attaques se sont bien raffinées et c'est pourquoi un dev vient de proposer un module kernel Linux capable de détecter ces saloperies.

Enfin !

Ce module s'appelle hid-omg-detect et c'est signé Zubeyr Almaho. Le patch (déjà en v2) a été soumis le 4 avril dernier sur la LKML. Alors je pense que vous allez vous dire que c'est encore un truc qui va bloquer par défaut vos périphériques USB sauf que non, ça ne bloque rien. En fait, il surveille passivement les périphériques HID (claviers, souris...) et leur attribue un score de suspicion basé sur trois critères.

D'abord, l'entropie des frappes clavier. Un humain tape de manière irrégulière, avec des pauses, des hésitations, des fautes (perso je fais au moins 3 fautes de frappe par phrase ^^). Un câble trafiqué, lui, balance ses commandes avec une régularité de métronome, genre 500 caractères en 2 secondes sans une seule erreur. Ensuite, y'a la latence entre le branchement et la première frappe. Si votre "clavier" commence à taper immédiatement après avoir été branché... y'a comme un souci. Et enfin, le fingerprinting des descripteurs USB pour repérer les vendor/product IDs suspects ou les anomalies dans les descripteurs HID.

Pas con hein ? Et si le score dépasse un certain seuil (configurable), hop, le module balance un warning dans dmesg et vous oriente vers USBGuard pour bloquer le périphérique. Parce que hid-omg-detect ne touche à rien lui-même. Il sonne juste l'alarme, et c'est à vous d'agir !

Mais alors pourquoi lancer ça maintenant ?

Hé bien parce que les outils d'attaque USB sont devenus légion ! Les câbles O.MG (créés par le chercheur MG et distribués via Hak5), par exemple, ça ressemble à un câble USB lambda que vous emprunteriez sans réfléchir pour charger votre téléphone. Sauf que dedans y'a un implant WiFi capable d'injecter des frappes, de les logger, de spoofer les identifiants USB, le tout contrôlable à distance. Quand je pense qu'il y a quelques mois, des chercheurs montraient qu'une simple webcam Lenovo pouvait être transformée en dispositif BadUSB ... Sa fé grav réchéflir 🤓 comme dirait les citoyens souverains ^^.

Maintenant, en attendant que le patch soit accepté, vous n'êtes pas totalement démunis non plus. Des outils comme USBRip (un script Python, pip3 install usbrip) permettent déjà de tracer les connexions et déconnexions USB en parsant /var/log/syslog. Y'a pas ce scoring d'anomalies, mais au moins vous avez un historique pour savoir qui a branché quoi et quand. Et si vous êtes vraiment parano (et franchement, vous avez raison de l'être), USBGuard peut carrément whitelister vos périphériques de confiance et bloquer tout le reste. Mais le problème d'une telle solution c'est que ça demande de maintenir une liste blanche à jour, ce qui n'est pas toujours pratique quand on branche 15 trucs par jour.

On verra si les mainteneurs du kernel l'accepte... Après ça ne protégera pas contre tous les scénarios non plus. Un périphérique qui attend 30 secondes avant de commencer son injection pourrait passer sous le radar. Et si un attaquant injecte du jitter aléatoire dans ses frappes pour simuler un humain, là ce sera plus compliqué. Mais combiné avec USBGuard, ça donnera enfin une vraie ligne de défense native contre les attaques par périphériques USB piégés . Et c'est quand même mieux que de boucher ses ports au plâtre et ciment (Mais pleure pas au dessus du mortier...) !

Bref, va falloir garder un œil là-dessus.

Source