Izkoriščanje hrošča Lightning Bug je bila etična izbira

To je mnenjski uvodnik Shinobija, samouka, izobraževalca v Bitcoin prostoru in tehnološko usmerjenega voditelja podcasta Bitcoin.

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 kos na prejšnji napaki ki ga je sprožil Burak, so pred Taprootom obstajale omejitve glede velikosti skripta in podatkov prič v transakciji. Z aktivacijo Taproota so bile te omejitve odstranjene, tako da so ostale samo omejitve glede same omejitve velikosti bloka, da se omejijo ti deli posameznih transakcij. Težava pri zadnji napaki je bila v tem, da kljub dejstvu, da je bila soglasna koda v btcd pravilno nadgrajena, da odraža to spremembo, se koda, ki obravnava prenos enakovrednih — vključno z razčlenjevanjem podatkov pred pošiljanjem ali prejemanjem — ni pravilno nadgradila. Torej koda, ki obdeluje bloke in transakcije, preden je bila dejansko posredovana v potrditev za soglasje, ni prenesla podatkov, nikoli jih ni posredovala logiki potrjevanja soglasja in zadevni blok ni bil nikoli preverjen.

Tokrat se je zgodilo zelo podobno. Druga omejitev v razdelku peer-to-peer zbirke kode je bila nepravilna uveljavitev omejitve podatkov prič, ki je bila omejena na največ 1/8 velikosti bloka v nasprotju s celotno velikostjo bloka. Burak je izdelal a transakcija s pričevalnimi podatki le eno enoto teže nad strogo omejitvijo in znova zastala vozlišča btcd in LND na tej višini bloka. Ta transakcija je bila nestandardna transakcija, kar pomeni, da čeprav je popolnoma veljavna po pravilih soglasja, ni veljavna glede na privzeto politiko mempoola, zato je vozlišča ne bodo posredovala po omrežju. Popolnoma možno ga je spraviti izrudariti v blok, vendar je edini način, da ga zagotovite neposredno rudarju, kar je Burak storil s pomočjo F2Poola.

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 dobesedno tik nad tistim iz prejšnjega meseca v kodni bazi. Odkril ga ni niti nihče v Lightning Labs. AJ Towns je o tem poročal 11. oktobra, dva dni po tem, ko je prvotno napako sprožila Burakova večpodpisna transakcija 998 od 999. Preden so ga izbrisali, je bil javno objavljen na Githubu 10 ur. Nato je bil narejen popravek, vendar ni bil izdan, z namenom, da se težava tiho popravi v naslednji izdaji 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).

Kot sem šel v svojem prispevku o zadnji napaki, če bi zlonamerni akter našel hrošče pred dobronamernim razvijalcem, bi lahko taktično odprl nove kanale do ranljivih vozlišč, preusmeril celotno vsebino teh kanalov nazaj k sebi in nato izkoristil napako. Od tam bi imeli ta sredstva pod svojim nadzorom in bi lahko tudi zaprli kanal z začetnim stanjem, s čimer bi dobesedno podvojili svoj denar. Kar je Burak naredil pri dejavnem izkoriščanju te težave na ironičen način, je dejansko zaščitilo uporabnike LND pred takšnim napadom.

Ko je bil izkoriščen, so bili uporabniki odprti za takšne napade že obstoječih vrstnikov, s katerimi so že imeli odprte kanale, vendar jih ni bilo več mogoče posebej ciljati z novimi kanali. Njihova vozlišča so bila zaustavljena in nikoli ne bi prepoznala ali obdelala plačil prek kanalov, ki jih je nekdo poskušal odpreti po bloku, ki je zaustavil njihovo vozlišče. Torej, čeprav ni popolnoma odstranil tveganja izkoriščanja uporabnikov, je to tveganje omejil na ljudi, s katerimi so že imeli kanal. Burakovo dejanje jo je ublažilo. Osebno menim, da je bilo tovrstno ukrepanje kot odgovor na napako smiselno; omejil je škodo, uporabnike seznanil s tveganjem in privedel do hitre sanacije.

LND tudi ni bila edina prizadeta stvar. Tekočine pokvarjen je bil tudi postopek fiksiranja, ki zahteva posodobitve funkcionarjev zveze, da to popravijo. 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.

Razvijalci in uporabniki bi morali biti osredotočeni na izboljšanje procesov, da bi preprečili, da bi se takšni incidenti ponovili, in se ne bi morali igrati igre premetavanja krivde kot vroč krompir.

To je gostujoča objava avtorja Shinobija. Izražena mnenja so v celoti njihova lastna in ne odražajo nujno mnenj BTC Inc ali Bitcoin Magazine.