Å utnytte lynfeilen var det etiske valget

Dette er en meningsredaksjon av Shinobi, en selvlært pedagog i Bitcoin-området og teknologiorientert Bitcoin-podcastvert.

For andre gang på omtrent en måned har btcd/LND fått en feil utnyttet som fikk dem til å avvike i konsensus fra Bitcoin Core. Nok en gang var Burak utvikleren som utløste denne sårbarheten – denne gangen var det tydeligvis med vilje – og nok en gang var det et problem med kode for å analysere Bitcoin-transaksjoner over konsensuslaget. Som jeg diskuterte i min stykke på forrige feil som Burak utløste, før Taproot var det begrensninger på hvor stort manus og vitnedata i en transaksjon kunne være. Med aktiveringen av Taproot ble disse grensene fjernet, og bare begrensningene for blokkstørrelsen i seg selv for å begrense disse delene av individuelle transaksjoner. Problemet med den siste feilen var at til tross for at konsensuskoden i btcd ble riktig oppgradert for å gjenspeile denne endringen, oppgraderte ikke koden som håndterer peer-to-peer-overføring – inkludert parsing av data før sending eller mottak – på riktig måte. Så kodebehandlingsblokkene og transaksjonene før de faktisk ble sendt for å bli validert for konsensus mislyktes i dataene, sendte dem aldri til konsensusvalideringslogikken og den aktuelle blokken ble aldri validert.

En veldig lignende ting skjedde denne gangen. En annen grense i peer-to-peer-delen av kodebasen var å håndheve en begrensning på vitnedata på feil måte, og begrense den til maksimalt 1/8 av blokkstørrelsen i motsetning til full blokkstørrelse. Burak laget en Transaksjonen med vitnedata bare en enkelt vektenhet over den strenge grensen og igjen stoppet btcd- og LND-noder i den blokkhøyden. Denne transaksjonen var en ikke-standard transaksjon, noe som betyr at selv om den er perfekt gyldig i henhold til konsensusregler, er den ikke gyldig i henhold til standard mempool-policy, og noder vil derfor ikke videresende den over nettverket. Det er fullt mulig å få det utvunnet i en blokk, men den eneste måten å gjøre det på er å gi det direkte til en gruvearbeider, noe Burak gjorde ved hjelp av F2Pool.

Dette fører virkelig til poenget at enhver kode som har som formål å analysere og validere Bitcoin-data må revideres grundig for å sikre at den er i tråd med hva Bitcoin Core vil gjøre. Det spiller ingen rolle om den koden er konsensusmotoren for en nodeimplementering eller bare et stykke kode som sender transaksjoner rundt for en Lightning-node. Denne andre feilen var bokstavelig talt rett over den fra forrige måned i kodebasen. Det ble ikke engang oppdaget av noen på Lightning Labs. AJ Towns rapporterte det 11. oktober, to dager etter at den opprinnelige feilen ble utløst av Buraks 998-av-999 multisig-transaksjon. Den ble publisert på Github i 10 timer før den ble slettet. En reparasjon ble deretter laget, men ikke utgitt, med den hensikt å stille om problemet i neste utgivelse av LND.

Nå er dette ganske standardprosedyre for en alvorlig sårbarhet, spesielt med et prosjekt som Bitcoin Core hvor en slik sårbarhet faktisk kan forårsake alvorlig skade på baselagets nettverk/protokoll. Men i dette spesifikke tilfellet utgjorde det en alvorlig risiko for LND-brukeres midler, og gitt det faktum at det bokstavelig talt var rett ved siden av den forrige feilen som hadde samme risiko, var sjansene for at den ville bli funnet og utnyttet svært høye, som demonstrert av Burak. Dette reiser spørsmålet om stille-patch-tilnærmingen er veien å gå når det kommer til sårbarheter som dette som kan gjøre brukere åpne for tyveri av midler (fordi noden deres er ute av stand til å oppdage gamle kanaltilstander og straffe dem riktig).

Som jeg gikk inn på i min del om den siste feilen, hvis en ondsinnet aktør hadde funnet feilene før en velmenende utvikler, kunne de taktisk ha åpnet nye kanaler til sårbare noder, rutet hele innholdet i disse kanalene tilbake til seg selv og deretter utnyttet feilen. Derfra ville de ha disse midlene under sin kontroll og også vært i stand til å lukke kanalen med den opprinnelige staten, bokstavelig talt doble pengene sine. Det Burak gjorde ved å aktivt utnytte dette problemet på en ironisk måte, beskyttet faktisk LND-brukere mot et slikt angrep.

Når det først ble utnyttet, var brukere åpne for slike angrep fra eksisterende jevnaldrende som de allerede hadde åpne kanaler med, men de var ikke lenger i stand til å bli målrettet spesifikt med nye kanaler. Nodene deres ble stoppet og ville aldri gjenkjenne eller behandle betalinger gjennom kanaler noen prøvde å åpne etter blokkeringen som stoppet noden deres. Så selv om det ikke helt fjernet risikoen for at brukere ble utnyttet, begrenset det risikoen til personer de allerede hadde en kanal med. Buraks handling dempet det. Personlig synes jeg denne typen handling som svar på feilen var fornuftig; det begrenset skaden, gjorde brukerne oppmerksomme på risikoen og førte til at den raskt ble lappet.

LND var heller ikke det eneste som ble rammet. Væske pegging-prosessen ble også brutt, som krever oppdateringer til forbundets funksjonærer for å fikse det. Eldre versjoner av Rust Bitcoin ble også berørt, noe som førte til at stallen påvirket noen blokkutforskere og electrs-forekomster (en implementering av backend-serveren for Electrum Wallet). Nå, med unntak av Liquids pinne som til slutt utsetter midler for nødgjenopprettingsnøklene som Blockstream har etter utløpet av en tidslås – og realistisk sett i filmplottet der Blockstream stjal disse midlene, vet alle nøyaktig hvem de skal gå etter – disse andre problemer setter aldri noens midler i fare på noe tidspunkt. Dessuten hadde Rust Bitcoin faktisk rettet denne spesifikke feilen i nyere versjoner, noe som tilsynelatende ikke førte til noen kommunikasjon med vedlikeholdere av andre kodebaser for å synliggjøre potensialet for slike problemer. Det var bare den aktive utnyttelsen av feilen live på nettverket som avslørte at problemet eksisterte i flere kodebaser.

Dette bringer opp noen store problemer når det kommer til sårbarheter som dette i Layer 2-programvare på Bitcoin. For det første hvor alvorlig disse kodebasene blir revidert for sikkerhetsfeil, og hvordan det prioriteres kontra integrering av nye funksjoner. Jeg synes det er veldig talende at sikkerhet ikke alltid er prioritert gitt at denne andre feilen ikke en gang ble funnet av vedlikeholderne av kodebasen der den var til stede, selv om den bokstavelig talt var rett ved siden av den første feilen som ble oppdaget forrige måned. Etter en stor feil som satte brukernes midler i fare, ble ingen intern revisjon av den kodebasen utført? Det tok noen utenfor prosjektet for å oppdage det? Det viser ikke en prioritering for å sikre brukernes midler fremfor å bygge nye funksjoner for å trekke inn flere brukere. For det andre viser det faktum at dette problemet allerede var rettet i Rust Bitcoin mangel på kommunikasjon på tvers av vedlikeholdere av forskjellige kodebaser med hensyn til feil som dette. Dette er ganske forståelig, siden det å være helt forskjellige kodebaser ikke får noen som fant en feil i en umiddelbart til å tenke: "Jeg bør kontakte andre team som skriver lignende programvare på helt forskjellige programmeringsspråk for å advare dem om potensialet for en slik feil." Du finner ikke en feil i Windows og tenker umiddelbart å rapportere feilen til Linux-kjernevedlikeholdere. Bitcoin som en protokoll for distribuert konsensus over et globalt nettverk er imidlertid et helt annet beist; kanskje Bitcoin-utviklere bør begynne å tenke i de baner når det gjelder sårbarheter i Bitcoin-programvare. Spesielt når det gjelder å analysere og tolke data som er konsensusrelatert.

Til slutt, kanskje når det gjelder protokoller som Lightning, som er avhengig av å observere blokkjeden til enhver tid for å kunne reagere på gamle kanaltilstander for å opprettholde sikkerheten, bør uavhengig parsing og verifisering av data holdes på et absolutt minimum – hvis ikke fjernet fullstendig og delegert til Bitcoin Core eller data direkte avledet fra den. Core Lightning er bygget på denne måten, kobler til en forekomst av Bitcoin Core og er helt avhengig av det for validering av blokker og transaksjoner. Hvis LND fungerte på samme måte, ville ingen av disse feilene i btcd ha påvirket LND-brukere på en måte som satt pengene deres i fare.

Uansett hvordan ting håndteres – enten å outsource validering helt eller ganske enkelt minimere intern validering og tilnærme seg den med mye mer forsiktighet – viser denne hendelsen at noe må endres når man nærmer seg spørsmålet om hvordan Layer 2-programvare håndterer samhandling med konsensusrelaterte data. Nok en gang er alle veldig heldige at dette ikke ble utnyttet av en ondsinnet skuespiller, men i stedet av en utvikler som beviste et poeng. Når det er sagt, kan Bitcoin ikke regne med å være heldig eller håpe på at ondsinnede aktører ikke eksisterer.

Utviklere og brukere bør fokusere på å forbedre prosessene for å forhindre at hendelser som dette skjer igjen, og ikke spille spillet med å kaste skylden som en varm potet.

Dette er et gjesteinnlegg av Shinobi. Uttrykte meninger er helt deres egne og reflekterer ikke nødvendigvis meningene til BTC Inc eller Bitcoin Magazine.