Exploiter le Lightning Bug était le choix éthique

Bitcoin peut-il vraiment faire de vous un millionnaire ?

Ceci est un éditorial d’opinion de Shinobi, un éducateur autodidacte dans l’espace Bitcoin et hôte de podcast Bitcoin orienté technologie.

Pour la deuxième fois en environ un mois, btcd/LND ont eu un bogue exploité qui les a fait s’écarter du consensus de Bitcoin Core. Une fois de plus, Burak était le développeur qui a déclenché cette vulnérabilité – cette fois, c’était clairement intentionnel – et encore une fois, c’était un problème avec le code pour analyser les transactions Bitcoin au-dessus de la couche de consensus. Comme je l’ai expliqué dans mon article sur le bogue précédent déclenché par Burak, avant Taproot, il y avait des limites à la taille du script et des données de témoin dans une transaction. Avec l’activation de Taproot, ces limites ont été supprimées, ne laissant que les limitations sur la limite de taille de bloc elle-même pour limiter ces parties de transactions individuelles. Le problème avec le dernier bogue était que malgré le fait que le code de consensus dans btcd ait été correctement mis à jour pour refléter ce changement, le code gérant la transmission peer-to-peer – y compris l’analyse des données avant l’envoi ou lors de la réception – n’a pas été correctement mis à jour. Ainsi, les blocs de traitement de code et les transactions avant qu’ils ne soient effectivement transmis pour être validés pour le consensus ont échoué les données, ne les ont jamais transmises à la logique de validation du consensus et le bloc en question n’a jamais été validé.

Une chose très similaire s’est produite cette fois. Une autre limite dans la section peer-to-peer de la base de code était l’application incorrecte d’une restriction sur les données témoins, en la limitant à un maximum de 1/8 de la taille du bloc par opposition à la taille du bloc complet. Burak a conçu une transaction avec des données témoins juste une seule unité de poids au-dessus de la limite stricte et a de nouveau bloqué les nœuds btcd et LND à cette hauteur de bloc. Cette transaction était une transaction non standard, ce qui signifie que même si elle est parfaitement valide selon les règles de consensus, elle n’est pas valide selon la politique de mempool par défaut et, par conséquent, les nœuds ne la relayeront pas sur le réseau. Il est parfaitement possible de le faire extraire dans un bloc, mais la seule façon de le faire est de le fournir directement à un mineur, ce que Burak a fait avec l’aide de F2Pool.

Cela fait vraiment comprendre que tout morceau de code dont le but est d’analyser et de valider les données Bitcoin doit être fortement audité afin de s’assurer qu’il est conforme à ce que fera Bitcoin Core. Peu importe que ce code soit le moteur de consensus pour une implémentation de nœud ou simplement un morceau de code transmettant des transactions pour un nœud Lightning. Ce deuxième bug était littéralement juste au-dessus de celui du mois dernier dans la base de code. Il n’a même pas été découvert par quiconque à Lightning Labs. AJ Towns l’a signalé le 11 octobre, deux jours après que le bogue d’origine ait été déclenché par la transaction multisig 998-of-999 de Burak. Il a été publié publiquement sur Github pendant 10 heures avant d’être supprimé. Un correctif a ensuite été apporté, mais pas publié, avec l’intention de corriger discrètement le problème dans la prochaine version de LND.

Maintenant, c’est une procédure assez standard pour une vulnérabilité grave, en particulier avec un projet comme Bitcoin Core où une telle vulnérabilité peut en fait causer de graves dommages au réseau/protocole de la couche de base. Mais dans ce cas précis, il présentait un risque sérieux pour les fonds des utilisateurs de LND, et étant donné qu’il était littéralement juste à côté du bogue précédent qui présentait les mêmes risques, les chances qu’il soit trouvé et exploité étaient très élevées, comme l’a démontré Burak. Cela soulève la question de savoir si l’approche du patch silencieux est la voie à suivre lorsqu’il s’agit de vulnérabilités comme celle-ci qui peuvent exposer les utilisateurs au vol de fonds (car leur nœud est incapable de détecter les anciens états de canal et de les pénaliser correctement).

Comme je l’ai expliqué dans mon article sur le dernier bogue, si un acteur malveillant avait trouvé les bogues avant un développeur bien intentionné, il aurait pu ouvrir tactiquement de nouveaux canaux vers des nœuds vulnérables, rediriger l’intégralité du contenu de ces canaux vers lui-même, puis exploité le bogue. À partir de là, ils auraient ces fonds sous leur contrôle et pourraient également fermer le canal avec l’état initial, doublant littéralement leur argent. Ce que Burak a fait en exploitant activement ce problème de manière ironique a en fait protégé les utilisateurs de LND d’une telle attaque.

Une fois exploité, les utilisateurs étaient ouverts à de telles attaques de pairs préexistants avec lesquels ils avaient déjà des canaux ouverts, mais ils n’étaient plus capables d’être ciblés spécifiquement avec de nouveaux canaux. Leurs nœuds étaient bloqués et ne reconnaîtraient ni ne traiteraient jamais les paiements via des canaux que quelqu’un aurait tenté d’ouvrir après le blocage qui a bloqué leur nœud. Ainsi, même si cela n’éliminait pas complètement le risque d’exploitation des utilisateurs, cela limitait ce risque aux personnes avec lesquelles ils avaient déjà une chaîne. L’action de Burak l’a atténué. Personnellement, je pense que ce type d’action en réponse au bogue avait du sens ; il a limité les dégâts, sensibilisé les utilisateurs au risque et conduit à une correction rapide.

LND n’était pas non plus la seule chose affectée. Liquide le processus d’ancrage a également été rompunécessitant des mises à jour des fonctionnaires de la fédération pour y remédier. Anciennes versions de Rust Bitcoin ont également été affectés, ce qui a entraîné le blocage de certains explorateurs de blocs et instances electrs (une implémentation du serveur principal pour Electrum Wallet). Maintenant, à l’exception de la cheville de Liquid exposant finalement des fonds aux clés de récupération d’urgence détenues par Blockstream après l’expiration d’un délai – et, de manière réaliste, dans l’intrigue de film de style braquage où Blockstream a volé ces fonds, tout le monde sait exactement qui aller après – ces autres les problèmes ne mettent jamais les fonds de quiconque en danger à aucun moment. De plus, Rust Bitcoin avait en fait corrigé ce bogue spécifique dans les versions plus récentes, ce qui n’a apparemment conduit à aucune communication avec les responsables d’autres bases de code pour mettre en évidence le potentiel de tels problèmes. Ce n’est que l’exploitation active du bogue en direct sur le réseau qui a largement révélé que le problème existait dans plusieurs bases de code.

Cela soulève de gros problèmes en ce qui concerne des vulnérabilités comme celle-ci dans le logiciel de couche 2 sur Bitcoin. Premièrement, le sérieux avec lequel ces bases de code sont auditées pour les bogues de sécurité et la façon dont cela est priorisé par rapport à l’intégration de nouvelles fonctionnalités. Je pense qu’il est très révélateur que la sécurité ne soit pas toujours prioritaire étant donné que ce deuxième bogue n’a même pas été trouvé par les mainteneurs de la base de code où il était présent, même s’il était littéralement juste à côté du bogue initial découvert le mois dernier. Après un bogue majeur qui a mis en péril les fonds des utilisateurs, aucun audit interne de cette base de code n’a-t-il été effectué ? Il a fallu quelqu’un d’extérieur au projet pour le découvrir ? Cela ne démontre pas une priorité pour protéger les fonds des utilisateurs plutôt que de créer de nouvelles fonctionnalités pour attirer plus d’utilisateurs. Deuxièmement, le fait que ce problème ait déjà été corrigé dans Rust Bitcoin démontre un manque de communication entre les mainteneurs de différentes bases de code en ce qui concerne les bogues comme celui-ci. C’est assez compréhensible, car le fait d’avoir des bases de code complètement différentes ne fait pas penser immédiatement à quelqu’un qui a trouvé un bogue dans l’un d’entre eux : « Je devrais contacter d’autres équipes écrivant des logiciels similaires dans des langages de programmation totalement différents pour les avertir du potentiel d’un tel bogue. Vous ne trouvez pas de bogue dans Windows et pensez immédiatement à aller signaler le bogue aux responsables du noyau Linux. Cependant, Bitcoin en tant que protocole de consensus distribué sur un réseau mondial est une bête très différente; peut-être que les développeurs de Bitcoin devraient commencer à réfléchir dans ce sens en ce qui concerne les vulnérabilités des logiciels Bitcoin. Surtout quand il s’agit d’analyser et d’interpréter des données consensuelles.

Enfin, peut-être qu’en ce qui concerne des protocoles comme Lightning, qui dépendent de l’observation de la blockchain à tout moment pour pouvoir réagir aux anciens états des canaux afin de maintenir la sécurité, l’analyse indépendante et la vérification des données doivent être réduites au minimum absolu – si pas entièrement supprimé et délégué à Bitcoin Core ou aux données directement dérivées de celui-ci. Core Lightning est architecturé de cette manière, se connectant à une instance de Bitcoin Core et dépendant entièrement de celle-ci pour la validation des blocs et des transactions. Si LND fonctionnait de la même manière, aucun de ces bogues dans btcd n’aurait affecté les utilisateurs de LND d’une manière qui mettrait leurs fonds en danger.

Quelle que soit la manière dont les choses sont gérées – soit en externalisant entièrement la validation, soit en minimisant simplement la validation interne et en l’abordant avec beaucoup plus de soin – cet incident montre que quelque chose doit changer dans l’approche de la question de la façon dont le logiciel de couche 2 gère l’interaction avec les données consensuelles. Encore une fois, tout le monde a beaucoup de chance que cela n’ait pas été exploité par un acteur malveillant, mais plutôt par un développeur prouvant un point. Cela étant dit, Bitcoin ne peut pas compter sur la chance ou espérer que les acteurs malveillants n’existent pas.

Les développeurs et les utilisateurs doivent se concentrer sur l’amélioration des processus pour éviter que de tels incidents ne se reproduisent, et ne pas jouer au jeu de rejeter le blâme comme une patate chaude.

www.actusduweb.com

Suivez Actusduweb sur Google News