Faucon, vraie faiblesse

L’équipe Frontier Red Team d’Anthropic a publié un billet dans lequel elle décrit ses trouvailles sur deux algorithmes dédiés à la cybersécurité : HAWK et AES. Si les découvertes sont avérées, les conséquences ne sont pas aussi dramatiques qu’on peut le lire ça et là. Elles ne sont pas inexistantes pour autant.

Le 28 juillet 2026, Anthropic a publié un billet de recherche consacré à la « découverte de faiblesses cryptographiques avec Claude ». Il décrit les trouvailles réalisées avec une préversion interne de Mythos qui n’est pas encore accessible au public.

Les découvertes concernent deux algorithmes de sécurité. D’abord HAWK, un schéma de signature numérique conçu pour résister aux ordinateurs quantiques. Ensuite AES, ou plus exactement une version réduite d’AES, utilisée en général en recherche pour mieux étudier la robustesse de cet algorithme.

Dans son billet, Anthropic affirme qu’aucune de ces découvertes n’a d’incidence sur l’informatique actuelle. Certes, mais elles ont tout de même quelques conséquences, même si elles sont loin de l’apocalypse décrite par certains.

Le vol court du faucon post-quantique

Oups faille de sécurité assez grave dans TOR.
(Permalink)

Un seul code vous manque et tout est perdu

Le 26 juillet, l’équipe de GrapheneOS s’est lancée tout à coup dans un exposé de nombreuses mesures de sécurité, avec une insistance particulière pour la gestion des mots de passe. Ce calendrier ne doit rien au hasard : pour la première fois aux États-Unis, le ministère de la Justice poursuit un citoyen américain pour destruction présumée de données à l’aide d’un mot de passe « contraint ».

Depuis deux jours, le compte X de GrapheneOS répond à de nombreuses questions sur la gestion de ses mots de passe. L’équipe en a fait une synthèse dans son forum pour résumer toutes les informations.

L’équipe explique que le système mobile est basé sur Android 17 et « sur le matériel le plus sécurisé disponible pour Android », la liste se limitant aujourd’hui aux seuls Pixel de Google. Elle rappelle cependant que la situation va évoluer en 2027, grâce à un partenariat avec Motorola Mobility et « aux progrès réalisés par Qualcomm ». Un signal assez fort pour l’industrie, qui pourrait se rapprocher de Graphene pour lancer des smartphones très orientés vers la sécurité. On parle bien de nouveaux modèles, car aucun appareil Motorola actuel ne dispose des sécurités nécessaires.

• Motorola s’associe à GrapheneOS pour renforcer la sécurité de ses (futurs) smartphones

Les informations se concentrent tout particulièrement sur la protection des mots de passe et autres secrets, ainsi que sur les défenses du système mobile contre l’extraction de données. Le chiffrement du disque constitue ainsi la première ligne de défense : même les attaquants les plus sophistiqués ne peuvent le casser directement, et doivent soit exploiter l’OS en état « After First Unlock » (après premier déverrouillage), soit forcer le PIN ou mot de passe par force brute.

L’équipe indique également que GrapheneOS supporte uniquement les appareils ayant un secure element avec des limitations strictes sur les tentatives de mots de passe et codes PIN : 4 heures après 10 tentatives échouées, 41 jours après 15, avec seulement 20 tentatives autorisées au total. Le secure element est pour rappel une puce dédiée, physiquement et logiciellement isolée, conçue pour stocker les secrets et résister à leur extraction. Dans le contexte de GrapheneOS, il a en outre un rôle précis : il détient les compteurs de tentatives de déverrouillage et applique la limitation de débit, expliquant les délais de plus en plus longs entre les tentatives. Stocker les compteurs dans la puce empêche de « tricher » en les réinitialisant.

Parmi les autres points abordés, on peut citer la limite de caractères des mots portée de 16 à 128, la possibilité d’utiliser un facteur biométrique pour que le système reste utilisable au quotidien (5 tentatives biométriques seulement, qui comptent dans le quota général), des allocateurs de mémoire durcis, le hardware memory tagging (MTE) pour renforcer la résistance aux exploitations de failles inconnues, le blocage par défaut des nouvelles connexions USB quand l’appareil est verrouillé, ou encore un minuteur de redémarrage automatique, ramenant l’appareil en état « Before First Unlock » (avant premier déverrouillage) au bout de 18 heures (par défaut) sans déverrouillage de l’appareil. Ce dernier comportement a d’ailleurs été repris par Apple et Google dans leurs systèmes.

• Le redémarrage automatique des iPhone inactifs est bien une fonctionnalité d’iOS 18

Dans le billet, on trouve également un paragraphe consacré au PIN de contrainte. Présentée comme un outil relativement mineur et optionnel, il efface l’appareil quand il est saisi dans n’importe quelle invite d’authentification (déverrouillage, changement de réglage sensible, etc.). Il fonctionne sur tous les profils, y compris les utilisateurs secondaires et Private Spaces. L’équipe de GrapheneOS insiste : les données ne dépendent pas de cette fonctionnalité pour être protégées. Elle est considérée comme un outil parmi d’autres, et son usage réel doit être mûrement réfléchi compte tenu des conséquences physiques ou juridiques possibles.

L’affaire Samuel Tunick

La mention des conséquences juridiques n’est pas due au hasard. Si l’équipe de Graphene communique tant autour des protections de son système en ce moment, c’est à cause d’un évènement juridique majeur aux États-Unis lié à la tech.

Pour la première fois (a priori), des procureurs fédéraux poursuivent en effet un citoyen américain pour destruction présumée de données à l’aide d’un mot de passe « contraint » intégré au logiciel d’un téléphone. C’est le lien avec la communication abondante : le logiciel en question n’est autre que GrapheneOS.

Samuel Tunick a été initialement arrêté sans mandat le 25 janvier 2025 à l’aéroport de Hartsfield-Jackson (Atlanta) par les douanes américaines, sur la base de l’exception de fouille frontalière au Quatrième amendement. Alors que les agents fédéraux tentaient d’accéder à son téléphone lors de l’inspection, Tunick aurait saisi un mot de passe de contrainte GrapheneOS qui a immédiatement effacé les données stockées sur l’appareil.

Tunick est donc poursuivi en vertu de la loi américaine pour avoir fourni aux agents frontaliers un code d’accès ayant causé l’effacement du contenu numérique de son téléphone, ce que les procureurs qualifient de destruction intentionnelle de biens pour empêcher leur saisie.

Un enjeu plus grand que le cas individuel

La communication de GrapheneOS est probablement défensive, pour documenter publiquement la robustesse cryptographique de son modèle de menace face à l’attention médiatique soudaine portée à la fonction « mot de passe de contrainte ».

Sur le plan juridique, l’enjeu dépasse le cas individuel : la question posée aux tribunaux est de savoir si l’activation d’une fonctionnalité de sécurité native – conçue précisément pour protéger des données personnelles en cas de contrainte – peut être qualifiée pénalement de destruction de preuves, y compris lorsque la fouille initiale s’est déroulée sans mandat.

Sans surprise, les avocats de Samuel Tunick contestent cette version des faits. Ils affirment que la détention et la saisie étaient illégales, et accusent le gouvernement américain d’exiger l’accès au téléphone sous prétexte d’une recherche d’images pédopornographiques, sans fournir aucun élément pour étayer ces soupçons.

Pour les avocats, cette arrestation et cette affaire sont politiques. Le gouvernement s’en serait pris à Samuel Tunick non pas pour d’éventuels matériels pédopornographiques, mais pour son association avec un mouvement appelé « Defend the Atlanta Forest ». Ce dernier s’oppose à la création d’un énorme campus de formation pour les forces de l’ordre à Atlanta, surnommé « Cop City », critiqué pour son impact environnemental (plus de 34 hectares déforestés) et son coût de 67 millions de dollars.

Les avocats demandent l’annulation de toute la procédure, au motif qu’elle viole les Quatrième, Cinquième et Sixième amendements de la Constitution américaine. Des violations liées à la manière dont l’interrogatoire a été mené, au refus d’un avocat, à l’absence alléguée d’avertissements Miranda (le fameux « Vous avez le droit de garder le silence »), ou encore à la fouille et la saisie sans mandat.

« Je n’ai jamais vu cela auparavant, même si j’ai discuté du scénario potentiel avec des activistes et des journalistes au fil des années. Je pense que cette affaire rappelle que les autorités peuvent prétendre que vous avez sciemment détruit des données, donc il vaut mieux ne pas avoir ces données sur vous lorsque vous franchissez certaines frontières », a réagi Runa Sandvik, une experte en sécurité informatique, auprès de TechCrunch.

Un seul code vous manque et tout est perdu

Le 26 juillet, l’équipe de GrapheneOS s’est lancée tout à coup dans un exposé de nombreuses mesures de sécurité, avec une insistance particulière pour la gestion des mots de passe. Ce calendrier ne doit rien au hasard : pour la première fois aux États-Unis, le ministère de la Justice poursuit un citoyen américain pour destruction présumée de données à l’aide d’un mot de passe « contraint ».

Depuis deux jours, le compte X de GrapheneOS répond à de nombreuses questions sur la gestion de ses mots de passe. L’équipe en a fait une synthèse dans son forum pour résumer toutes les informations.

L’équipe explique que le système mobile est basé sur Android 17 et « sur le matériel le plus sécurisé disponible pour Android », la liste se limitant aujourd’hui aux seuls Pixel de Google. Elle rappelle cependant que la situation va évoluer en 2027, grâce à un partenariat avec Motorola Mobility et « aux progrès réalisés par Qualcomm ». Un signal assez fort pour l’industrie, qui pourrait se rapprocher de Graphene pour lancer des smartphones très orientés vers la sécurité. On parle bien de nouveaux modèles, car aucun appareil Motorola actuel ne dispose des sécurités nécessaires.

• Motorola s’associe à GrapheneOS pour renforcer la sécurité de ses (futurs) smartphones

Les informations se concentrent tout particulièrement sur la protection des mots de passe et autres secrets, ainsi que sur les défenses du système mobile contre l’extraction de données. Le chiffrement du disque constitue ainsi la première ligne de défense : même les attaquants les plus sophistiqués ne peuvent le casser directement, et doivent soit exploiter l’OS en état « After First Unlock » (après premier déverrouillage), soit forcer le PIN ou mot de passe par force brute.

L’équipe indique également que GrapheneOS supporte uniquement les appareils ayant un secure element avec des limitations strictes sur les tentatives de mots de passe et codes PIN : 4 heures après 10 tentatives échouées, 41 jours après 15, avec seulement 20 tentatives autorisées au total. Le secure element est pour rappel une puce dédiée, physiquement et logiciellement isolée, conçue pour stocker les secrets et résister à leur extraction. Dans le contexte de GrapheneOS, il a en outre un rôle précis : il détient les compteurs de tentatives de déverrouillage et applique la limitation de débit, expliquant les délais de plus en plus longs entre les tentatives. Stocker les compteurs dans la puce empêche de « tricher » en les réinitialisant.

Parmi les autres points abordés, on peut citer la limite de caractères des mots portée de 16 à 128, la possibilité d’utiliser un facteur biométrique pour que le système reste utilisable au quotidien (5 tentatives biométriques seulement, qui comptent dans le quota général), des allocateurs de mémoire durcis, le hardware memory tagging (MTE) pour renforcer la résistance aux exploitations de failles inconnues, le blocage par défaut des nouvelles connexions USB quand l’appareil est verrouillé, ou encore un minuteur de redémarrage automatique, ramenant l’appareil en état « Before First Unlock » (avant premier déverrouillage) au bout de 18 heures (par défaut) sans déverrouillage de l’appareil. Ce dernier comportement a d’ailleurs été repris par Apple et Google dans leurs systèmes.

• Le redémarrage automatique des iPhone inactifs est bien une fonctionnalité d’iOS 18

Dans le billet, on trouve également un paragraphe consacré au PIN de contrainte. Présentée comme un outil relativement mineur et optionnel, il efface l’appareil quand il est saisi dans n’importe quelle invite d’authentification (déverrouillage, changement de réglage sensible, etc.). Il fonctionne sur tous les profils, y compris les utilisateurs secondaires et Private Spaces. L’équipe de GrapheneOS insiste : les données ne dépendent pas de cette fonctionnalité pour être protégées. Elle est considérée comme un outil parmi d’autres, et son usage réel doit être mûrement réfléchi compte tenu des conséquences physiques ou juridiques possibles.

L’affaire Samuel Tunick

La mention des conséquences juridiques n’est pas due au hasard. Si l’équipe de Graphene communique tant autour des protections de son système en ce moment, c’est à cause d’un évènement juridique majeur aux États-Unis lié à la tech.

Pour la première fois (a priori), des procureurs fédéraux poursuivent en effet un citoyen américain pour destruction présumée de données à l’aide d’un mot de passe « contraint » intégré au logiciel d’un téléphone. C’est le lien avec la communication abondante : le logiciel en question n’est autre que GrapheneOS.

Samuel Tunick a été initialement arrêté sans mandat le 25 janvier 2025 à l’aéroport de Hartsfield-Jackson (Atlanta) par les douanes américaines, sur la base de l’exception de fouille frontalière au Quatrième amendement. Alors que les agents fédéraux tentaient d’accéder à son téléphone lors de l’inspection, Tunick aurait saisi un mot de passe de contrainte GrapheneOS qui a immédiatement effacé les données stockées sur l’appareil.

Tunick est donc poursuivi en vertu de la loi américaine pour avoir fourni aux agents frontaliers un code d’accès ayant causé l’effacement du contenu numérique de son téléphone, ce que les procureurs qualifient de destruction intentionnelle de biens pour empêcher leur saisie.

Un enjeu plus grand que le cas individuel

La communication de GrapheneOS est probablement défensive, pour documenter publiquement la robustesse cryptographique de son modèle de menace face à l’attention médiatique soudaine portée à la fonction « mot de passe de contrainte ».

Sur le plan juridique, l’enjeu dépasse le cas individuel : la question posée aux tribunaux est de savoir si l’activation d’une fonctionnalité de sécurité native – conçue précisément pour protéger des données personnelles en cas de contrainte – peut être qualifiée pénalement de destruction de preuves, y compris lorsque la fouille initiale s’est déroulée sans mandat.

Sans surprise, les avocats de Samuel Tunick contestent cette version des faits. Ils affirment que la détention et la saisie étaient illégales, et accusent le gouvernement américain d’exiger l’accès au téléphone sous prétexte d’une recherche d’images pédopornographiques, sans fournir aucun élément pour étayer ces soupçons.

Pour les avocats, cette arrestation et cette affaire sont politiques. Le gouvernement s’en serait pris à Samuel Tunick non pas pour d’éventuels matériels pédopornographiques, mais pour son association avec un mouvement appelé « Defend the Atlanta Forest ». Ce dernier s’oppose à la création d’un énorme campus de formation pour les forces de l’ordre à Atlanta, surnommé « Cop City », critiqué pour son impact environnemental (plus de 34 hectares déforestés) et son coût de 67 millions de dollars.

Les avocats demandent l’annulation de toute la procédure, au motif qu’elle viole les Quatrième, Cinquième et Sixième amendements de la Constitution américaine. Des violations liées à la manière dont l’interrogatoire a été mené, au refus d’un avocat, à l’absence alléguée d’avertissements Miranda (le fameux « Vous avez le droit de garder le silence »), ou encore à la fouille et la saisie sans mandat.

« Je n’ai jamais vu cela auparavant, même si j’ai discuté du scénario potentiel avec des activistes et des journalistes au fil des années. Je pense que cette affaire rappelle que les autorités peuvent prétendre que vous avez sciemment détruit des données, donc il vaut mieux ne pas avoir ces données sur vous lorsque vous franchissez certaines frontières », a réagi Runa Sandvik, une experte en sécurité informatique, auprès de TechCrunch.

Microsoft a présenté le 27 juillet 2026 une architecture de sécurité entièrement bâtie sur l'IA agentique, avec une préversion publique annoncée pour le 3 août 2026.

Google Threat Intelligence Group a lancé une nouvelle nomenclature pour ses groupes de hackers, remplaçant les identifiants historiques de Mandiant et du Threat Analysis Group par des cryptonymes en deux mots.

Fin juin, à l’occasion de la mise en ligne d’iOS 26.5.2, Apple avait expliqué que le processus de distribution des mises à jour de sécurité pour ses systèmes d’exploitation s’était accéléré. En cause : l’IA générative qui permet de développer rapidement « des outils de piratage malveillants ».

Un cycle plus expéditif qui explique aussi peut-être pourquoi la dernière livraison est si riche en correctifs. iOS 26.6 et iPadOS 26.6 corrigent en effet la bagatelle de 87 vulnérabilités, soit autant de CVE dans la longue liste publiée par Apple.

Aucune d’entre elles n’a été exploitée activement avant la publication du correctif (« zero day »), en revanche plusieurs sont considérées comme très sérieuses. C’est le cas de CVE-2026-64747 dans le composant système AVEVideoEncoder, qui permet à une application d’exécuter du code arbitraire avec les privilèges du noyau. Ou encore CVE-2026-43813 dans le composant CloudAttestation chargé de vérifier l’intégrité des applications, qui permet de contourner le contrôle de signature du code.

Plusieurs failles du noyau autorisaient l’écriture et la corruption de sa mémoire, ce qui peut servir à élever les privilèges ou à compromettre plus largement le système.

Le nombre de correctifs est encore plus important dans macOS 26.6 Tahoe : le bulletin dénombre 155 identifiants CVE. Là non plus, aucune faille « zero day » au compteur, mais on retrouve les mêmes vulnérabilités critiques que sous iOS 26.6, avec en plus des failles propres au système (dans Accounts, Core Services, CUPS, Remote Management…) avec à chaque fois un risque d’obtention des privilèges root. Une faille dans HFS peut aussi permettre l’exécution de code arbitraire. Une vulnérabilité dans le Wi-Fi peut faire sortir une app du bac à sable ou lui accorder certains privilèges. watchOS 26.6, tvOS 26.6 et visionOS 26 comprennent plus de 80 correctifs.

C’est entendu, on est encore loin des 570 failles colmatées dans Windows 11 via le dernier Patch Tuesday, mais à l’échelle d’Apple c’est tout de même significatif. Habituellement, les mises à jour de sécurité du constructeur comptent quelques dizaines de vulnérabilités. iOS 26.5.2 affichait ainsi 32 failles de sécurité, ce qui était déjà un joli paquet qui devait être intégré dans iOS 26.6.

Signe des temps, plusieurs outils d’IA sont crédités dans les listes des correctifs : Claude (Anthropic), GLM (Z.AI), l’AI Red Ream de NVIDIA, Codex Security (OpenAI)… Apple est également partenaire du projet Glasswing d’Anthropic, qui lui permet depuis avril d’accéder au modèle Mythos spécialisé dans la cybersécurité. Si l’IA générative aide les attaquants, elle épaule aussi les défenseurs.

En attendant un probable iOS 26.6.1, les utilisateurs d’appareils Apple seront bien avisés d’effectuer ces mises à jour. Ce d’autant que ces versions 26.6 intègrent en plus une fonction en préparation d’iOS 27, d’iPadOS 27 et de macOS 27 Golden Gate : elle optimise l’index de Spotlight (le moteur de recherche interne) pour le futur Siri. Un travail qui nécessite plusieurs jours en tâche de fond. Bien sûr, Siri AI ne sera pas lancé cet automne en Europe sur iPhone et iPad, mais il sera tout de même disponible sur Mac.

• Aperçu de Siri AI sur iOS 27 : Apple a-t-elle sauvé le soldat Siri ?

Fin juin, à l’occasion de la mise en ligne d’iOS 26.5.2, Apple avait expliqué que le processus de distribution des mises à jour de sécurité pour ses systèmes d’exploitation s’était accéléré. En cause : l’IA générative qui permet de développer rapidement « des outils de piratage malveillants ».

Un cycle plus expéditif qui explique aussi peut-être pourquoi la dernière livraison est si riche en correctifs. iOS 26.6 et iPadOS 26.6 corrigent en effet la bagatelle de 87 vulnérabilités, soit autant de CVE dans la longue liste publiée par Apple.

Aucune d’entre elles n’a été exploitée activement avant la publication du correctif (« zero day »), en revanche plusieurs sont considérées comme très sérieuses. C’est le cas de CVE-2026-64747 dans le composant système AVEVideoEncoder, qui permet à une application d’exécuter du code arbitraire avec les privilèges du noyau. Ou encore CVE-2026-43813 dans le composant CloudAttestation chargé de vérifier l’intégrité des applications, qui permet de contourner le contrôle de signature du code.

Plusieurs failles du noyau autorisaient l’écriture et la corruption de sa mémoire, ce qui peut servir à élever les privilèges ou à compromettre plus largement le système.

Le nombre de correctifs est encore plus important dans macOS 26.6 Tahoe : le bulletin dénombre 155 identifiants CVE. Là non plus, aucune faille « zero day » au compteur, mais on retrouve les mêmes vulnérabilités critiques que sous iOS 26.6, avec en plus des failles propres au système (dans Accounts, Core Services, CUPS, Remote Management…) avec à chaque fois un risque d’obtention des privilèges root. Une faille dans HFS peut aussi permettre l’exécution de code arbitraire. Une vulnérabilité dans le Wi-Fi peut faire sortir une app du bac à sable ou lui accorder certains privilèges. watchOS 26.6, tvOS 26.6 et visionOS 26 comprennent plus de 80 correctifs.

C’est entendu, on est encore loin des 570 failles colmatées dans Windows 11 via le dernier Patch Tuesday, mais à l’échelle d’Apple c’est tout de même significatif. Habituellement, les mises à jour de sécurité du constructeur comptent quelques dizaines de vulnérabilités. iOS 26.5.2 affichait ainsi 32 failles de sécurité, ce qui était déjà un joli paquet qui devait être intégré dans iOS 26.6.

Signe des temps, plusieurs outils d’IA sont crédités dans les listes des correctifs : Claude (Anthropic), GLM (Z.AI), l’AI Red Ream de NVIDIA, Codex Security (OpenAI)… Apple est également partenaire du projet Glasswing d’Anthropic, qui lui permet depuis avril d’accéder au modèle Mythos spécialisé dans la cybersécurité. Si l’IA générative aide les attaquants, elle épaule aussi les défenseurs.

En attendant un probable iOS 26.6.1, les utilisateurs d’appareils Apple seront bien avisés d’effectuer ces mises à jour. Ce d’autant que ces versions 26.6 intègrent en plus une fonction en préparation d’iOS 27, d’iPadOS 27 et de macOS 27 Golden Gate : elle optimise l’index de Spotlight (le moteur de recherche interne) pour le futur Siri. Un travail qui nécessite plusieurs jours en tâche de fond. Bien sûr, Siri AI ne sera pas lancé cet automne en Europe sur iPhone et iPad, mais il sera tout de même disponible sur Mac.

• Aperçu de Siri AI sur iOS 27 : Apple a-t-elle sauvé le soldat Siri ?

Selon l'institut américain des assurances pour la sécurité routière, les taxis autonomes de Waymo ont eu 68 % d'accidents en moins que des conducteurs humains. Une étude rassurante pour les autorités.

Microsoft : "Votre sécurité est importante pour nous !"
Microsoft GitHub : Rempli de malwares et de liens d'arnaques.
(Permalink)

Trois actualités à retenir cette semaine dans le cyberespace : des agents d'OpenAI qui ont piraté Hugging Face en toute autonomie, une faille noyau critique débusquée par Claude Mythos, et le récit d'une course contre la montre chez OVHcloud pour colmater une vulnérabilité vieille de 16 ans.

• lien nᵒ 1 : Hugging Face explique qu'une IA a réussi à s'introduire dans son infra de prod
• lien nᵒ 2 : OpenAI avoue que ce sont ses propres modèles qui ont conduit cette attaque
• lien nᵒ 3 : L'avénement de Skynet
• lien nᵒ 4 : Comment une évaluation interne d’OpenAI a fini par compromettre les serveurs de Hugging Face

Commentaires : voir le flux Atom ouvrir dans le navigateur

FR-Alert est un dispositif d'alerte à la population pour l'avertir d'un danger, via une notification sur le téléphone. Actif en France depuis juin 2022, il indique l'attitude à avoir selon le lieu et la nature du péril. Et alors que les incendies ravagent le pays, notamment en Gironde, à Fontainebleau ou à Biscarosse, il est utilisé localement par les préfectures pour prévenir les habitants.

Les États-Unis vont-ils serrer la vis sur les poignées de portes à déverrouillage électrique ? La NHTSA va réfléchir à un potentiel cadre sur ce type d'ouverture qui pourrait montrer des lacunes en cas d'urgence.

La mode c'est les passkeys, on est envahi de passkeys

Cette fois, c’est décidé : les SMS et la voix ne seront bientôt plus autorisés dans Entra comme facteur d’authentification. Microsoft évoque l’IA comme accélérateur de cette décision, l’entreprise renvoyant évidemment vers les clés d’accès (passkeys).

Microsoft a annoncé le retrait des SMS et de la voix comme méthodes de MFA (multi-factor authentification) dans l’annuaire d’identité Entra, avec bascule vers les clés d’accès par défaut et une échéance ferme au 1ᵉʳ février 2027.

L’entreprise justifie ce changement par l’explosion de l’IA générative, qui a modifié l’économie du phishing et de l’ingénierie sociale, en automatisant le vol d’identifiants et les opérations d’échanges de SIM (SIM swap) à grande échelle et en deux fois moins de temps.

Un programme au pas de course

Ce changement important ne sera pas d’une traite. Microsoft fournit un calendrier, où les étapes vont cependant s’enchainer rapidement :

• 1ᵉʳ septembre 2026 : invite automatique à enregistrer une clé d’accès lors du prochain défi MFA
• 18 septembre 2026 : publication de la liste des fournisseurs télécom compatibles pour les organisations qui doivent conserver les SMS et/ou la voix pour des raisons réglementaires
• 30 octobre 2026 : obligation de configurer un fournisseur télécom supporté via le Microsoft Security Store pour les organisations restant sur MFA téléphonique
• 1ᵉʳ février 2027 : retrait définitif des SMS/voix fournis par Microsoft, sans dérogation possible

Plusieurs points importants à préciser tout de même. Pour éviter que le processus automatique ne perturbe trop les organisations à compter du 1ᵉʳ septembre, une API sera fournie le 1ᵉʳ aout. Elle permettra aux équipes d’administrations de se retirer (opt-out) du mécanisme pour gérer elles-mêmes la transition.

Il y a le bon CVE et le mauvais CVE

La publication en 48 heures de 432 bulletins CVE pour le noyau Linux a provoqué des interrogations sur la meilleure manière d’intégrer un tel flot de corrections dans les environnements de production. La situation est plus complexe qu’il n’y paraît.

Entre les 20 et 21 juillet, un lot conséquent de 432 CVE a été publié pour le noyau Linux. Cela ne signifie pas que 432 failles ont été corrigées, car le fonctionnement des CVE est différent pour le noyau. En revanche, ils correspondent quand même à des corrections portées dans la branche principale par les mainteneurs du noyau. Se pose alors la question de leur répercussion concrète.

D’abord, qu’est-ce qu’un CVE ? C’est un identifiant unique (Common Vulnerabilities and Exposures) attribué à une faille de sécurité informatique connue publiquement. Une telle vulnérabilité se définit par une faiblesse de la logique d’un logiciel, permettant alors à un attaquant de violer la politique de sécurité et d’effectuer des actions auxquelles il n’a normalement pas droit. Dans la plupart des cas, les CVE sont publiés avant les correctifs associés, car ils servent souvent de base pour les bulletins de sécurité. Le CVE s’accompagne généralement d’un score CVSS (Common Vulnerability Scoring System), censé représenter le niveau de dangerosité de la faille, et de détails contextuels (vecteur d’attaque à distance, niveau de privilèges requis, etc.).

• CVSS 4.0 : dur, dur, d’être un expert !

Il y a CVE et CVE

Les CVE sont attribués par les CNA (CVE Numbering Authorities). Or, depuis février 2024, le projet Linux est devenu sa propre autorité de numérotation, avec des règles spécifiques pour répondre à l’échelle de son immense base de code.

Pour comprendre la situation actuelle, il faut retenir que ces règles sont inversées par rapport au reste de l’industrie. Dans un cas classique, la découverte d’une faille entraine l’attribution d’un CVE, l’alerte puis le développement du patch. Que les détails soient parfois publiés plus tard n’y change rien, le CVE est attribué d’abord. Au sein du projet Linux, c’est le contraire : la découverte d’une faiblesse dans le code entraine le développement d’un patch puis la fusion de celui-ci dans les branches stables du noyau, et seulement après l’apparition d’un CVE. Ce qui signifie qu’au sein du noyau Linux, les failles non corrigées n’ont pas de CVE.

Autre précision importante : l’équipe du noyau attribue systématiquement un CVE à tout correctif de bug susceptible d’impacter la stabilité ou l’accès mémoire, sans chercher à qualifier si le bug est facilement exploitable ou non. C’est ce qu’expliquait sur son blog Greg Kroah-Hartman, mainteneur principal des branches stables du noyau, en février dernier. De même, aucun score CVSS n’est produit, et pour cause : les développeurs du noyau ne connaissent pas l’usage fait de Linux, donc dans quel type d’environnement le code sera exécuté.

En revanche, là où un CVE traditionnel décrit un comportement de haut niveau, un CVE Linux correspond directement à un identifiant de commit Git. Ce suivi automatisé explique pourquoi l’utilisation massive de fuzzers et d’outils d’analyse statique génère des pics soudains de plusieurs centaines de CVE.

Mais alors, où est le problème ?

Si la publication de 432 CVE est en soi inédite, ils correspondent donc à des bugs déjà corrigés. Pourtant Jan Schaumann, architecte en chef de la sécurité de l’information chez Akamai Technologies, s’en est plaint sur la liste de diffusion OSS-SEC. Il y exprime son inquiétude devant un tel volume, demandant comment les entreprises, et de manière générale les environnements de production, peuvent suivre un tel rythme.

Mais en quoi est-ce un problème ? Si les failles sont déjà corrigées, ne suffit-il pas d’attendre sagement la prochaine révision du noyau ? Ce n’est pas si simple.

Plusieurs éléments doivent être considérés. D’un côté, les corrections intégrées aux branches stables signifient que toutes les versions actuellement supportées du noyau Linux vont les répercuter. En théorie, il suffirait d’installer la version suivante dans la branche utilisée, par exemple la 7.2 si l’on utilise une distribution évoluant avec les versions les plus récentes. De l’autre, les environnements de production utilisent souvent des versions modifiées, voire d’anciennes versions dans lesquelles les équipes « backportent » (rétroportent) les modifications qui les intéressent.

C’est là que survient le problème dont se plaint Jan Schaumann : quand 432 CVE sont publiés en 24 heures, comment savoir ce qui est important et doit être rétroporté ? Dans un courrier envoyé à The Register, il évoque la possibilité de faire travailler des LLM pour gérer automatiquement le flux. « Des mises à jour automatisées, régulières et fréquentes qui intègrent tous les changements dans un délai donné me semblent la seule approche raisonnable, mais cela est très difficile pour de nombreuses grandes organisations », explique-t-il ainsi.

Le dernier noyau disponible, toujours

Sur la liste de diffusion OSS-SEC, la discussion présente des réponses intéressantes, notamment celle de Greg Kroah-Hartman en personne. Bien qu’il ne réagisse pas directement au message initial, les solutions envisagées par d’autres sont passées en revue, et il donne nettement sa préférence : toujours utiliser le dernier noyau stable disponible sur la branche souhaitée et vérifier régulièrement l’ensemble des systèmes gérés.

Kroah-Hartman reconnait que ce n’est pas toujours simple au sein des entreprises, mais que des produits payants permettent de gérer efficacement ce processus. Si payer un tel produit n’est pas possible, il recommande d’installer des distributions comme Debian ou Yocto, car « leurs pratiques de sécurité sont extraordinaires ». Les autres solutions représentent plus de travail ou une sécurité moindre. Vérifier un par un les CVE pour ne considérer que ceux importants dans l’infrastructure ? On peut le faire de manière automatisée pour vérifier ce qui ressort à l’intersection des fichiers visés par les CVE et des fichiers réellement utilisés dans l’environnement géré. Mais on en revient à la proposition de Jan Schaumann, et toutes les organisations ne peuvent pas se permettre un tel pipeline de gestion.

En d’autres termes, la meilleure solution reste la répercussion des nouveaux noyaux quand ils deviennent disponibles, mais l’explosion du nombre de CVE – très probablement portée par l’utilisation croissante des LLM – rend la lecture plus complexe. Pour Greg Kroah-Hartman cependant, il n’y a pas vraiment de problème : les 432 CVE étaient en préparation depuis des semaines, personne ne devrait être surpris.

Il y a le bon CVE et le mauvais CVE

La publication en 48 heures de 432 bulletins CVE pour le noyau Linux a provoqué des interrogations sur la meilleure manière d’intégrer un tel flot de corrections dans les environnements de production. La situation est plus complexe qu’il n’y paraît.

Entre les 20 et 21 juillet, un lot conséquent de 432 CVE a été publié pour le noyau Linux. Cela ne signifie pas que 432 failles ont été corrigées, car le fonctionnement des CVE est différent pour le noyau. En revanche, ils correspondent quand même à des corrections portées dans la branche principale par les mainteneurs du noyau. Se pose alors la question de leur répercussion concrète.

D’abord, qu’est-ce qu’un CVE ? C’est un identifiant unique (Common Vulnerabilities and Exposures) attribué à une faille de sécurité informatique connue publiquement. Une telle vulnérabilité se définit par une faiblesse de la logique d’un logiciel, permettant alors à un attaquant de violer la politique de sécurité et d’effectuer des actions auxquelles il n’a normalement pas droit. Dans la plupart des cas, les CVE sont publiés avant les correctifs associés, car ils servent souvent de base pour les bulletins de sécurité. Le CVE s’accompagne généralement d’un score CVSS (Common Vulnerability Scoring System), censé représenter le niveau de dangerosité de la faille, et de détails contextuels (vecteur d’attaque à distance, niveau de privilèges requis, etc.).

• CVSS 4.0 : dur, dur, d’être un expert !

Il y a CVE et CVE

Les CVE sont attribués par les CNA (CVE Numbering Authorities). Or, depuis février 2024, le projet Linux est devenu sa propre autorité de numérotation, avec des règles spécifiques pour répondre à l’échelle de son immense base de code.

Pour comprendre la situation actuelle, il faut retenir que ces règles sont inversées par rapport au reste de l’industrie. Dans un cas classique, la découverte d’une faille entraine l’attribution d’un CVE, l’alerte puis le développement du patch. Que les détails soient parfois publiés plus tard n’y change rien, le CVE est attribué d’abord. Au sein du projet Linux, c’est le contraire : la découverte d’une faiblesse dans le code entraine le développement d’un patch puis la fusion de celui-ci dans les branches stables du noyau, et seulement après l’apparition d’un CVE. Ce qui signifie qu’au sein du noyau Linux, les failles non corrigées n’ont pas de CVE.

Autre précision importante : l’équipe du noyau attribue systématiquement un CVE à tout correctif de bug susceptible d’impacter la stabilité ou l’accès mémoire, sans chercher à qualifier si le bug est facilement exploitable ou non. C’est ce qu’expliquait sur son blog Greg Kroah-Hartman, mainteneur principal des branches stables du noyau, en février dernier. De même, aucun score CVSS n’est produit, et pour cause : les développeurs du noyau ne connaissent pas l’usage fait de Linux, donc dans quel type d’environnement le code sera exécuté.

En revanche, là où un CVE traditionnel décrit un comportement de haut niveau, un CVE Linux correspond directement à un identifiant de commit Git. Ce suivi automatisé explique pourquoi l’utilisation massive de fuzzers et d’outils d’analyse statique génère des pics soudains de plusieurs centaines de CVE.

Mais alors, où est le problème ?

Si la publication de 432 CVE est en soi inédite, ils correspondent donc à des bugs déjà corrigés. Pourtant Jan Schaumann, architecte en chef de la sécurité de l’information chez Akamai Technologies, s’en est plaint sur la liste de diffusion OSS-SEC. Il y exprime son inquiétude devant un tel volume, demandant comment les entreprises, et de manière générale les environnements de production, peuvent suivre un tel rythme.

Mais en quoi est-ce un problème ? Si les failles sont déjà corrigées, ne suffit-il pas d’attendre sagement la prochaine révision du noyau ? Ce n’est pas si simple.

Plusieurs éléments doivent être considérés. D’un côté, les corrections intégrées aux branches stables signifient que toutes les versions actuellement supportées du noyau Linux vont les répercuter. En théorie, il suffirait d’installer la version suivante dans la branche utilisée, par exemple la 7.2 si l’on utilise une distribution évoluant avec les versions les plus récentes. De l’autre, les environnements de production utilisent souvent des versions modifiées, voire d’anciennes versions dans lesquelles les équipes « backportent » (rétroportent) les modifications qui les intéressent.

C’est là que survient le problème dont se plaint Jan Schaumann : quand 432 CVE sont publiés en 24 heures, comment savoir ce qui est important et doit être rétroporté ? Dans un courrier envoyé à The Register, il évoque la possibilité de faire travailler des LLM pour gérer automatiquement le flux. « Des mises à jour automatisées, régulières et fréquentes qui intègrent tous les changements dans un délai donné me semblent la seule approche raisonnable, mais cela est très difficile pour de nombreuses grandes organisations », explique-t-il ainsi.

Le dernier noyau disponible, toujours

Sur la liste de diffusion OSS-SEC, la discussion présente des réponses intéressantes, notamment celle de Greg Kroah-Hartman en personne. Bien qu’il ne réagisse pas directement au message initial, les solutions envisagées par d’autres sont passées en revue, et il donne nettement sa préférence : toujours utiliser le dernier noyau stable disponible sur la branche souhaitée et vérifier régulièrement l’ensemble des systèmes gérés.

Kroah-Hartman reconnait que ce n’est pas toujours simple au sein des entreprises, mais que des produits payants permettent de gérer efficacement ce processus. Si payer un tel produit n’est pas possible, il recommande d’installer des distributions comme Debian ou Yocto, car « leurs pratiques de sécurité sont extraordinaires ». Les autres solutions représentent plus de travail ou une sécurité moindre. Vérifier un par un les CVE pour ne considérer que ceux importants dans l’infrastructure ? On peut le faire de manière automatisée pour vérifier ce qui ressort à l’intersection des fichiers visés par les CVE et des fichiers réellement utilisés dans l’environnement géré. Mais on en revient à la proposition de Jan Schaumann, et toutes les organisations ne peuvent pas se permettre un tel pipeline de gestion.

En d’autres termes, la meilleure solution reste la répercussion des nouveaux noyaux quand ils deviennent disponibles, mais l’explosion du nombre de CVE – très probablement portée par l’utilisation croissante des LLM – rend la lecture plus complexe. Pour Greg Kroah-Hartman cependant, il n’y a pas vraiment de problème : les 432 CVE étaient en préparation depuis des semaines, personne ne devrait être surpris.

Il existe de nombreuses méthodes de sécurité pour se connecter à son compte Google, mais la loi de Murphy étant universelle et intangible, il peut arriver que tout se passe mal et qu’aucune ne fonctionne. Le moteur de recherche en a donc ajouté une nouvelle qui ne devrait plus se perdre au fin fond d’un gestionnaire de mots de passe : le visage.

Google est en train de déployer une fonction de selfie vidéo pour récupérer son compte. Il faudra au préalable enregistrer un selfie vidéo, en suivant les indications de mouvements de tête de l’application. En cas de problème de connexion au compte, l’app peut proposer de réaliser un selfie, qui sera comparé à celui déjà enregistré. Une fois l’identité vérifiée, l’accès sera rétabli.

Évidemment, cette nouvelle méthode pose quelques questions de confidentialité, ce d’autant que le selfie vidéo original est stocké sur les serveurs de Google. L’entreprise se veut rassurante : les données sont enregistrées « de manière sécurisée » (elles sont chiffrées au repos) et avec le consentement de l’utilisateur. La vidéo ne sert que pour l’aide à la connexion, et il est possible de la supprimer à tout moment depuis le compte Google.

Autre inquiétude très concrète : les tentatives d’usurpation d’identité. Des malandrins pourraient en effet être tentés d’utiliser de fausses photos ou vidéos pour se connecter subrepticement dans le compte Google d’une victime. On n’ose imaginer les dégâts possibles, puisque ces comptes contiennent une bonne partie de la vie des utilisateurs…

Plusieurs niveaux de sécurité sont appliqués pour prévenir ces tentatives. « Nous comparons votre vidéo à celle que vous avez enregistrée et vous demandons d’effectuer quelques mouvements simples afin de vérifier qu’il s’agit bien d’une captation en direct », explique Google. Des « mesures de sécurité habituelles » sont également mises en œuvre pour détecter et bloquer les connexions suspectes.

Les plus suspicieux se contenteront des méthodes de connexion existantes, que ce soit une passkey ou un système de validation à deux étapes, comme le code d’une app d’authentification, une clé de sécurité physique ou une invite Google sur un téléphone déjà connecté. Il y a aussi le code reçu par SMS, mais cette méthode n’est pas spécialement sécurisée.

• Mots de passe, double authentification : grrrrr… il est temps d’agir !

Il existe de nombreuses méthodes de sécurité pour se connecter à son compte Google, mais la loi de Murphy étant universelle et intangible, il peut arriver que tout se passe mal et qu’aucune ne fonctionne. Le moteur de recherche en a donc ajouté une nouvelle qui ne devrait plus se perdre au fin fond d’un gestionnaire de mots de passe : le visage.

Google est en train de déployer une fonction de selfie vidéo pour récupérer son compte. Il faudra au préalable enregistrer un selfie vidéo, en suivant les indications de mouvements de tête de l’application. En cas de problème de connexion au compte, l’app peut proposer de réaliser un selfie, qui sera comparé à celui déjà enregistré. Une fois l’identité vérifiée, l’accès sera rétabli.

Évidemment, cette nouvelle méthode pose quelques questions de confidentialité, ce d’autant que le selfie vidéo original est stocké sur les serveurs de Google. L’entreprise se veut rassurante : les données sont enregistrées « de manière sécurisée » (elles sont chiffrées au repos) et avec le consentement de l’utilisateur. La vidéo ne sert que pour l’aide à la connexion, et il est possible de la supprimer à tout moment depuis le compte Google.

Autre inquiétude très concrète : les tentatives d’usurpation d’identité. Des malandrins pourraient en effet être tentés d’utiliser de fausses photos ou vidéos pour se connecter subrepticement dans le compte Google d’une victime. On n’ose imaginer les dégâts possibles, puisque ces comptes contiennent une bonne partie de la vie des utilisateurs…

Plusieurs niveaux de sécurité sont appliqués pour prévenir ces tentatives. « Nous comparons votre vidéo à celle que vous avez enregistrée et vous demandons d’effectuer quelques mouvements simples afin de vérifier qu’il s’agit bien d’une captation en direct », explique Google. Des « mesures de sécurité habituelles » sont également mises en œuvre pour détecter et bloquer les connexions suspectes.

Les plus suspicieux se contenteront des méthodes de connexion existantes, que ce soit une passkey ou un système de validation à deux étapes, comme le code d’une app d’authentification, une clé de sécurité physique ou une invite Google sur un téléphone déjà connecté. Il y a aussi le code reçu par SMS, mais cette méthode n’est pas spécialement sécurisée.

• Mots de passe, double authentification : grrrrr… il est temps d’agir !

Depuis le durcissement, le 20 juillet, des contrôles de sécurité dans le métro de Shenzhen, des files d’attente longues de plusieurs centaines de mètres sont apparues devant une dizaine de grandes stations. De quoi provoquer des critiques contre le discours officiel du “tout pour le peuple” prôné par les autorités, et même des appels à supprimer ces contrôles dans l’ensemble des métros du pays.

© PHOTO ZHANG KAIYV