Les litiges du Ledger contestent l'affirmation de OneKey concernant un « piratage » lié à un bug reproduit dans l'application Ethereum

Ledger conteste les allégations de « piratage » après que OneKey a reproduit une faille de remplacement de transaction dans l'ancienne application Ethereum Ledger a réagi après que l'équipe de sécurité Anzen de OneKey a affirmé avoir « piraté Ledger » en reproduisant une faille de remplacement de transaction sur une ancienne application Ethereum. Ledger reconnaît que la vulnérabilité était réelle, mais affirme qu'elle avait déjà été corrigée avant la démonstration publique de OneKey. Ce qui s'est passé - Le 27 août, Yishi Wang, fondateur de OneKey, a tweeté que son équipe avait réussi à reproduire une attaque de remplacement de transaction contre la version 1.22.1 de l'application Ethereum de Ledger dans un environnement de laboratoire. Il a décrit le problème comme une condition de course entre l'affichage de la transaction et le tampon de transaction sous-jacent. - Ledger a reconnu la vulnérabilité sous-jacente, mais a souligné que l'entreprise avait corrigé la faille avant la publication de la démonstration par OneKey. Charles Guillemet, CTO de Ledger, a déclaré : « Reproduire une faille déjà corrigée n'est pas un 'piratage de Ledger' », qualifiant le travail de OneKey d'exercice de laboratoire sur une ancienne application. Comment la faille fonctionnait (en termes simples) - Les applications Ledger reçoivent des instructions appelées APDU (Commandes Application Protocol Data Unit) provenant de logiciels wallet, de pages web ou d'autres interfaces hôtes. - Dans les versions affectées, une deuxième APDU pouvait être acceptée tandis que l'utilisateur examinait encore une transaction sur l'écran de l'appareil. Cette deuxième commande pouvait remplacer les paramètres de signature en mémoire partagée sans modifier ce qui était affiché sur l'appareil. - Résultat : un utilisateur pouvait examiner et approuver la transaction A sur l'appareil, tandis que la clé sécurisée signait en réalité la transaction B — et l'appareil ne signalait pas à l'utilisateur que les données de signature sous-jacentes avaient changé. - Ledger a classé cela comme une condition de course Time-of-Check to Time-of-Use (TOCTOU) qui contournait les protections d'affichage fiable sur lesquelles les wallets matériels s'appuient pour permettre aux utilisateurs de vérifier les montants, les adresses et les actions contractuelles. Ce qui était et n'était pas en danger - La faille n'a pas exposé les phrases secrètes ni extrait les clés privées du module sécurisé. Elle pouvait simplement amener une clé protégée à signer des entrées différentes de celles affichées à l'utilisateur. - Un attaquant devait avoir le contrôle du canal de communication entre l'application Ledger et son hôte — par exemple, un logiciel malveillant sur l'hôte, une application wallet compromise ou une page web hostile avec accès WebHID/WebUSB. L'attaque ne pouvait pas être exécutée à distance contre un appareil débranché. - Une exploitation réussie nécessitait également que l'utilisateur approuve une transaction pendant que le logiciel malveillant manipulait le contexte de signature en attente. Où se trouvait la faille et comment elle a été corrigée - Ledger affirme que le défaut se trouvait dans la gestion des entrées/sorties de son Secure SDK, et non dans le système d'exploitation ou le firmware de l'appareil. Les applications construites avec les versions affectées du SDK reposaient sur leurs propres vérifications d'état pour rejeter les commandes intercalées. - En conséquence, l'exposition était spécifique à l'application : une application restait sécurisée si chaque point d'entrée asynchrone vérifiait correctement l'état, même lorsqu'elle était construite avec le SDK affecté. - Chronologie des correctifs : - 13 août : L'application Ethereum 1.22.2 a ajouté des vérifications d'état au niveau de l'application qui bloquent le chemin de substitution de transaction documenté. - 21 août : Ledger a publié le Secure SDK 26.6.1, qui bloque les commandes intercalées avant qu'elles n'atteignent le code de l'application. Les applications ont ensuite été recompilées avec le SDK corrigé. - Ledger recommande désormais l'application Ethereum 1.22.3 ou ultérieure, car elle inclut la protection plus large du SDK et corrige une faille supplémentaire d'affichage de transaction. OneKey avait raison : la version 1.22.3 est protégée, mais la première mitigation au niveau application est apparue dans la version 1.22.2. Conseils pratiques pour les utilisateurs et les développeurs - Ledger n'a trouvé aucune preuve que des attaquants ont exploité cette faille (identifiée comme LSB-023), et aucune perte crypto n'a été publiquement liée à cette vulnérabilité spécifique. - Les utilisateurs doivent ouvrir Ledger Live, installer les dernières applications pour leur appareil et vérifier la version de l'application Ethereum sur leur wallet matériel. Installer une mise à jour du firmware seul ne remplace pas les applications construites avec un SDK affecté — les applications doivent également être mises à jour. - Les développeurs d'applications tierces doivent revoir leur gestion d'état et recompiler leurs applications avec le Secure SDK 26.6.1 ou ultérieur. Ledger indique que cette faiblesse a été introduite en août 2025 et a affecté les versions du SDK jusqu'à la 26.6.0. Contexte plus large - Cette divulgation fait suite à une série de correctifs pour wallets matériels ; par exemple, BitBox a récemment corrigé deux vulnérabilités affectant l'installation du firmware et la gestion des adresses Bitcoin, sans preuve d'exploitation confirmée. Conclusion La faille technique démontrée par OneKey était réelle mais limitée dans son champ d'action : elle nécessitait un hôte compromis et l'approbation de l'utilisateur, et Ledger affirme avoir corrigé le problème avant que la démonstration ne soit rendue publique. Les utilisateurs doivent mettre à jour leurs applications via Ledger Live, et les développeurs doivent recompiler avec le SDK corrigé pour fermer la fenêtre d'exposition.