Att utnyttja blixten var det etiska valet

Detta är en åsiktsledare av Shinobi, en självlärd utbildare inom Bitcoin-utrymmet och teknikorienterad Bitcoin-podcast-värd.

För andra gången på ungefär en månad har btcd/LND fått en bugg utnyttjad som fick dem att avvika i konsensus från Bitcoin Core. Återigen var Burak utvecklaren som utlöste denna sårbarhet - den här gången var det tydligt avsiktligt - och återigen var det ett problem med kod för att analysera Bitcoin-transaktioner ovanför konsensusskiktet. Som jag diskuterade i min bit på föregående bugg som Burak utlöste, innan Taproot fanns det gränser för hur stort manus och vittnesdata i en transaktion kunde vara. Med aktiveringen av Taproot togs dessa gränser bort och lämnade endast begränsningarna för själva blockstorleksgränsen för att begränsa dessa delar av enskilda transaktioner. Problemet med det senaste felet var att trots det faktum att konsensuskoden i btcd uppgraderades korrekt för att återspegla denna förändring, uppgraderades inte koden som hanterade peer-to-peer-överföring – inklusive analys av data före sändning eller mottagning – inte korrekt. Så kodbearbetningsblocken och transaktionerna innan de faktiskt skickades för att valideras för konsensus misslyckades med data, skickade den aldrig till konsensusvalideringslogiken och blocket i fråga kunde aldrig valideras.

En mycket liknande sak hände den här gången. En annan gräns i peer-to-peer-sektionen av kodbasen var att tillämpa en begränsning av vittnesdata felaktigt, begränsa den till maximalt 1/8 av blockstorleken i motsats till full blockstorlek. Burak skapade en transaktion med vittnesdata bara en enda viktenhet över den strikta gränsen och återigen stannade btcd- och LND-noder på den blockhöjden. Denna transaktion var en icke-standardtransaktion, vilket innebär att även om den är helt giltig enligt konsensusregler, är den inte giltig enligt standard mempool-policy och därför kommer noder inte att vidarebefordra den över nätverket. Det är fullt möjligt att få det minerat i ett block, men det enda sättet att göra det är att tillhandahålla det direkt till en gruvarbetare, vilket är vad Burak gjorde med hjälp av F2Pool.

Detta driver verkligen hem poängen att varje bit kod vars syfte är att analysera och validera Bitcoin-data måste granskas hårt för att säkerställa att det är i linje med vad Bitcoin Core kommer att göra. Det spelar ingen roll om den koden är konsensusmotorn för en nodimplementering eller bara en bit kod som skickar runt transaktioner för en Lightning-nod. Denna andra bugg var bokstavligen precis ovanför den från förra månaden i kodbasen. Det upptäcktes inte ens av någon på Lightning Labs. AJ Towns rapporterade det den 11 oktober, två dagar efter att den ursprungliga buggen utlöstes av Buraks 998-av-999 multisig-transaktion. Det publicerades offentligt på Github i 10 timmar innan det raderades. En korrigering gjordes sedan, men släpptes inte, med avsikten att tyst korrigera problemet i nästa utgåva av LND.

Nu är detta en ganska standardprocedur för en allvarlig sårbarhet, speciellt med ett projekt som Bitcoin Core där en sådan sårbarhet faktiskt kan orsaka allvarlig skada på basskiktsnätverket/-protokollet. Men i det här specifika fallet utgjorde det en allvarlig risk för LND-användares medel, och med tanke på att det bokstavligen låg precis bredvid föregående bugg som hade samma risker, var chansen att den skulle hittas och utnyttjas mycket stor, som visades av Burak. Detta väcker frågan om huruvida den tysta patch-metoden är rätt väg att gå när det kommer till sårbarheter som denna som kan lämna användarna öppna för stöld av pengar (eftersom deras nod lämnas oförmögen att upptäcka gamla kanaltillstånd och straffa dem på rätt sätt).

Som jag gick in på i mitt inlägg om den sista buggen, om en illvillig aktör hade hittat buggen före en välmenande utvecklare, kunde de taktiskt ha öppnat nya kanaler till sårbara noder, dirigerat tillbaka hela innehållet i dessa kanaler till sig själva och sedan utnyttjade felet. Därifrån skulle de ha dessa medel under sin kontroll och även kunna stänga kanalen med det ursprungliga tillståndet, bokstavligen fördubbla sina pengar. Det Burak gjorde genom att aktivt utnyttja det här problemet på ett ironiskt sätt skyddade faktiskt LND-användare från en sådan attack.

När den väl hade utnyttjats var användare öppna för sådana attacker från redan existerande kamrater som de redan hade öppna kanaler med, men de kunde inte längre riktas specifikt mot nya kanaler. Deras noder stannade och skulle aldrig känna igen eller behandla betalningar genom kanaler som någon försökte öppna efter blocket som stoppade deras nod. Så även om det inte helt tog bort risken för att användare utnyttjades, begränsade det den risken till personer som de redan hade en kanal med. Buraks agerande mildrade det. Personligen tycker jag att den här typen av åtgärder som svar på buggen var vettig; det begränsade skadan, gjorde användarna medvetna om risken och ledde till att den snabbt lappades.

LND var inte heller det enda som drabbades. Vätska peggingsprocessen bröts också, kräver uppdateringar av federationens funktionärer för att fixa det. Äldre versioner av Rust Bitcoin påverkades också, vilket gjorde att stallningen påverkade vissa blockutforskare och electrs-instanser (en implementering av backend-servern för Electrum Wallet). Nu, med undantag för att Liquids peg så småningom exponerar medel för de nödåterställningsnycklar som Blockstream innehar efter att ett tidslås har gått ut - och, realistiskt sett i den häktade filmintrigen där Blockstream stal dessa medel, vet alla exakt vem de ska gå efter - dessa andra problem sätter aldrig någons pengar i fara vid något tillfälle. Dessutom hade Rust Bitcoin faktiskt korrigerat denna specifika bugg i nyare versioner, vilket uppenbarligen inte ledde till någon kommunikation med underhållare av andra kodbaser för att belysa potentialen för sådana problem. Det var bara det aktiva utnyttjandet av felet live på nätverket som avslöjade att problemet fanns i flera kodbaser.

Detta väcker några stora problem när det kommer till sårbarheter som denna i Layer 2-programvara på Bitcoin. För det första, hur allvarligt dessa kodbaser granskas för säkerhetsbuggar och hur det prioriteras jämfört med integrationen av nya funktioner. Jag tycker att det är väldigt talande att säkerheten inte alltid prioriteras med tanke på att denna andra bugg inte ens hittades av underhållarna av kodbasen där den fanns, även om den bokstavligen låg precis bredvid den första buggen som upptäcktes förra månaden. Efter en stor bugg som satte användarnas pengar på spel, gjordes ingen intern revision av den kodbasen? Krävdes det någon utanför projektet för att upptäcka det? Det visar inte en prioritering för att skydda användarnas pengar framför att bygga nya funktioner för att dra in fler användare. För det andra visar det faktum att det här problemet redan var åtgärdat i Rust Bitcoin en brist på kommunikation mellan underhållare av olika kodbaser när det gäller buggar som detta. Detta är ganska förståeligt, eftersom att vara helt olika kodbaser inte får någon som hittade en bugg i en omedelbart att tänka: "Jag borde kontakta andra team som skriver liknande programvara på helt andra programmeringsspråk för att varna dem om potentialen för en sådan bugg .” Du hittar inte en bugg i Windows och tänker sedan omedelbart gå och rapportera felet till Linux-kärnunderhållare. Bitcoin som ett protokoll för distribuerad konsensus över ett globalt nätverk är dock en helt annan best; kanske Bitcoin-utvecklare borde börja tänka i de banorna när det kommer till sårbarheter i Bitcoin-programvara. Speciellt när det gäller att analysera och tolka data som är konsensusrelaterad.

Slutligen, kanske när det kommer till protokoll som Lightning, som är beroende av att observera blockkedjan hela tiden för att kunna reagera på gamla kanaltillstånd för att upprätthålla säkerheten, bör oberoende analys och verifiering av data hållas till ett absolut minimum – om inte tagits bort helt och delegerats till Bitcoin Core eller data som härrör direkt från den. Core Lightning är uppbyggd på detta sätt, ansluter till en instans av Bitcoin Core och är helt beroende av det för validering av block och transaktioner. Om LND fungerade på samma sätt, skulle ingen av dessa buggar i btcd ha påverkat LND-användare på ett sätt som sätter deras pengar på spel.

Oavsett hur saker hanteras – antingen outsourca validering helt eller helt enkelt minimera intern validering och närma sig den med mycket mer försiktighet – visar denna incident att något måste förändras när det gäller att närma sig frågan om hur Layer 2-programvaran hanterar interaktion med konsensusrelaterad data. Återigen har alla stor tur att detta inte utnyttjades av en illvillig skådespelare, utan istället av en utvecklare som bevisar en poäng. Som sagt, Bitcoin kan inte räkna med att ha tur eller hoppas att illvilliga aktörer inte existerar.

Utvecklare och användare bör vara fokuserade på att förbättra processerna för att förhindra att incidenter som detta händer igen, och inte spela spelet att kasta runt skulden som en het potatis.

Detta är ett gästinlägg av Shinobi. Åsikter som uttrycks är helt deras egna och återspeglar inte nödvändigtvis de från BTC Inc eller Bitcoin Magazine.