Het uitbuiten van de Lightning Bug was ethisch – Bitcoin Magazine



Dit is een opinieredactioneel commentaar van Shinobi, een autodidactische opvoeder in de Bitcoin-ruimte en technisch georiënteerde Bitcoin-podcasthost.

Voor de tweede keer in ongeveer een maand is er bij btcd/LND een bug uitgebuit waardoor ze in consensus afweken van Bitcoin Core. Nogmaals, Burak was de ontwikkelaar die deze kwetsbaarheid veroorzaakte – deze keer was het duidelijk opzettelijk – en nogmaals, het was een probleem met code voor het ontleden van Bitcoin-transacties boven de consensuslaag. Zoals ik besprak in mijn stuk over de eerdere bug die Burak veroorzaakte, waren er vóór Taproot limieten aan hoe groot het script en de gegevens van getuigen in een transactie konden zijn. Met de activering van Taproot werden die limieten verwijderd, waardoor alleen de beperkingen op de blokgrootte zelf overbleven om deze delen van individuele transacties te beperken. Het probleem met de laatste bug was dat ondanks het feit dat de consensuscode in btcd correct was geüpgraded om deze wijziging weer te geven, de code die peer-to-peer-transmissie afhandelde – inclusief het ontleden van gegevens vóór verzending of bij ontvangst – niet correct werd bijgewerkt. Dus de codeverwerkingsblokken en transacties voordat het daadwerkelijk werd doorgegeven om te worden gevalideerd voor consensus, faalden de gegevens, gaven het nooit door aan de consensusvalidatielogica en het blok in kwestie kon nooit worden gevalideerd.

Deze keer gebeurde iets soortgelijks. Een andere limiet in het peer-to-peer-gedeelte van de codebase was het onjuist afdwingen van een beperking op de getuigegegevens, waardoor deze werd beperkt tot maximaal 1/8 van de blokgrootte in tegenstelling tot de volledige blokgrootte. Burak maakte een transactie met getuigegegevens die slechts één gewichtseenheid over de strikte limiet overschreed en opnieuw btcd- en LND-knooppunten op die blokhoogte vastliep. Deze transactie was een niet-standaard transactie, wat betekent dat hoewel deze perfect geldig is volgens consensusregels, deze niet geldig is volgens het standaard mempool-beleid en daarom zullen nodes deze niet over het netwerk doorgeven. Het is perfect mogelijk om het in een blok te delven, maar de enige manier om dit te doen is om het rechtstreeks aan een mijnwerker te geven, wat Burak deed met behulp van F2Pool.

Dit maakt echt duidelijk dat elk stukje code dat bedoeld is om Bitcoin-gegevens te ontleden en te valideren, zwaar moet worden gecontroleerd om ervoor te zorgen dat het in overeenstemming is met wat Bitcoin Core zal doen. Het maakt niet uit of die code de consensus-engine is voor een knooppuntimplementatie of slechts een stukje code dat transacties doorgeeft voor een Lightning-knooppunt. Deze tweede bug was letterlijk recht boven die van vorige maand in de codebasis. Het werd zelfs door niemand bij Lightning Labs ontdekt. AJ Towns meldde het op 11 oktober, twee dagen nadat de oorspronkelijke bug werd geactiveerd door Burak’s 998-of-999 multisig-transactie. Het werd 10 uur lang publiekelijk op Github geplaatst voordat het werd verwijderd. Er is toen een fix gemaakt, maar niet vrijgegeven, met de bedoeling het probleem stilletjes te patchen in de volgende release van LND.

Dit is een vrij standaardprocedure voor een ernstige kwetsbaarheid, vooral bij een project als Bitcoin Core waar een dergelijke kwetsbaarheid daadwerkelijk ernstige schade aan het basislaagnetwerk/-protocol kan veroorzaken. Maar in dit specifieke geval vormde het een serieus risico voor het geld van LND-gebruikers, en gezien het feit dat het letterlijk naast de eerdere bug zat die dezelfde risico’s had, was de kans dat het zou worden gevonden en misbruikt zeer hoog, zoals aangetoond door Burak. Dit roept de vraag op of de stille patch-aanpak de juiste keuze is als het gaat om kwetsbaarheden zoals deze die gebruikers bloot kunnen stellen aan diefstal van geld (omdat hun node niet in staat is om oude kanaalstatussen te detecteren en ze correct te bestraffen).

Zoals ik in mijn stuk over de laatste bug inging, als een kwaadwillende acteur de bugs had gevonden voordat een goedbedoelende ontwikkelaar tactisch nieuwe kanalen naar kwetsbare knooppunten had geopend, de volledige inhoud van die kanalen naar zichzelf had kunnen routeren en vervolgens misbruik gemaakt van de bug. Van daaruit zouden ze die fondsen onder hun controle hebben en ook in staat zijn om het kanaal te sluiten met de oorspronkelijke staat, waardoor ze letterlijk hun geld zouden verdubbelen. Wat Burak deed door dit probleem actief op een ironische manier uit te buiten, beschermde LND-gebruikers in feite tegen een dergelijke aanval.

Toen het eenmaal was uitgebuit, stonden gebruikers open voor dergelijke aanvallen van bestaande peers met wie ze al open kanalen hadden, maar ze waren niet langer in staat om specifiek met nieuwe kanalen te worden aangevallen. Hun knooppunten waren vastgelopen en zouden nooit betalingen herkennen of verwerken via kanalen die iemand probeerde te openen na het blok dat hun knooppunt blokkeerde. Dus hoewel het het risico van misbruik van gebruikers niet volledig wegnam, beperkte het dat risico wel tot mensen met wie ze al een kanaal hadden. De actie van Burak verzachtte het. Persoonlijk denk ik dat dit soort actie als reactie op de bug logisch was; het beperkte de schade, maakte gebruikers bewust van het risico en zorgde ervoor dat het snel werd gepatcht.

LND was ook niet het enige dat werd getroffen. Vloeistoffen pegging-proces was ook verbrokenwaardoor updates voor de functionarissen van de federatie nodig zijn om het te repareren. Oudere versies van Rust Bitcoin werden ook beïnvloed, waardoor de stal sommige blokverkenners en elektrs-instanties (een implementatie van de backend-server voor Electrum Wallet) beïnvloedde. Nu, met uitzondering van Liquid’s peg die uiteindelijk fondsen blootstelt aan de noodherstelsleutels die door Blockstream worden bewaard na het verstrijken van een tijdslot – en, realistisch gezien in de filmplot in overvalstijl waar Blockstream deze fondsen stal, weet iedereen precies wie te gaan na – deze andere problemen brengen nooit iemands geld in gevaar. Ook had Rust Bitcoin deze specifieke bug in nieuwere versies gepatcht, wat blijkbaar niet leidde tot enige communicatie met beheerders van andere codebases om het potentieel voor dergelijke problemen te benadrukken. Het was alleen de actieve exploitatie van de bug live op het netwerk die op grote schaal aan het licht bracht dat het probleem in meerdere codebases bestond.

Dit brengt enkele grote problemen met zich mee als het gaat om kwetsbaarheden zoals deze in Layer 2-software op Bitcoin. Ten eerste de ernst waarmee deze codebases worden gecontroleerd op beveiligingsbugs en hoe dat wordt geprioriteerd ten opzichte van de integratie van nieuwe functies. Ik denk dat het veelzeggend is dat beveiliging niet altijd prioriteit heeft, aangezien deze tweede bug niet eens werd gevonden door de beheerders van de codebase waar deze aanwezig was, hoewel het letterlijk vlak naast de eerste bug was die vorige maand werd ontdekt. Is er na een grote bug die het geld van de gebruikers in gevaar bracht, geen interne audit van die codebase gedaan? Was er iemand van buiten het project nodig om het te ontdekken? Dat toont geen prioriteit aan om het geld van gebruikers te beschermen boven het bouwen van nieuwe functies om meer gebruikers aan te trekken. Ten tweede, het feit dat dit probleem al in Rust Bitcoin was gepatcht, toont een gebrek aan communicatie tussen beheerders van verschillende codebases met betrekking tot dit soort bugs. Dit is redelijk begrijpelijk, omdat het feit dat het volledig verschillende codebases zijn, iemand die een bug in één ervan heeft gevonden niet meteen denkt: “Ik zou contact moeten opnemen met andere teams die vergelijkbare software in totaal verschillende programmeertalen schrijven om hen te waarschuwen voor de mogelijkheid van zo’n bug.” Je vindt geen bug in Windows en denkt dan meteen om de bug te melden aan de Linux-kernelbeheerders. Bitcoin als protocol voor gedistribueerde consensus over een wereldwijd netwerk is echter een heel ander beest; misschien moeten Bitcoin-ontwikkelaars in die richting gaan denken als het gaat om kwetsbaarheden in Bitcoin-software. Vooral als het gaat om het ontleden en interpreteren van gegevens die met consensus te maken hebben.

Ten slotte, misschien als het gaat om protocollen zoals Lightning, die te allen tijde afhankelijk zijn van het observeren van de blockchain om te kunnen reageren op oude kanaalstatussen om de veiligheid te behouden, moeten onafhankelijke parsing en verificatie van gegevens tot een absoluut minimum worden beperkt – als niet volledig verwijderd en gedelegeerd aan Bitcoin Core of gegevens die er rechtstreeks van zijn afgeleid. Core Lightning is op deze manier ontworpen, verbindt met een instantie van Bitcoin Core en is volledig afhankelijk daarvan voor validatie van blokken en transacties. Als LND op dezelfde manier zou werken, zouden geen van deze bugs in btcd LND-gebruikers hebben getroffen op een manier die hun geld in gevaar zou brengen.

Op welke manier de zaken ook worden afgehandeld – ofwel validatie volledig uitbesteden of eenvoudig interne validatie minimaliseren en met veel meer zorg benaderen – dit incident laat zien dat er iets moet veranderen in de benadering van de vraag hoe Layer 2-software omgaat met de interactie met consensusgerelateerde gegevens. Nogmaals, iedereen heeft veel geluk dat dit niet werd uitgebuit door een kwaadwillende acteur, maar in plaats daarvan door een ontwikkelaar die een punt bewijst. Dat gezegd hebbende, Bitcoin kan er niet op rekenen geluk te hebben of te hopen dat kwaadwillende actoren niet bestaan.

Ontwikkelaars en gebruikers moeten gefocust zijn op het verbeteren van de processen om te voorkomen dat dit soort incidenten opnieuw gebeurt, en niet het spel spelen van het rondgooien van de schuld als een hete aardappel.

Dit is een gastpost van Shinobi. De geuite meningen zijn geheel van henzelf en komen niet noodzakelijk overeen met die van BTC Inc of Bitcoin Magazine.



Plaats een reactie