La populaire newsletter Bitcoin OpTech a créé un Hall of Fame pour remercier les développeurs qui ont divulgué de manière responsable les principales vulnérabilités du logiciel Bitcoin sans les exploiter à leur propre avantage. La liste fournit plus de quatre ans d’histoire d’épisodes où Bitcoin a failli échouer.
Bitcoin OpTech développe des technologies open source pour les entreprises intéressées par l’utilisation du bitcoin. Il émet systématiquement divulgations responsables sur les vulnérabilités logicielles afin que les développeurs puissent travailler dessus. La société est surtout connue pour sa newsletter, un résumé hebdomadaire des e-mails qui couvre les actualités techniques sur Bitcoin et les logiciels associés.
Maintenant, il maintient une liste de certains des bogues les plus importants pour lesquels il a reçu des rapports. Beaucoup d’entre eux étaient de graves vulnérabilités de Bitcoin qu’un attaquant aurait pu utiliser pour causer des dommages importants à des parties importantes de l’infrastructure de Bitcoin, comme Bitcoin Core ou le Lightning Network.
Sommaire
Vulnérabilités Bitcoin : Bloquer le bogue d’analyse dans LND et BTCD
Bitcoin Optech Newsletter #222 a signalé un bogue d’analyse de bloc dans LND et BTCD détecté par Burak qui passe brqgoo. Il a envoyé une transaction multi-signature Taproot tapscript 998 sur 999 qui a cassé une bibliothèque d’analyse utilisée par BTCD et LND. Le bogue a été divulgué le 9 novembre 2022.
Les règles de consensus de Taproot ne limitaient pas la taille des données témoins envoyées dans une transaction. Les utilisateurs ont rapidement signalé que le nœud complet BTCD et LND Lightning Network implémentations n’a pas réussi à transférer les données des blocs récents. Un développeur a résolu le problème avec une nouvelle version du code de BTCD.
Lire la suite: Un bug gèle le bitcoin à l’intérieur Lightning Network Pendant des heures
Vulnérabilité de sécurité détectée dans Lightning Network sorties d’ancre
Bastien Teinturier a informé les destinataires de la liste de diffusion Lightning-Dev d’un problème de sécurité affectant les anciennes versions de Core Lightning avec des fonctionnalités expérimentales et LND.
Une conception plus récente des sorties d’ancre LN a permis aux parties de combiner plusieurs sorties HTLC révoquées en une seule transaction. Cette conception comportait un défaut qui pouvait permettre à une partie ayant émis un HTLC révoqué de voler des fonds non réclamés lorsqu’un timelock HTLC a expiré.
Il l’avait précédemment signalé aux responsables de l’implémentation LN et avait recommandé aux utilisateurs d’anciennes versions de Core Lightning d’installer des mises à niveau. Le bogue a été signalé en mai 2021.
Vulnérabilités de script intersite dans BTCPay Server
Ajmal Aboobacker et Abdul Muhaimin ont reçu des primes de divulgation pour avoir informé les développeurs de BTCPay de trois vulnérabilités de script intersite dans BTCPay Server. BTCPay Server 1.2.3 a résolu le problème. Le bogue a été partagé avec le public en septembre 2021.
Écart entre les implémentations BIP125 et Bitcoin Core
Avant cela, Antoine Riard avait signalé une source possible de conflit entre BIP125 et Bitcoin Core qui avait été divulguée en mai 2021. BIP125 autorisait les transactions parentes non confirmées que les expéditeurs pouvaient remplacer par Replace-By-Fee pour rendre toutes les transactions utilisant la sortie des transactions parentes remplaçables par héritage inféré.
Cette fonctionnalité a provoqué un conflit avec Bitcoin Core, qui n’autorisait pas ce comportement. Le conflit pourrait rendre une vulnérabilité LN existante divulguée dans Optech Newsletter #95 moins chère à exploiter.
Acceptation des signatures non standard dans LND
Antoine Riard a révélé une vulnérabilité dans LND en octobre de la même année, qui l’a amené à accepter des signatures de transaction que Bitcoin Core ne pouvait pas relayer ou exploiter par défaut. Lorsque la transaction n’a pas pu être confirmée au niveau du Bitcoin Core, le délai a expiré et l’attaquant a pu voler les fonds.
Attaque par déni de service par manque de mémoire dans l’inventaire
En septembre 2020, Braydon Fuller et Javed Khan ont révélé une vulnérabilité permettant aux attaquants d’inonder les nœuds bitcoin avec des messages d’inventaire (inv) dans une variante de l’attaque par déni de service. Chaque message inv contenait le nombre maximal de hachages de transaction.
Lorsque les nœuds cibles recevaient trop de messages inv, ils pouvaient manque de mémoire et plantage. L’attaque par déni de service pourrait être combinée à une attaque par éclipse pour voler des fonds.
Attaque de rançon des frais LN
En juin 2020, René Pickhardt détecte un Lightning Network vulnérabilité où un expéditeur pourrait prendre des paiements en otage en ne sélectionnant pas un taux de frais approprié lors de l’envoi de paiements.
Même dans le Lightning Network, les attaquants pourraient augmenter les taux de frais en envoyant un grand nombre de transactions « indésirables », ce qui pourrait rendre la structure de frais recommandée plus élevée que le taux de frais sélectionné. L’exploitation de cette vulnérabilité pourrait forcer le destinataire à fermer le canal sans recevoir de paiements ou accepter de régler les HTLC hors chaîne.
Attaques de paiement excessif de frais sur les transactions segwit multi-entrées
Greg Sanders a découvert une vulnérabilité dans le logiciel couramment utilisé pour interagir avec les portefeuilles matériels en juin 2020. Les portefeuilles matériels peuvent fournir un stockage sécurisé des actifs numériques en partie parce que leurs propriétaires ne les laissent généralement pas connectés à un ordinateur qui se connecte à Internet.
Cependant, un attaquant peut pirater l’ordinateur du propriétaire d’un portefeuille matériel et l’utiliser pour prendre le contrôle du logiciel. L’attaquant peut l’utiliser pour inciter le portefeuille matériel à payer trop cher les frais de transaction en interférant avec les algorithmes utilisés pour calculer les montants UTXO.
Seule la vulnérabilité affecte les signataires apatrides comme les portefeuilles matériels qui ne stockent pas les données UTXO et doivent les recalculer chaque fois que leurs propriétaires envoient une transaction.
Bogue de débordement dans l’implémentation bech32 du langage C de référence
Trezor a révélé un bogue dans la fonction de référence pour les implémentations Bech32 écrites dans le langage de programmation C en novembre 2018. Le bogue n’affecte pas les implémentations écrites dans d’autres langages de programmation.
Il a publié un correctif corrigeant le bogue. Ledger a informé Trezor d’un bogue similaire dans l’une des bibliothèques de Trezor pour les adresses Bitcoin Cash. Trezor a également créé un patch pour le réparer.
Bitcoin Optech a corrigé une vulnérabilité de déni de service
L’équipe Bitcoin Optech a corrigé une vulnérabilité de déni de service qu’un attaquant aurait pu utiliser pour tromper les mineurs accepter les transactions bitcoin invalides. Il a recommandé aux mineurs et aux services Bitcoin de mettre à jour leur logiciel pour inclure le correctif ou d’attendre au moins 30 confirmations.
Awemany a initialement signalé le problème. Bitcoin Optech a émis un avertissement concernant cette vulnérabilité le 20 septembre 2018. Selon les détails techniques, le bogue aurait pu permettre au mineur de mettre en place un ensemble précis de conditions dans lesquelles un expéditeur pourrait dépenser deux fois le bitcoin.
Cory Fields a signalé un bogue brisant le consensus dans Bitcoin Cash
Cory Fields a révélé en août de la même année qu’il avait fait un rapport anonyme d’un bogue brisant le consensus dans Bitcoin Cash après une expérience frustrante de signalement du bogue aux développeurs de Bitcoin Cash.
Il a recommandé de le faire plus facile de signaler les vulnérabilités aux projets d’actifs numériques de manière anonyme. Neha Narula a ajouté quelques recommandations aux mainteneurs du projet pour prévenir les bogues potentiellement catastrophiques.
La vulnérabilité des preuves SPV est divulguée publiquement par accident
Une vulnérabilité dans les preuves SPV permet de créer une preuve SPV d’une transaction inexistante en créant une véritable transaction 64 bits qui incite les mineurs à l’inclure dans un bloc. Le créateur de Bitcoin Satoshi Nakamoto a prédit cette faille dans les preuves SPV dans la section 8 du Bitcoin Whitepaper.
Les développeurs pensaient qu’un attaquant utilisant cet exploit le trouverait plus cher qu’il ne vaut. Pour couvrir leurs bases, cependant, ils ont modifié les RPC Bitcoin Core pour effectuer des vérifications supplémentaires qui peuvent atténuer cette vulnérabilité.
Pour des nouvelles plus informées, suivez-nous sur Twitter et Abonnez vous à notre feed ou écoutez notre podcast d’investigation Innové : Blockchain Ville.