Udnyttelse af lynfejlen var det etiske valg

Dette er en meningsredaktion af Shinobi, en selvlært underviser i Bitcoin-området og teknologiorienteret Bitcoin-podcastvært.

For anden gang på omkring en måned har btcd/LND fået udnyttet en fejl, som fik dem til at afvige i konsensus fra Bitcoin Core. Endnu en gang var Burak udvikleren, der udløste denne sårbarhed - denne gang var det tydeligvis med vilje - og igen var det et problem med kode til at parse Bitcoin-transaktioner over konsensuslaget. Som jeg diskuterede i min stykke på den tidligere fejl som Burak udløste, før Taproot var der grænser for, hvor store script- og vidnedata i en transaktion kunne være. Med aktiveringen af ​​Taproot blev disse grænser fjernet, hvilket kun efterlod begrænsningerne på selve blokstørrelsesgrænsen for at begrænse disse dele af individuelle transaktioner. Problemet med den sidste fejl var, at på trods af, at konsensuskoden i btcd var korrekt opgraderet for at afspejle denne ændring, opgraderede koden, der håndterede peer-to-peer-transmission - inklusive parsing af data før afsendelse eller modtagelse - ikke korrekt. Så kodebearbejdningsblokkene og -transaktionerne, før de rent faktisk blev videregivet til at blive valideret for konsensus, svigtede dataene, sendte dem aldrig til konsensusvalideringslogikken, og den pågældende blok blev aldrig valideret.

En meget lignende ting skete denne gang. En anden grænse i peer-to-peer sektionen af ​​kodebasen var at håndhæve en begrænsning på vidnedata forkert, begrænse den til maksimalt 1/8 af blokstørrelsen i modsætning til den fulde blokstørrelse. Burak lavede en transaktion med vidnedata kun en enkelt vægtenhed over den strenge grænse og igen stoppede btcd- og LND-noder i den blokhøjde. Denne transaktion var en ikke-standard transaktion, hvilket betyder, at selvom den er perfekt gyldig ifølge konsensusregler, er den ikke gyldig i henhold til standard mempool-politik, og derfor vil noder ikke videresende den på tværs af netværket. Det er udmærket muligt at få det udvundet i en blok, men den eneste måde at gøre det på er at give det direkte til en minearbejder, hvilket Burak gjorde ved hjælp af F2Pool.

Dette fører virkelig til pointen, at ethvert stykke kode, hvis formål er at parse og validere Bitcoin-data, skal revideres kraftigt for at sikre, at det er i overensstemmelse med, hvad Bitcoin Core vil gøre. Det er ligegyldigt, om denne kode er konsensusmotoren for en nodeimplementering eller bare et stykke kode, der sender transaktioner rundt for en Lightning-node. Denne anden fejl var bogstaveligt talt lige over den fra sidste måned i kodebasen. Det blev ikke engang opdaget af nogen på Lightning Labs. AJ Towns rapporterede det den 11. oktober, to dage efter den oprindelige fejl blev udløst af Buraks 998-af-999 multisig-transaktion. Det blev offentliggjort på Github i 10 timer, før det blev slettet. En rettelse blev derefter lavet, men ikke frigivet, med den hensigt stille og roligt at lappe problemet i den næste udgivelse af LND.

Nu er dette en ret standardprocedure for en alvorlig sårbarhed, især med et projekt som Bitcoin Core, hvor en sådan sårbarhed faktisk kan forårsage alvorlig skade på basislagets netværk/protokol. Men i dette specifikke tilfælde udgjorde det en alvorlig risiko for LND-brugeres midler, og i betragtning af, at det bogstaveligt talt var lige ved siden af ​​den tidligere fejl, der havde de samme risici, var chancerne for, at det ville blive fundet og udnyttet meget høje, som påvist af Burak. Dette rejser spørgsmålet om, hvorvidt den stille patch-tilgang er vejen at gå, når det kommer til sårbarheder som denne, der kan efterlade brugere åbne for tyveri af midler (fordi deres node er ude af stand til at opdage gamle kanaltilstande og straffe dem korrekt).

Som jeg gik ind på i mit stykke om den sidste fejl, hvis en ondsindet aktør havde fundet fejlene før en velmenende udvikler, kunne de taktisk have åbnet nye kanaler til sårbare noder, dirigeret hele indholdet af disse kanaler tilbage til sig selv og derefter udnyttede fejlen. Derfra ville de have disse midler under deres kontrol og også være i stand til at lukke kanalen med den oprindelige tilstand, bogstaveligt talt fordoble deres penge. Hvad Burak gjorde ved aktivt at udnytte dette problem på en ironisk måde, beskyttede faktisk LND-brugere mod et sådant angreb.

Når det først blev udnyttet, var brugere åbne over for sådanne angreb fra allerede eksisterende peers, som de allerede havde åbne kanaler med, men de var ikke længere i stand til at blive målrettet specifikt med nye kanaler. Deres noder var gået i stå og ville aldrig genkende eller behandle betalinger gennem kanaler, som nogen forsøgte at åbne efter blokeringen, der stoppede deres node. Så selvom det ikke helt fjernede risikoen for, at brugere blev udnyttet, begrænsede det den risiko til folk, de allerede havde en kanal med. Buraks handling mildnede det. Personligt synes jeg, at denne type handling som reaktion på fejlen gav mening; det begrænsede skaden, gjorde brugerne opmærksomme på risikoen og førte til, at den hurtigt blev lappet.

LND var heller ikke det eneste, der blev ramt. Væske pegging-processen blev også brudt, der kræver opdateringer til forbundets funktionærer for at rette det. Ældre versioner af Rust Bitcoin blev også påvirket, hvilket fik stallingen til at påvirke nogle blokudforskere og electrs-instanser (en implementering af backend-serveren til Electrum Wallet). Nu, med undtagelse af Liquids pind, der til sidst udsætter midler for nødgendannelsesnøglerne, som Blockstream besidder efter udløbet af en tidslås - og realistisk set i det røveriagtige filmplot, hvor Blockstream stjal disse midler, ved alle præcis, hvem de skal gå efter - disse andre problemer sætter aldrig nogens penge i fare på noget tidspunkt. Også Rust Bitcoin havde faktisk rettet denne specifikke fejl i nyere versioner, hvilket tilsyneladende ikke førte til nogen kommunikation med vedligeholdere af andre kodebaser for at fremhæve potentialet for sådanne problemer. Det var kun den aktive udnyttelse af fejlen live på netværket, der i vid udstrækning afslørede, at problemet eksisterede i flere kodebaser.

Dette bringer nogle store problemer op, når det kommer til sårbarheder som denne i Layer 2-software på Bitcoin. For det første den seriøsitet, hvormed disse kodebaser revideres for sikkerhedsfejl, og hvordan det prioriteres i forhold til integrationen af ​​nye funktioner. Jeg synes, det er meget sigende, at sikkerhed ikke altid prioriteres, da denne anden fejl ikke engang blev fundet af vedligeholderne af kodebasen, hvor den var til stede, selvom den bogstaveligt talt var lige ved siden af ​​den oprindelige fejl, der blev opdaget i sidste måned. Efter en stor fejl, der satte brugernes midler i fare, blev der ikke foretaget en intern revision af den kodebase? Det tog nogen uden for projektet at opdage det? Det viser ikke en prioritet til at sikre brugernes midler frem for at bygge nye funktioner for at tiltrække flere brugere. For det andet viser det faktum, at dette problem allerede var rettet i Rust Bitcoin, en mangel på kommunikation på tværs af vedligeholdere af forskellige kodebaser med hensyn til fejl som denne. Dette er ret forståeligt, da det at være helt forskellige kodebaser ikke får nogen, der har fundet en fejl i en, med det samme til at tænke: "Jeg bør kontakte andre hold, der skriver lignende software på helt andre programmeringssprog for at advare dem om potentialet for en sådan fejl." Du finder ikke en fejl i Windows og tænker derefter straks på at rapportere fejlen til Linux-kernevedligeholdere. Bitcoin som en protokol for distribueret konsensus på tværs af et globalt netværk er dog et meget anderledes dyr; Måske bør Bitcoin-udviklere begynde at tænke i de baner, når det kommer til sårbarheder i Bitcoin-software. Især når det kommer til at parse og fortolke data, der er konsensusrelateret.

Til sidst, måske når det kommer til protokoller som Lightning, der er afhængige af at observere blockchain til enhver tid for at kunne reagere på gamle kanaltilstande for at opretholde sikkerheden, bør uafhængig parsing og verifikation af data holdes på et absolut minimum - hvis ikke fjernet fuldstændigt og uddelegeret til Bitcoin Core eller data direkte afledt derfra. Core Lightning er opbygget på denne måde, forbinder til en forekomst af Bitcoin Core og afhænger helt af det til validering af blokke og transaktioner. Hvis LND fungerede på samme måde, ville ingen af ​​disse fejl i btcd have påvirket LND-brugere på en måde, der satte deres penge i fare.

Uanset hvordan tingene håndteres – enten at outsource validering helt eller blot minimere intern validering og gribe den an med meget mere omhu – viser denne hændelse, at noget skal ændres i forhold til spørgsmålet om, hvordan Layer 2-software håndterer interaktion med konsensus-relaterede data. Endnu en gang er alle meget heldige, at dette ikke blev udnyttet af en ondsindet skuespiller, men i stedet af en udvikler, der beviser en pointe. Når det er sagt, kan Bitcoin ikke regne med at være heldig eller håbe på, at ondsindede aktører ikke eksisterer.

Udviklere og brugere bør fokusere på at forbedre processerne for at forhindre hændelser som denne i at ske igen, og ikke spille spillet med at kaste skylden rundt som en varm kartoffel.

Dette er et gæsteindlæg af Shinobi. Udtalte meninger er helt deres egne og afspejler ikke nødvendigvis dem fra BTC Inc eller Bitcoin Magazine.