Quotidien suisseMardi 6 octobre 2026Édition de 13h, technologie
Prochaine publication le 6 octobre 2026 à 17h
Une · Sécurité · Danemark
Danemark : les données de 8,8 millions de personnes aspirées du registre CPR
Lundi 5.10, le ministère danois de la Recherche, de l’Éducation et du Numérique annonce que des inconnus ont obtenu sans autorisation les noms, adresses et numéros CPR (le numéro d’identification personnel danois) d’environ 8,8 millions de personnes inscrites au registre central de la population, vivantes, émigrées ou décédées. Le registre en compte environ 11 millions.
Selon le communiqué officiel, les attaquants ont détourné l’accès légal d’une entreprise privée danoise autorisée à interroger le registre, dans les limites des données ouvertes aux sociétés privées. L’administration du CPR a remarqué le vendredi soir 2.10 un comportement irrégulier survenu au cours de septembre, puis a établi l’ampleur de la fuite pendant le week-end. Les personnes inscrites avec une protection du nom et de l’adresse ne sont pas concernées. L’accès de l’entreprise a été coupé, l’autorité de protection des données (Datatilsynet) a été saisie et la police enquête. D’après BleepingComputer, Datatilsynet évoque une forme d’énumération par force brute des numéros CPR valides, avant l’extraction des fiches correspondantes. Le nom de l’entreprise n’est pas publié.
La ministre Christina Egelund parle d’un incident « profondément grave », a informé la commission parlementaire compétente et demandé un audit de sécurité complet du système. Le principal risque immédiat est l’hameçonnage crédible : le ministère rappelle de ne jamais donner de mot de passe par téléphone ou courriel, même si l’interlocuteur connaît nom, adresse et numéro CPR. La ligne d’assistance Cyberhotline (+45 33 37 00 37) est ouverte de 8h à minuit ces prochains jours.
Mold 3.0 : l’éditeur de liens rapide réécrit en Rust
Le 5.10, Rui Ueyama publie Mold 3.0, première version de son éditeur de liens (linker) réécrite de C++ en Rust. Elle se présente comme un remplacement direct de Mold 2.42.1, dernière version en C++. Objectif affiché de la série 3.x : combler les derniers écarts de compatibilité avec GNU ld, en particulier les scripts d’édition de liens, pour que Mold puisse devenir l’éditeur de liens par défaut des distributions Linux.
Selon l’annonce, la version Rust résiste mieux aux fichiers objets corrompus et corrige de nombreux bugs au passage. Elle exige Rust 1.95 ou plus récent, n’a plus besoin de la bibliothèque de parallélisme oneTBB d’Intel et se construit avec Cargo au lieu de CMake.
Google suspend sa prime aux failles open source, noyée sous les rapports automatisés
Google n’accepte plus, temporairement, les signalements de vulnérabilités produit dans son programme de récompenses open source (OSS VRP), lancé en 2022 pour Go, Angular, Bazel, Protocol Buffers ou Fuchsia, avec des primes de 100 à 31 337 dollars. Motif invoqué : une forte hausse des soumissions automatisées, « dont la grande majorité ne sont pas valides ».
Restent ouverts les rapports sur la chaîne d’approvisionnement, les dossiers déjà déposés (avant le 1.10) et le programme de primes aux correctifs. Google promet une refonte et un point au premier trimestre 2027. Le projet curl avait arrêté son programme pour la même raison en janvier, et Intel a supprimé ses récompenses financières mi-septembre, sans explication.
Math.random() n’est pas un secret : la leçon de la faille Rejetto HFS
Le serveur de fichiers libre Rejetto HFS (versions 3.0.0 à 3.2.0) fait l’objet de sondages actifs pour CVE-2026-61500, selon VulnCheck. La faille tient en une erreur classique : une clé de signature tirée d’un générateur pseudo-aléatoire non cryptographique. Atelier pédagogique.
Deux familles de générateurs. Un générateur pseudo-aléatoire (PRNG) part d’un état interne et produit une suite de nombres qui paraît aléatoire. Pour une simulation ou un jeu, il suffit que la suite soit bien répartie et rapide à calculer. Pour un secret (clé, jeton de session, mot de passe temporaire), il faut une propriété de plus : qu’en observant des sorties, on ne puisse ni deviner les suivantes ni retrouver les précédentes. C’est la définition d’un générateur cryptographique (CSPRNG). Math.random() en JavaScript appartient à la première famille. Dans V8, le moteur de Chrome et de Node.js, il repose sur l’algorithme xorshift128+ : 128 bits d’état, des décalages et des XOR, donc des opérations linéaires qu’un solveur de contraintes (comme Z3) sait inverser à partir de quelques sorties consécutives.
La chaîne dans HFS. D’après l’analyse publiée par Horizon3 le 30.09, HFS signait ses cookies de session (via le framework Koa et sa bibliothèque keygrip) avec une clé construite au démarrage à partir de trois appels à Math.random(). Le même générateur servait ensuite à créer un identifiant renvoyé tel quel au client, en pleine précision, dans un cookie simplement encodé en base64, signé mais pas chiffré. Un attaquant qui lance quelques débuts de connexion récolte donc des sorties consécutives, reconstitue l’état du générateur, remonte la suite jusqu’aux valeurs du démarrage et vérifie chaque clé candidate contre la signature de son propre cookie. Avec la clé, il fabrique un cookie administrateur valide, puis exécute du code grâce à la fonction de l’API d’administration qui permet de définir du JavaScript côté serveur. Horizon3 dit avoir trouvé la chaîne avec le modèle Mythos d’Anthropic.
Ce qu’il faut faire. Pour tout secret, utiliser le générateur du système : crypto.randomBytes() ou crypto.getRandomValues() en JavaScript, secrets en Python, getrandom() sous Linux. Ne jamais exposer à l’extérieur des sorties d’un générateur qui sert aussi à fabriquer des secrets. Préférer une clé de signature fournie par configuration et persistée, plutôt que générée au démarrage. Enfin, un cookie « signé » garantit son intégrité, pas sa confidentialité : tout ce qu’il contient est lisible par le client. Correctif : HFS 3.2.1, ou mieux la dernière version stable 3.3.4.
ZRAM : lecture et écriture séparées pour économiser la mémoire
Sergey Senozhatsky (Google, équipe Chrome) a soumis le 5.10 une refonte de ZRAM, le périphérique de swap compressé en RAM du noyau Linux. Jusqu’ici, compression et décompression partageaient le même flux par CPU : un lecteur prioritaire pouvait rester bloqué derrière un écrivain préempté qui tenait le verrou, un cas d’inversion de priorité. La série sépare les flux de lecture et d’écriture, et n’alloue plus qu’un seul contexte pour la recompression. Gain annoncé : de quelques dizaines à quelques centaines de Ko par contexte et par CPU selon les algorithmes (zstd, deflate, lz4hc). En revue, pas encore intégré.
AMD Zen 6 : isolation matérielle du BTB attendue dans Linux 7.4
Un patch mis en file dans la branche x86/bugs du dépôt tip prend en charge la nouvelle isolation par contexte du tampon de cibles de branchement (BTB) des processeurs Zen 6. Elle sépare utilisateur et noyau, invité et hôte, ce qui rend inutile la mitigation SafeRET contre SRSO (la faille de débordement spéculatif de la pile de retour des Zen 1 à 4). Les attaques entre deux processus utilisateurs ou deux invités restent couvertes par la barrière IBPB au changement de contexte.
