Exploiter le Lightning Bug était le choix éthique

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 a eu un bug exploité qui les a amenés à s'écarter du consensus par rapport à Bitcoin Core. Une fois de plus, Burak est le développeur qui a déclenché cette vulnérabilité – cette fois, c'était clairement intentionnel – et encore une fois, il s'agissait d'un problème avec le code permettant d'analyser les transactions Bitcoin au-dessus de la couche de consensus. Comme je l'ai évoqué dans mon article sur le bug précédent que Burak a déclenché, avant Taproot, il y avait des limites à la taille des données de script et de témoin dans une transaction. Avec l'activation de Taproot, ces limites ont été supprimées, ne laissant que les limites de taille de bloc elle-même pour limiter ces parties des transactions individuelles. Le problème avec le dernier bug é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, le code traitant les blocs et les transactions avant qu'ils ne soient réellement transmis pour être validés pour consensus a échoué à transmettre les données, ne les a jamais transmises à la logique de validation par consensus et le bloc en question n'a jamais pu être 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 consistait à appliquer incorrectement une restriction sur les données des témoins, en les limitant à un maximum de 1/8 de la taille du bloc, par opposition à la taille totale du bloc. Burak a conçu un transaction avec les données témoins, une seule unité de poids au-dessus de la limite stricte et une fois de plus 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 pool de mémoire par défaut et donc les nœuds ne la relayeront pas à travers le réseau. Il est parfaitement possible de l'extraire en bloc, mais le seul moyen d'y parvenir est de le fournir directement à un mineur, ce qu'a fait Burak avec l'aide de F2Pool.

Cela fait vraiment ressortir le fait que tout morceau de code dont le but est d’analyser et de valider les données Bitcoin doit être fortement audité afin de garantir qu’il est conforme à ce que Bitcoin Core fera. Peu importe que ce code soit le moteur de consensus pour l'implémentation d'un 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. Cela n’a même été découvert par personne chez Lightning Labs. AJ Towns l'a signalé le 11 octobre, deux jours après le déclenchement du bug initial par la transaction multisig 998 sur 999 de Burak. Il a été publié publiquement sur Github pendant 10 heures avant d'être supprimé. Un correctif a ensuite été apporté, mais n'a pas été publié, avec l'intention de corriger discrètement le problème dans la prochaine version de LND.

Il s’agit d’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 réalité 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 se trouvait littéralement juste à côté du bug 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 des correctifs 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 bug, si un acteur malveillant avait trouvé les bugs avant un développeur bien intentionné, il aurait pu tactiquement ouvrir de nouveaux canaux vers des nœuds vulnérables, renvoyer tout le contenu de ces canaux vers lui-même, puis exploité le bug. À 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 du LND contre une telle attaque.

Une fois exploité, les utilisateurs étaient vulnérables à de telles attaques de la part 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 reconnaissaient ni ne traitaient jamais les paiements via les canaux que quelqu'un avait tenté d'ouvrir après le blocage qui avait bloqué leur nœud. Ainsi, même si cela n'a pas complètement supprimé le risque d'exploitation des utilisateurs, cela a limité 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 bug avait du sens ; il a limité les dégâts, a sensibilisé les utilisateurs au risque et a permis de le corriger rapidement.

Le LND n’a pas non plus été le seul à être touché. Liquide le processus de rattachement a également été interrompu, né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 amené le blocage à affecter certains explorateurs de blocs et instances electrs (une implémentation du serveur backend pour Electrum Wallet). Désormais, à l'exception du rattachement de Liquid qui finit par exposer les 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 du film de style braquage où Blockstream a volé ces fonds, tout le monde sait exactement à qui s'en prendre - ces autres les problèmes ne mettent jamais en danger les fonds de qui que ce soit. De plus, Rust Bitcoin avait en fait corrigé ce bug spécifique dans des 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. Seule l’exploitation active du bug en direct sur le réseau 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 les logiciels de couche 2 sur Bitcoin. Premièrement, le sérieux avec lequel ces bases de code sont auditées pour détecter les bogues de sécurité et la manière 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é n'est pas toujours prioritaire étant donné que ce deuxième bug n'a même pas été trouvé par les responsables de la base de code où il était présent, même s'il était littéralement juste à côté du bug initial découvert le mois dernier. Après un bug majeur mettant en danger les fonds des utilisateurs, aucun audit interne de cette base de code n'a-t-il été effectué ? Il a fallu quelqu'un extérieur au projet pour le découvrir ? Cela ne démontre pas qu'il est prioritaire de protéger les fonds des utilisateurs plutôt que de créer de nouvelles fonctionnalités pour attirer davantage 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 responsables des différentes bases de code concernant des bugs comme celui-ci. C'est assez compréhensible, car le fait d'avoir des bases de code complètement différentes ne fait pas immédiatement penser à quelqu'un qui a trouvé un bug dans l'une d'entre elles : « Je devrais contacter d'autres équipes qui écrivent des logiciels similaires dans des langages de programmation totalement différents pour les avertir de la possibilité d'un tel bug. » Vous ne trouvez pas de bug dans Windows et pensez immédiatement à signaler le bug aux responsables du noyau Linux. Bitcoin en tant que protocole de consensus distribué sur un réseau mondial est cependant 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 lorsqu'il s'agit d'analyser et d'interpréter des données liées au consensus.

Enfin, peut-être lorsqu'il s'agit de 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 et la vérification indépendantes des données devraient ê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 bugs 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 simplement en minimisant 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 manière dont les logiciels de couche 2 gèrent l’interaction avec les données liées au consensus. 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 qui prouve son point de vue. Cela étant dit, Bitcoin ne peut pas compter sur la chance ou espérer qu’il n’existe pas d’acteurs malveillants.

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

Ceci est un article invité de Shinobi. Les opinions exprimées sont entièrement les leurs et ne reflètent pas nécessairement celles de BTC Inc ou de Bitcoin Magazine.