Välkvea ärakasutamine oli eetiline valik

See on Bitcoini ruumi iseõppinud koolitaja ja tehnoloogiale orienteeritud Bitcoini taskuhäälingusaate hosti Shinobi arvamustoimetus.

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 tükk eelnevast veast mille Burak käivitas, olid enne Taprooti piirangud tehingu skripti ja tunnistajaandmete suurusele. Taprooti aktiveerimisega need piirangud eemaldati, jättes üksikute tehingute nende osade piiramiseks ainult ploki suuruse piirangu enda piirangud. Viimase veaga seotud probleem seisnes selles, et hoolimata asjaolust, et btcd konsensuskood oli selle muudatuse kajastamiseks korralikult uuendatud, ei uuendatud võrdõiguslikku edastamist käsitlev kood, sealhulgas andmete sõelumine enne saatmist või vastuvõtmist, korralikult. Nii et kooditöötlusplokid ja tehingud, enne kui need konsensuse jaoks valideerimiseks tegelikult edastati, ebaõnnestusid andmetes, ei edastanud neid kunagi konsensuse valideerimise loogikale ja kõnealust plokki ei õnnestunud kunagi kinnitada.

Seekord juhtus väga sarnane lugu. Teine piirang koodibaasi peer-to-peer sektsioonis oli tunnistajate andmetele piirangu jõustamine valesti, piirates seda maksimaalselt 1/8 ploki suurusest erinevalt ploki täissuurusest. Burak meisterdas a tehing tunnistajate andmetega vaid üks kaaluühik üle range piirangu ja jällegi seiskusid btcd ja LND sõlmed sellel ploki kõrgusel. See tehing oli mittestandardne tehing, mis tähendab, et kuigi see konsensusreeglite järgi on täiesti kehtiv, ei kehti see mempooli vaikepoliitika kohaselt ja seetõttu ei edasta sõlmed seda üle võrgu. See on täiesti võimalik saada plokki kaevandada, kuid ainus viis seda teha on anda see otse kaevandajale, mida Burak F2Pooli abiga tegi.

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 sõna otseses mõttes otse üle eelmise kuu oma koodibaasis. Seda ei avastanud isegi keegi Lightning Labsis. AJ Towns teatas sellest 11. oktoobril, kaks päeva pärast seda, kui Buraki 998/999 multisig-tehing käivitas esialgse vea. Enne kustutamist postitati see avalikult Githubisse 10 tundi. Seejärel tehti parandus, kuid seda ei avaldatud, eesmärgiga probleem vaikselt LND järgmises versioonis parandada.

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).

Nagu ma oma viimast viga käsitlevas kirjatükis käsitlesin, kui pahatahtlik näitleja oleks vead leidnud enne heade kavatsustega arendajat, oleks ta võinud taktikaliselt avada uusi kanaleid haavatavatele sõlmedele, suunata kogu nende kanalite sisu enda juurde ja seejärel kasutas viga ära. Sealt oleksid nad need vahendid oma kontrolli all ja saaksid ka kanali esialgse seisuga sulgeda, sõna otseses mõttes kahekordistades oma raha. See, mida Burak selle probleemi iroonilisel viisil aktiivselt ära kasutas, kaitses tegelikult LND kasutajaid sellise rünnaku eest.

Pärast selle ärakasutamist olid kasutajad avatud sellistele rünnakutele juba olemasolevate eakaaslaste poolt, kellega neil juba olid avatud kanalid, kuid neid ei saanud enam uute kanalite abil konkreetselt sihtida. Nende sõlmed olid seiskunud ega tuvastanud ega töötle kunagi makseid kanalite kaudu, mida keegi üritas pärast sõlme seiskunud plokki avada. Ehkki see ei kõrvaldanud täielikult kasutajate ärakasutamise ohtu, piiras see seda ohtu inimestele, kellega neil juba kanal oli. Buraki tegevus leevendas seda. Isiklikult arvan, et selline tegevus vastuseks veale oli mõistlik; see piiras kahju, muutis kasutajad riskist teadlikuks ja viis selle kiire parandamiseni.

LND ei olnud ka ainus, mida see mõjutas. Vedelik ka sidumisprotsess katkes, mille parandamiseks on vaja föderatsiooni funktsionääridelt värskendusi. 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.

Arendajad ja kasutajad peaksid keskenduma protsesside täiustamisele, et vältida selliste vahejuhtumite kordumist, ja mitte mängima seda mängu, et süüdistada nagu kuuma kartulit.

See on Shinobi külalispostitus. Avaldatud arvamused on täielikult nende omad ja ei pruugi kajastada BTC Inc või Bitcoin Magazine'i arvamusi.