Le gestionnaire de mots de passe 1Password ajoute une nouvelle corde à son arc. Dans un billet publié le 22 octobre, l’entreprise a présenté une nouvelle plateforme baptisée « 1Password for Agents » pour fluidifier l’utilisation des identifiants stockés dans la base, mais sans les voir.

Dans le scénario décrit par 1Password, un agent arrive sur un formulaire de connexion. Il interroge alors le gestionnaire de mots de passe, déclenchant une demande d’approbation par l’utilisation. Si ce dernier confirme, 1Password remplit lui-même les champs d’identifiants, l’agent n’ayant pas accès à ces informations.

Pour réaliser l’opération, l’agent s’authentifie auprès de 1Password via une clé unique propre. Quand la connexion est faite, le gestionnaire supprime l’identifiant de la page pour que l’agent ne puisse jamais le voir ou le réutiliser. Dans le cas où plusieurs identifiants correspondent à un même formulaire, l’utilisateur est invité à choisir l’agent à utiliser. Ce dernier n’accède pas non plus au reste du coffre.

Ce mécanisme est clairement une évolution du complément 1Password for Claude lancé en juillet. Cette fois cependant, il s’agit d’une plateforme disposant d’intégrations pour Muse de Meta, Claude Duet d’Anthropic, ChatGPT Work et Dots d’OpenAI, Grok Bot de SpaceXSI (anciennement SpaceXAI, encore plus anciennement xAI) et Townie de Town. Selon les cas, la compatibilité est en cours de déploiement ou doit arriver « bientôt ». 1Password prévoit également l’intégration dans Instinct, Browserbase, Browser Use, Dana, KERNEL, Perplexity, Ramp, Tomo et Wajo.

1Password prévient toutefois que ce mécanisme ne sert qu’à protéger les identifiants, pas à contrôler l’agent lui-même. L’entreprise ne peut pas agir sur ce que l’agent fera avec ces identifiants, mais le problème était exactement le même en entrant manuellement les mots de passe pour réaliser une opération.

Le gestionnaire de mots de passe 1Password ajoute une nouvelle corde à son arc. Dans un billet publié le 22 octobre, l’entreprise a présenté une nouvelle plateforme baptisée « 1Password for Agents » pour fluidifier l’utilisation des identifiants stockés dans la base, mais sans les voir.

Dans le scénario décrit par 1Password, un agent arrive sur un formulaire de connexion. Il interroge alors le gestionnaire de mots de passe, déclenchant une demande d’approbation par l’utilisation. Si ce dernier confirme, 1Password remplit lui-même les champs d’identifiants, l’agent n’ayant pas accès à ces informations.

Pour réaliser l’opération, l’agent s’authentifie auprès de 1Password via une clé unique propre. Quand la connexion est faite, le gestionnaire supprime l’identifiant de la page pour que l’agent ne puisse jamais le voir ou le réutiliser. Dans le cas où plusieurs identifiants correspondent à un même formulaire, l’utilisateur est invité à choisir l’agent à utiliser. Ce dernier n’accède pas non plus au reste du coffre.

Ce mécanisme est clairement une évolution du complément 1Password for Claude lancé en juillet. Cette fois cependant, il s’agit d’une plateforme disposant d’intégrations pour Muse de Meta, Claude Duet d’Anthropic, ChatGPT Work et Dots d’OpenAI, Grok Bot de SpaceXSI (anciennement SpaceXAI, encore plus anciennement xAI) et Townie de Town. Selon les cas, la compatibilité est en cours de déploiement ou doit arriver « bientôt ». 1Password prévoit également l’intégration dans Instinct, Browserbase, Browser Use, Dana, KERNEL, Perplexity, Ramp, Tomo et Wajo.

1Password prévient toutefois que ce mécanisme ne sert qu’à protéger les identifiants, pas à contrôler l’agent lui-même. L’entreprise ne peut pas agir sur ce que l’agent fera avec ces identifiants, mais le problème était exactement le même en entrant manuellement les mots de passe pour réaliser une opération.

Ah bah y'a encore des adminsys qui vont passer quelques heures sympa... 😕
(Permalink)

Oups ?

La Zero Day Initiative de Trend Micro a envoyé six rapports de failles de sécurité sur des listes de diffusion publiques du noyau Linux, avec de nombreux détails. Le caractère accidentel de ces publications est contesté. Le danger, bien que limité, est réel pour certaines configurations.

Les 21 et 22 octobre, six rapports de vulnérabilités ont été envoyés par Trend Micro sur des listes publiques rattachées au développement du noyau public. Plus précisément, ces rapports ont été adressés à la liste de sécurité privée du noyau, mais les listes publiques linux-kernel, linux-cifs, netdev et dri-devel figuraient en copie. Les détails techniques, avec les chemins de code et les traces KASAN, sont depuis publics alors qu’aucun correctif n’est encore publié.

Six vulnérabilités, dont deux critiques

Parmi les rapports, deux concernent des failles critiques dans ksmbd. La première, estampillée par Trend Micro ZDI-CAN-33774, réside dans une situation de compétition dans l’affectation de la table de traitement. Si l’on envoie une rafale de paquets SMB1 courts suivie d’un paquet SMB2 dans la même écriture TCP, les processus de travail traitent alors les données SMB1 avec un gestionnaire SMB2, qui va lire au-delà de la mémoire tampon. Une écriture hors limites devient ainsi possible, à condition que le pirate ait accès à un partage, mais aucune autorisation n’est nécessaire, expliquant le score CVSS de 9 sur 10.

L’autre faille, ZDI-CAN-33549, est un dépassement par le bas d’un entier (integer underflow) dans le chemin SMB Direct de ksmbd. Un client peut envoyer des descripteurs de tampon RDMA dont le premier est plus long que la charge annoncée. Le compteur de taille du serveur repasse alors par zéro et une copie mémoire déborde ensuite du tampon alloué. Pour l’exploitation en revanche, il faut réunir trois conditions : une interface compatible RDMA (matérielle ou le pilote logiciel rxe), un partage ksmbd accessible en écriture et un client qui négocie SMB Direct. À noter cependant que le support de SMB Direct est une option, désactivée par défaut. Le score CVSS est quand même de 9, confirmant la criticité de la brèche.

Ces notes sont attribuées via CVSS 3.1, le caractère critique débutant à 9. Trois autres failles – ZDI-CAN-33367, ZDI-CAN-34068 et ZDI-CAN-34076 – sont tout de même dans la tranche élevée, avec des notes comprises entre 7,8 et 8,8. Elles concernent respectivement une élévation locale de privilèges dans skb_zerocopy (réseau), une élévation locale de privilèges dans le pilote de GPU virtuel vmwgfx (VMware) et une divulgation d’informations dans nvmet (un pilote NVMe). La sixième faille, ZDI-CAN-32005, est un dépassement de pile (stack overflow) dans ConnMan, mais aucun score CVSS n’est rattaché.

Bien que le danger soit limité à certaines configurations spécifiques (ksmbd est un serveur compatible Samba mais n’est pas Samba), il est réel. Dans le contexte de publication de ces failles, il est probable qu’aucun correctif ne sera disponible avant plusieurs semaines.

Accident ou respect des nouvelles règles du noyau ?

Phoronix est le premier site à s’être rendu compte de ces publications. Pour nos confrères, il s’agissait clairement d’une bourde importante. D’ailleurs, Greg Kroah-Hartman en personne, le mainteneur principal du noyau Linux, s’est étonné et agacé dans des réponses à ces publications. Sur le pilote GPU VMware par exemple, il a répondu : « Pour une raison quelconque, vous avez envoyé cela dans des listes publiques, sans correctif, donc nous ne pouvons pas faire grand-chose avec ça ». L’agacement est monté d’un cran sur le rapport du pilote NMVe : « Encore une fois, pas de correctif, et envoyé sur une liste publique ? Merci de corriger votre processus de soumission… ».

Mais en dépit de ces réponses, certains médias s’interrogent : s’agissait-il vraiment d’un accident ? Cyber Kendra note ainsi que les rapports attribuent clairement la découverte des failles à TrendAI, le scanner IA de vulnérabilités de Trend Micro. Or, selon la documentation sur les failles de sécurité dans le noyau, réécrite et fusionnée pour le noyau Linux 7.1, indique que toute vulnérabilité trouvée grâce à l’IA doit être considérée comme publique et envoyée aux mainteneurs concernés plutôt que sur la liste privée.

Nos confrères rappellent que cette règle est une conséquence directe de l’agacement de Linus Torvalds sur le caractère « presque totalement ingérable » de la liste privée de sécurité depuis l’émergence des outils IA. Mais selon ces mêmes directives, les découvreurs de failles doivent joindre des correctifs ou des analyses d’impact. Les rapports de Trend Micro ne contenaient ni l’un ni l’autre, expliquant en partie l’agacement de Greg Kroah-Hartman.

The Hacker News évoque les mêmes règles et ne mentionne d’ailleurs jamais le caractère éventuellement accidentel de ces publications.

Nous avons contacté Trend Micro et mettrons à jour cette actualité si nous obtenons une réponse.

Oups ?

La Zero Day Initiative de Trend Micro a envoyé six rapports de failles de sécurité sur des listes de diffusion publiques du noyau Linux, avec de nombreux détails. Le caractère accidentel de ces publications est contesté. Le danger, bien que limité, est réel pour certaines configurations.

Les 21 et 22 octobre, six rapports de vulnérabilités ont été envoyés par Trend Micro sur des listes publiques rattachées au développement du noyau public. Plus précisément, ces rapports ont été adressés à la liste de sécurité privée du noyau, mais les listes publiques linux-kernel, linux-cifs, netdev et dri-devel figuraient en copie. Les détails techniques, avec les chemins de code et les traces KASAN, sont depuis publics alors qu’aucun correctif n’est encore publié.

Six vulnérabilités, dont deux critiques

Parmi les rapports, deux concernent des failles critiques dans ksmbd. La première, estampillée par Trend Micro ZDI-CAN-33774, réside dans une situation de compétition dans l’affectation de la table de traitement. Si l’on envoie une rafale de paquets SMB1 courts suivie d’un paquet SMB2 dans la même écriture TCP, les processus de travail traitent alors les données SMB1 avec un gestionnaire SMB2, qui va lire au-delà de la mémoire tampon. Une écriture hors limites devient ainsi possible, à condition que le pirate ait accès à un partage, mais aucune autorisation n’est nécessaire, expliquant le score CVSS de 9 sur 10.

L’autre faille, ZDI-CAN-33549, est un dépassement par le bas d’un entier (integer underflow) dans le chemin SMB Direct de ksmbd. Un client peut envoyer des descripteurs de tampon RDMA dont le premier est plus long que la charge annoncée. Le compteur de taille du serveur repasse alors par zéro et une copie mémoire déborde ensuite du tampon alloué. Pour l’exploitation en revanche, il faut réunir trois conditions : une interface compatible RDMA (matérielle ou le pilote logiciel rxe), un partage ksmbd accessible en écriture et un client qui négocie SMB Direct. À noter cependant que le support de SMB Direct est une option, désactivée par défaut. Le score CVSS est quand même de 9, confirmant la criticité de la brèche.

Ces notes sont attribuées via CVSS 3.1, le caractère critique débutant à 9. Trois autres failles – ZDI-CAN-33367, ZDI-CAN-34068 et ZDI-CAN-34076 – sont tout de même dans la tranche élevée, avec des notes comprises entre 7,8 et 8,8. Elles concernent respectivement une élévation locale de privilèges dans skb_zerocopy (réseau), une élévation locale de privilèges dans le pilote de GPU virtuel vmwgfx (VMware) et une divulgation d’informations dans nvmet (un pilote NVMe). La sixième faille, ZDI-CAN-32005, est un dépassement de pile (stack overflow) dans ConnMan, mais aucun score CVSS n’est rattaché.

Bien que le danger soit limité à certaines configurations spécifiques (ksmbd est un serveur compatible Samba mais n’est pas Samba), il est réel. Dans le contexte de publication de ces failles, il est probable qu’aucun correctif ne sera disponible avant plusieurs semaines.

Accident ou respect des nouvelles règles du noyau ?

Phoronix est le premier site à s’être rendu compte de ces publications. Pour nos confrères, il s’agissait clairement d’une bourde importante. D’ailleurs, Greg Kroah-Hartman en personne, le mainteneur principal du noyau Linux, s’est étonné et agacé dans des réponses à ces publications. Sur le pilote GPU VMware par exemple, il a répondu : « Pour une raison quelconque, vous avez envoyé cela dans des listes publiques, sans correctif, donc nous ne pouvons pas faire grand-chose avec ça ». L’agacement est monté d’un cran sur le rapport du pilote NMVe : « Encore une fois, pas de correctif, et envoyé sur une liste publique ? Merci de corriger votre processus de soumission… ».

Mais en dépit de ces réponses, certains médias s’interrogent : s’agissait-il vraiment d’un accident ? Cyber Kendra note ainsi que les rapports attribuent clairement la découverte des failles à TrendAI, le scanner IA de vulnérabilités de Trend Micro. Or, selon la documentation sur les failles de sécurité dans le noyau, réécrite et fusionnée pour le noyau Linux 7.1, indique que toute vulnérabilité trouvée grâce à l’IA doit être considérée comme publique et envoyée aux mainteneurs concernés plutôt que sur la liste privée.

Nos confrères rappellent que cette règle est une conséquence directe de l’agacement de Linus Torvalds sur le caractère « presque totalement ingérable » de la liste privée de sécurité depuis l’émergence des outils IA. Mais selon ces mêmes directives, les découvreurs de failles doivent joindre des correctifs ou des analyses d’impact. Les rapports de Trend Micro ne contenaient ni l’un ni l’autre, expliquant en partie l’agacement de Greg Kroah-Hartman.

The Hacker News évoque les mêmes règles et ne mentionne d’ailleurs jamais le caractère éventuellement accidentel de ces publications.

Nous avons contacté Trend Micro et mettrons à jour cette actualité si nous obtenons une réponse.

Jason Clinton, RSSI adjoint d'Anthropic, a prévenu que la crise ouverte par les failles critiques de PHP allait encore empirer, pendant environ 18 mois. Il annonçait déjà ce « tsunami » de vulnérabilités trouvées par l'IA au mois d'août.

Le patch pour la faille php n'est disponible que pour les versions ultérieures à php 8.1.
Un développeur - Sury - s'est fait chier à backporter les correctifs dans php 8.1, 7 et même 5. C'est déjà exceptionnel pour un correctif d'une telle taille (plus de 13000 lignes de code, si j'ai bien lu.)
Sury a donc fourni des paquets pour Debian 13... jusqu'à 11.

Pour aider plus de clients à se protéger contre la faille, mon hébergeur (ScalarX) a backporté les paquets pour Debian 9 et 10... et fournit gratuitement les dépôts au public.

Il y a vraiment des gens qui dépensent beaucoup d'énergie pour que les autres soient en sécurité.

Chapeau bas à Christophe et son équipe. 😎
(Permalink)

C'est la faute des réseaux sociaux !

eMudhra jette l’éponge : l’entreprise indienne a décidé de mettre « volontairement » un terme à son activité de certification SSL/TLS, après la découverte de son incroyable défaillance cette semaine.

Pointé du doigt et parfois moqué par une bonne partie de la planète tech depuis quelques jours, eMudhra a annoncé ce jeudi 22 octobre son retrait du marché des certificats HTTPS (PDF). Huit clés de chiffrement avaient été très mal générées par l’autorité de certification indienne : leurs valeurs tenaient sur 8 bits, alors qu’elles auraient dû l’être sur 384 bits (48 octets). Une clé portait ainsi le numéro… 4. Juste 4.

• Certificats TLS : n’importe qui pouvait certifier un site via des clés passoires

Une image de marque en miettes

eMudhra s’est défendue en parlant d’« erreurs humaines » à plusieurs étapes du processus. Des erreurs qui permettaient à n’importe qui de générer de faux certificats HTTPS pour des domaines qu’il ne contrôlait pas, permettant ainsi d’usurper un site légitime. Les navigateurs web ont été mis à jour très rapidement pour refuser les certificats générés à partir de ces clés, mais pas forcément certains services en ligne, applications ou objets connectés qui n’y voient que du feu faute de mise à jour.

L’entreprise assure avoir « traité cet incident avec diligence, révoquant les autorités de certification concernées dans les 14 heures suivant sa découverte et le signalant rapidement ». Elle rappelle qu’« aucun certificat destiné à un utilisateur final n’avait été émis par les autorités de certification concernées », que son infrastructure « n’a pas été compromise et aucune donnée n’a été dérobée ».

Alors, tout va bien ? Pas vraiment. Les exigences de souveraineté des données et de conformité rendent cette activé SSL/TLS « de plus en plus complexe et coûteuse au fil des années » alors que d’autres grands acteurs délivrent gratuitement ces certificats. Pour eMudhra, le potentiel commercial et le retour sur investissement ont « considérablement diminué », alors que ce business ne représente que 1 % de son chiffre d’affaires mondial. Un poids faible donc, mais il n’empêche que la défaillance fait courir de sérieux risques aux internautes.

Pour justifier son retrait, eMudhra n’avance pas que l’argument économique. L’autorité vide son sac, et il est lourd : « l’amplification de cet incident sur les réseaux sociaux a suscité une attention disproportionnée par rapport à la place du SSL/TLS dans nos activités ». La réputation du groupe en a pris un coup. Par conséquent, « nous consacrerons nos efforts aux domaines dans lesquels nous créons le plus de valeur pour nos clients, en nous recentrant sur nos principales solutions pour les entreprises et sur les services de confiance autres que le SSL/TLS. »

Les clients d’eMudhra se verront proposer le remplacement gratuit de leurs certificats par des certificats fournis par des partenaires. L’entreprise s’engage à maintenir le bon fonctionnement des services de révocation et de vérification du statut des certificats jusqu’à ce qu’ils aient expiré ou remplacés. Elle promet aussi un rapport détaillé sur l’incident.

• 21 octobre 2026 : retour en détail sur cette journée noire pour la cybersécurité

C'est la faute des réseaux sociaux !

eMudhra jette l’éponge : l’entreprise indienne a décidé de mettre « volontairement » un terme à son activité de certification SSL/TLS, après la découverte de son incroyable défaillance cette semaine.

Pointé du doigt et parfois moqué par une bonne partie de la planète tech depuis quelques jours, eMudhra a annoncé ce jeudi 22 octobre son retrait du marché des certificats HTTPS (PDF). Huit clés de chiffrement avaient été très mal générées par l’autorité de certification indienne : leurs valeurs tenaient sur 8 bits, alors qu’elles auraient dû l’être sur 384 bits (48 octets). Une clé portait ainsi le numéro… 4. Juste 4.

• Certificats TLS : n’importe qui pouvait certifier un site via des clés passoires

Une image de marque en miettes

eMudhra s’est défendue en parlant d’« erreurs humaines » à plusieurs étapes du processus. Des erreurs qui permettaient à n’importe qui de générer de faux certificats HTTPS pour des domaines qu’il ne contrôlait pas, permettant ainsi d’usurper un site légitime. Les navigateurs web ont été mis à jour très rapidement pour refuser les certificats générés à partir de ces clés, mais pas forcément certains services en ligne, applications ou objets connectés qui n’y voient que du feu faute de mise à jour.

L’entreprise assure avoir « traité cet incident avec diligence, révoquant les autorités de certification concernées dans les 14 heures suivant sa découverte et le signalant rapidement ». Elle rappelle qu’« aucun certificat destiné à un utilisateur final n’avait été émis par les autorités de certification concernées », que son infrastructure « n’a pas été compromise et aucune donnée n’a été dérobée ».

Alors, tout va bien ? Pas vraiment. Les exigences de souveraineté des données et de conformité rendent cette activé SSL/TLS « de plus en plus complexe et coûteuse au fil des années » alors que d’autres grands acteurs délivrent gratuitement ces certificats. Pour eMudhra, le potentiel commercial et le retour sur investissement ont « considérablement diminué », alors que ce business ne représente que 1 % de son chiffre d’affaires mondial. Un poids faible donc, mais il n’empêche que la défaillance fait courir de sérieux risques aux internautes.

Pour justifier son retrait, eMudhra n’avance pas que l’argument économique. L’autorité vide son sac, et il est lourd : « l’amplification de cet incident sur les réseaux sociaux a suscité une attention disproportionnée par rapport à la place du SSL/TLS dans nos activités ». La réputation du groupe en a pris un coup. Par conséquent, « nous consacrerons nos efforts aux domaines dans lesquels nous créons le plus de valeur pour nos clients, en nous recentrant sur nos principales solutions pour les entreprises et sur les services de confiance autres que le SSL/TLS. »

Les clients d’eMudhra se verront proposer le remplacement gratuit de leurs certificats par des certificats fournis par des partenaires. L’entreprise s’engage à maintenir le bon fonctionnement des services de révocation et de vérification du statut des certificats jusqu’à ce qu’ils aient expiré ou remplacés. Elle promet aussi un rapport détaillé sur l’incident.

• 21 octobre 2026 : retour en détail sur cette journée noire pour la cybersécurité