Het exploiteren van de Lightning Bug was de ethische keuze

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 tijd is er bij btcd/LND een bug misbruikt waardoor ze in consensus zijn afgeweken van Bitcoin Core. Opnieuw was Burak de ontwikkelaar die deze kwetsbaarheid veroorzaakte – deze keer was het duidelijk opzettelijk – en opnieuw was het een probleem met code voor het parseren van Bitcoin-transacties boven de consensuslaag. Zoals ik heb besproken in mijn stuk over de vorige bug die Burak activeerde, vóór Taproot waren er grenzen aan hoe groot het script en de getuigengegevens in een transactie konden zijn. Met de activering van Taproot werden deze limieten verwijderd, waardoor alleen de beperkingen op de blokgroottelimiet 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 verandering weer te geven, de code die de peer-to-peer-transmissie afhandelde (inclusief het parseren van gegevens vóór verzending of ontvangst) niet correct werd geüpgraded. Dus de codeverwerkingsblokken en transacties voordat deze daadwerkelijk werden doorgegeven om te worden gevalideerd voor consensus, faalden in de gegevens, gaven deze 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 getuigengegevens, waarbij deze werd beperkt tot maximaal 1/8 van de blokgrootte, in tegenstelling tot de volledige blokgrootte. Burak maakte een transactie met getuigengegevens slechts één enkele gewichtseenheid boven de strikte limiet en opnieuw vastgelopen btcd- en LND-knooppunten op die blokhoogte. Deze transactie was een niet-standaardtransactie, wat betekent dat hoewel deze volkomen geldig is volgens de consensusregels, deze niet geldig is volgens het standaard mempool-beleid en dat knooppunten deze daarom niet via het netwerk zullen doorgeven. Het is perfect mogelijk om het in een blok te laten minen, maar de enige manier om dat te doen is door het rechtstreeks aan een miner te verstrekken, wat Burak deed met de hulp van F2Pool.

Dit maakt duidelijk dat elk stuk code dat tot doel heeft Bitcoin-gegevens te parseren en valideren, zwaar moet worden gecontroleerd om er zeker van te zijn dat het in overeenstemming is met wat Bitcoin Core zal doen. Het maakt niet uit of die code de consensusengine is voor een knooppuntimplementatie of slechts een stukje code dat transacties doorgeeft voor een Lightning-knooppunt. Deze tweede bug was letterlijk vlak boven die van vorige maand in de codebasis. Het werd zelfs door niemand bij Lightning Labs ontdekt. AJ Towns rapporteerde dit op 11 oktober, twee dagen nadat de oorspronkelijke bug werd geactiveerd door Burak's 998-van-999 multisig-transactie. Het werd 10 uur lang publiekelijk op Github gepost voordat het werd verwijderd. Er werd vervolgens een oplossing gemaakt, maar deze werd niet vrijgegeven, met de bedoeling om het probleem stilletjes op te lossen 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 ernstig risico voor de fondsen van LND-gebruikers, en gezien het feit dat het zich letterlijk vlak naast de eerdere bug bevond die dezelfde risico's met zich meebracht, was de kans dat het zou worden gevonden en geëxploiteerd zeer groot. zoals aangetoond door Burak. Dit roept de vraag op of de stille patch-aanpak de beste keuze is als het gaat om kwetsbaarheden als deze die gebruikers bloot kunnen stellen aan diefstal van geld (omdat hun knooppunt niet in staat is oude kanaalstatussen te detecteren en deze op de juiste manier te bestraffen).

Zoals ik in mijn stuk over de laatste bug heb uiteengezet: als een kwaadwillende actor de bugs had gevonden vóór een goedbedoelde ontwikkelaar, hadden ze op tactische wijze nieuwe kanalen kunnen openen naar kwetsbare knooppunten, de volledige inhoud van die kanalen naar zichzelf kunnen terugsturen en vervolgens misbruik gemaakt van de bug. Van daaruit zouden ze die fondsen onder hun controle hebben en ook in staat zijn het kanaal met de oorspronkelijke staat te sluiten, waardoor hun geld letterlijk zou verdubbelen. Wat Burak deed door dit probleem op een ironische manier actief uit te buiten, beschermde LND-gebruikers feitelijk tegen een dergelijke aanval.

Toen het eenmaal werd uitgebuit, stonden gebruikers open voor dergelijke aanvallen van reeds bestaande collega's met wie ze al open kanalen hadden, maar ze konden niet langer specifiek worden aangevallen met nieuwe kanalen. Hun knooppunten liepen vast en zouden nooit betalingen herkennen of verwerken via kanalen die iemand probeerde te openen na de blokkering die hun knooppunt tot stilstand bracht. Dus hoewel het risico dat gebruikers werden uitgebuit niet volledig werd weggenomen, werd dat risico wel beperkt tot mensen met wie ze al een kanaal hadden. De actie van Burak verzachtte dit. Persoonlijk denk ik dat dit soort actie als reactie op de bug zinvol 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 getroffen werd. Vloeistof Het pegging-proces werd ook verbroken, waarvoor updates voor de functionarissen van de federatie nodig zijn om het probleem te verhelpen. Oudere versies van Rust Bitcoin werden ook getroffen, waardoor de stalling gevolgen had voor sommige block explorers en electrs instances (een implementatie van de backend-server voor Electrum Wallet). Nu, met uitzondering van de koppeling van Liquid die uiteindelijk geld blootstelt aan de sleutels voor noodherstel die Blockstream in handen heeft na het verstrijken van een tijdslot – en, realistisch gezien in het filmplot in overvalstijl waarin Blockstream deze fondsen heeft gestolen, weet iedereen precies naar wie hij moet gaan – deze andere problemen brengen nooit iemands geld in gevaar. Bovendien had Rust Bitcoin deze specifieke bug in nieuwere versies daadwerkelijk gepatcht, wat blijkbaar niet leidde tot enige communicatie met beheerders van andere codebases om het potentieel voor dergelijke problemen te benadrukken. Het was pas 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 een aantal 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 beveiligingsfouten en hoe daaraan prioriteit wordt gegeven 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, ook al lag deze letterlijk vlak naast de eerste bug die vorige maand werd ontdekt. Is er na een grote bug die het geld van gebruikers in gevaar bracht, geen interne audit van die codebase uitgevoerd? Was er iemand van buiten het project voor nodig om het te ontdekken? Dat toont niet aan dat het veiligstellen van het geld van gebruikers prioriteit heeft boven het bouwen van nieuwe functies om meer gebruikers aan te trekken. Ten tweede toont het feit dat dit probleem al was opgelost in Rust Bitcoin een gebrek aan communicatie aan tussen beheerders van verschillende codebases met betrekking tot dit soort bugs. Dit is redelijk begrijpelijk, omdat het feit dat het totaal verschillende codebases zijn, iemand die een bug in één code heeft gevonden niet meteen denkt: "Ik zou contact moeten opnemen met andere teams die vergelijkbare software schrijven in totaal verschillende programmeertalen om hen te waarschuwen voor de mogelijkheid van zo'n bug." Je vindt geen bug in Windows en denkt dan meteen dat je de bug moet melden aan de Linux-kernelbeheerders. Bitcoin als protocol voor gedistribueerde consensus over een mondiaal 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 parseren en interpreteren van gegevens die consensusgerelateerd zijn.

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

Welke manier de zaken ook worden aangepakt – ofwel de validatie volledig uitbesteden of simpelweg de interne validatie minimaliseren en deze met veel meer zorg benaderen – dit incident laat zien dat er iets moet veranderen in de benadering van de kwestie van hoe Layer 2-software omgaat met de interactie met consensusgerelateerde gegevens. Nogmaals, iedereen heeft veel geluk dat dit niet is misbruikt door een kwaadwillende actor, maar door een ontwikkelaar die zijn punt bewijst. Dat gezegd hebbende, kan Bitcoin er niet op rekenen dat hij geluk heeft of hoopt dat er geen kwaadaardige actoren bestaan.

Ontwikkelaars en gebruikers moeten zich concentreren op het verbeteren van de processen om te voorkomen dat dit soort incidenten zich opnieuw voordoen, 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.