Udnyttelse af lynfejlen var det etiske valg

Dette er en meningsredaktion af Shinobi, en selvlært underviser i Bitcoin-området og teknologiorienteret Bitcoin-podcastvært.

For the second time in roughly a month, btcd/LND have had a bug exploited which caused them to deviate in consensus from Bitcoin Core. Once again, Burak was the developer who triggered this vulnerability — this time it was clearly intentional — and once again, it was an issue with code for parsing Bitcoin transactions above the consensus layer. As I discussed in my stykke på den tidligere fejl som Burak udløste, før Taproot var der grænser for, hvor store script- og vidnedata i en transaktion kunne være. Med aktiveringen af ​​Taproot blev disse grænser fjernet, hvilket kun efterlod begrænsningerne på selve blokstørrelsesgrænsen for at begrænse disse dele af individuelle transaktioner. Problemet med den sidste fejl var, at på trods af, at konsensuskoden i btcd var korrekt opgraderet for at afspejle denne ændring, opgraderede koden, der håndterede peer-to-peer-transmission - inklusive parsing af data før afsendelse eller modtagelse - ikke korrekt. Så kodebearbejdningsblokkene og -transaktionerne, før de rent faktisk blev videregivet til at blive valideret for konsensus, svigtede dataene, sendte dem aldrig til konsensusvalideringslogikken, og den pågældende blok blev aldrig valideret.

En meget lignende ting skete denne gang. En anden grænse i peer-to-peer sektionen af ​​kodebasen var at håndhæve en begrænsning på vidnedata forkert, begrænse den til maksimalt 1/8 af blokstørrelsen i modsætning til den fulde blokstørrelse. Burak lavede en transaktion med vidnedata kun en enkelt vægtenhed over den strenge grænse og igen stoppede btcd- og LND-noder i den blokhøjde. Denne transaktion var en ikke-standard transaktion, hvilket betyder, at selvom den er perfekt gyldig ifølge konsensusregler, er den ikke gyldig i henhold til standard mempool-politik, og derfor vil noder ikke videresende den på tværs af netværket. Det er udmærket muligt at få det udvundet i en blok, men den eneste måde at gøre det på er at give det direkte til en minearbejder, hvilket Burak gjorde ved hjælp af F2Pool.

This really drives home the point that any piece of code whose purpose is to parse and validate Bitcoin data must be heavily audited in order to ensure it is in line with what Bitcoin Core will do. It doesn’t matter if that code is the consensus engine for a node implementation or just a piece of code passing transactions around for a Lightning node. This second bug was bogstaveligt talt lige over den fra sidste måned i kodebasen. Det blev ikke engang opdaget af nogen på Lightning Labs. AJ Towns rapporterede det den 11. oktober, to dage efter den oprindelige fejl blev udløst af Buraks 998-af-999 multisig-transaktion. Det blev offentliggjort på Github i 10 timer, før det blev slettet. En rettelse blev derefter lavet, men ikke frigivet, med den hensigt stille og roligt at lappe problemet i den næste udgivelse af LND.

Now, this is pretty standard procedure for a serious vulnerability, especially with a project like Bitcoin Core where such a vulnerability can actually cause serious damage to the base-layer network/protocol. But in this specific case, it presented a serious risk to LND users’ funds, and given the fact that it was literally right next to the prior bug that had the same risks, the chances that it would be found and exploited were very high, as demonstrated by Burak. This begs the question of whether the quiet-patch approach is the way to go when it comes to vulnerabilities like this that can leave users open to theft of funds (because their node is left unable to detect old channel states and properly penalize them).

Som jeg gik ind på i mit stykke om den sidste fejl, hvis en ondsindet aktør havde fundet fejlene før en velmenende udvikler, kunne de taktisk have åbnet nye kanaler til sårbare noder, dirigeret hele indholdet af disse kanaler tilbage til sig selv og derefter udnyttede fejlen. Derfra ville de have disse midler under deres kontrol og også være i stand til at lukke kanalen med den oprindelige tilstand, bogstaveligt talt fordoble deres penge. Hvad Burak gjorde ved aktivt at udnytte dette problem på en ironisk måde, beskyttede faktisk LND-brugere mod et sådant angreb.

Når det først blev udnyttet, var brugere åbne over for sådanne angreb fra allerede eksisterende peers, som de allerede havde åbne kanaler med, men de var ikke længere i stand til at blive målrettet specifikt med nye kanaler. Deres noder var gået i stå og ville aldrig genkende eller behandle betalinger gennem kanaler, som nogen forsøgte at åbne efter blokeringen, der stoppede deres node. Så selvom det ikke helt fjernede risikoen for, at brugere blev udnyttet, begrænsede det den risiko til folk, de allerede havde en kanal med. Buraks handling mildnede det. Personligt synes jeg, at denne type handling som reaktion på fejlen gav mening; det begrænsede skaden, gjorde brugerne opmærksomme på risikoen og førte til, at den hurtigt blev lappet.

LND var heller ikke det eneste, der blev ramt. Væske pegging-processen blev også brudt, der kræver opdateringer til forbundets funktionærer for at rette det. Older versions of Rust Bitcoin were affected as well, which caused the stall to affect some block explorers and electrs instances (an implementation of the backend server for Electrum Wallet). Now, with the exception of Liquid’s peg eventually exposing funds to the emergency recovery keys held by Blockstream after a timelock expiry — and, realistically in the heist-style movie plot where Blockstream stole these funds, everyone knows exactly who to go after — these other issues never put anyone’s funds at risk at any point. Also, Rust Bitcoin had actually patched this specific bug in newer versions, which apparently didn’t lead to any communication with maintainers of other codebases to highlight the potential for such issues. It was only the active exploitation of the bug live on the network that widely exposed that the issue existed in multiple codebases.

This brings up some big issues when it comes to vulnerabilities like this in Layer 2 software on Bitcoin. First, the seriousness with which these codebases are audited for security bugs and how that is prioritized versus the integration of new features. I think it is very telling that security is not always prioritized given that this second bug was not even found by the maintainers of the codebase where it was present, even though it was literally right next to the initial bug discovered last month. After one major bug that put users’ funds at risk, was no internal audit of that codebase done? It took someone from outside the project to discover it? That does not demonstrate a priority to safeguard users’ funds over building new features to draw in more users. Second, the fact that this issue was already patched in Rust Bitcoin demonstrates a lack of communication across maintainers of different codebases in regards to bugs like this. This is pretty understandable, as being completely different codebases doesn’t make someone who found a bug in one immediately think, “I should contact other teams writing similar software in totally different programming languages to warn them about the potential for such a bug.” You don’t find a bug in Windows and then immediately think to go report the bug to Linux kernel maintainers. Bitcoin as a protocol for distributed consensus across a global network is a very different beast, however; maybe Bitcoin developers should start to think along those lines when it comes to vulnerabilities in Bitcoin software. Especially when it comes to parsing and interpreting data that is consensus related.

Lastly, maybe when it comes to protocols like Lightning, which depend on observing the blockchain at all times to be able to react to old channel states in order to maintain security, independent parsing and verification of data should be kept to an absolute minimum — if not removed entirely and delegated to Bitcoin Core or data directly derived from it. Core Lightning is architected in this way, connecting to an instance of Bitcoin Core and depending entirely on that for validation of blocks and transactions. If LND worked the same way, neither of these bugs in btcd would have affected LND users in a way that put their funds at risk.

Whichever way things are handled — either outsourcing validation entirely or simply minimizing internal validation and approaching it with much more care — this incident shows that something needs to change in approaching the issue of how Layer 2 software handles interacting with consensus-related data. Once again, everyone is very lucky that this was not exploited by a malicious actor, but instead by a developer proving a point. That being said, Bitcoin cannot count on getting lucky or hoping that malicious actors do not exist.

Udviklere og brugere bør fokusere på at forbedre processerne for at forhindre hændelser som denne i at ske igen, og ikke spille spillet med at kaste skylden rundt som en varm kartoffel.

Dette er et gæsteindlæg af Shinobi. Udtalte meninger er helt deres egne og afspejler ikke nødvendigvis dem fra BTC Inc eller Bitcoin Magazine.