Välkvea ärakasutamine oli eetiline valik

See on Bitcoini ruumi iseõppinud koolitaja ja tehnoloogiale orienteeritud Bitcoini taskuhäälingusaate hosti Shinobi arvamustoimetus.

Teist korda umbes kuu aja jooksul on btcd/LND-s kasutatud viga, mille tõttu nad kaldusid Bitcoin Core'ist üksmeelselt kõrvale. Taaskord oli Burak arendaja, kes selle haavatavuse käivitas – seekord oli see selgelt tahtlik – ja taas oli probleem Bitcoini tehingute parsimise koodiga konsensuskihi kohal. Nagu ma oma artiklis arutasin tükk eelnevast veast mille Burak käivitas, olid enne Taprooti piirangud tehingu skripti ja tunnistajaandmete suurusele. Taprooti aktiveerimisega need piirangud eemaldati, jättes üksikute tehingute nende osade piiramiseks ainult ploki suuruse piirangu enda piirangud. Viimase veaga seotud probleem seisnes selles, et hoolimata asjaolust, et btcd konsensuskood oli selle muudatuse kajastamiseks korralikult uuendatud, ei uuendatud võrdõiguslikku edastamist käsitlev kood, sealhulgas andmete sõelumine enne saatmist või vastuvõtmist, korralikult. Nii et kooditöötlusplokid ja tehingud, enne kui need konsensuse jaoks valideerimiseks tegelikult edastati, ebaõnnestusid andmetes, ei edastanud neid kunagi konsensuse valideerimise loogikale ja kõnealust plokki ei õnnestunud kunagi kinnitada.

Seekord juhtus väga sarnane lugu. Teine piirang koodibaasi peer-to-peer sektsioonis oli tunnistajate andmetele piirangu jõustamine valesti, piirates seda maksimaalselt 1/8 ploki suurusest erinevalt ploki täissuurusest. Burak meisterdas a tehing tunnistajate andmetega vaid üks kaaluühik üle range piirangu ja jällegi seiskusid btcd ja LND sõlmed sellel ploki kõrgusel. See tehing oli mittestandardne tehing, mis tähendab, et kuigi see konsensusreeglite järgi on täiesti kehtiv, ei kehti see mempooli vaikepoliitika kohaselt ja seetõttu ei edasta sõlmed seda üle võrgu. See on täiesti võimalik saada plokki kaevandada, kuid ainus viis seda teha on anda see otse kaevandajale, mida Burak F2Pooli abiga tegi.

See toob tõesti kaasa mõtte, et iga kooditükki, mille eesmärk on Bitcoini andmete sõelumine ja kinnitamine, tuleb põhjalikult auditeerida, et tagada selle vastavus Bitcoin Core'i tegevusele. Pole tähtis, kas see kood on sõlme juurutamise konsensusmootor või lihtsalt kooditükk, mis edastab välksõlme tehinguid. See teine ​​viga oli sõna otseses mõttes otse üle eelmise kuu oma koodibaasis. Seda ei avastanud isegi keegi Lightning Labsis. AJ Towns teatas sellest 11. oktoobril, kaks päeva pärast seda, kui Buraki 998/999 multisig-tehing käivitas esialgse vea. Enne kustutamist postitati see avalikult Githubisse 10 tundi. Seejärel tehti parandus, kuid seda ei avaldatud, eesmärgiga probleem vaikselt LND järgmises versioonis parandada.

Nüüd on see üsna tavaline protseduur tõsise haavatavuse jaoks, eriti sellise projekti puhul nagu Bitcoin Core, kus selline haavatavus võib tegelikult põhjustada põhikihi võrgule/protokollile tõsist kahju. Kuid antud konkreetsel juhul kujutas see endast tõsist ohtu LND kasutajate rahalistele vahenditele ja arvestades asjaolu, et see asus sõna otseses mõttes samade riskidega eelmise vea kõrval, oli tõenäosus, et see leitakse ja seda ära kasutatakse, väga suur. nagu näitas Burak. See tekitab küsimuse, kas vaikse paiga lähenemisviis on õige tee, kui tegemist on selliste haavatavustega, mis võivad jätta kasutajad avatuks raha vargustele (kuna nende sõlm ei suuda tuvastada vanu kanali olekuid ja neid korralikult karistada).

Nagu ma oma viimast viga käsitlevas kirjatükis käsitlesin, kui pahatahtlik näitleja oleks vead leidnud enne heade kavatsustega arendajat, oleks ta võinud taktikaliselt avada uusi kanaleid haavatavatele sõlmedele, suunata kogu nende kanalite sisu enda juurde ja seejärel kasutas viga ära. Sealt oleksid nad need vahendid oma kontrolli all ja saaksid ka kanali esialgse seisuga sulgeda, sõna otseses mõttes kahekordistades oma raha. See, mida Burak selle probleemi iroonilisel viisil aktiivselt ära kasutas, kaitses tegelikult LND kasutajaid sellise rünnaku eest.

Pärast selle ärakasutamist olid kasutajad avatud sellistele rünnakutele juba olemasolevate eakaaslaste poolt, kellega neil juba olid avatud kanalid, kuid neid ei saanud enam uute kanalite abil konkreetselt sihtida. Nende sõlmed olid seiskunud ega tuvastanud ega töötle kunagi makseid kanalite kaudu, mida keegi üritas pärast sõlme seiskunud plokki avada. Ehkki see ei kõrvaldanud täielikult kasutajate ärakasutamise ohtu, piiras see seda ohtu inimestele, kellega neil juba kanal oli. Buraki tegevus leevendas seda. Isiklikult arvan, et selline tegevus vastuseks veale oli mõistlik; see piiras kahju, muutis kasutajad riskist teadlikuks ja viis selle kiire parandamiseni.

LND ei olnud ka ainus, mida see mõjutas. Vedelik ka sidumisprotsess katkes, mille parandamiseks on vaja föderatsiooni funktsionääridelt värskendusi. Rust Bitcoini vanemad versioonid mõjutasid ka, mistõttu seiskumine mõjutas mõningaid plokiuurijaid ja elektrijuhte (Electrum Walleti taustaserveri rakendus). Nüüd, välja arvatud Liquidi sidumine, mis pärast ajaluku aegumist lõpuks Blockstreami käes olevatele hädaolukorra taastamise võtmetele paljastab – ja reaalselt varguste stiilis filmisüžees, kus Blockstream need raha varastas, teavad kõik täpselt, kelle taha minna – need teised probleemid ei sea kunagi kellegi raha ohtu. Samuti oli Rust Bitcoin selle konkreetse vea uuemates versioonides parandanud, mis ilmselt ei viinud suhtlemiseni teiste koodibaaside hooldajatega, et rõhutada selliste probleemide potentsiaali. See oli vaid vea aktiivne kasutamine võrgus, mis tõi laialdaselt esile, et probleem eksisteeris mitmes koodibaasis.

See toob esile mõned suured probleemid, kui tegemist on Bitcoini kihi 2 tarkvara haavatavustega. Esiteks, kui tõsiselt neid koodibaase turvavigade suhtes auditeeritakse ja kuidas seda prioriteediks seatakse võrreldes uute funktsioonide integreerimisega. Minu arvates on väga kõnekas, et turvalisust ei seata alati esikohale, kuna seda teist viga ei leidnud isegi selle koodibaasi hooldajad, kus see esines, kuigi see oli sõna otseses mõttes eelmisel kuul avastatud esialgse vea kõrval. Kas pärast ühte suurt viga, mis seadis kasutajate raha ohtu, ei tehtud selle koodibaasi siseauditit? Kas selle avastamiseks oli vaja kedagi väljastpoolt projekti? See ei näita kasutajate raha kaitsmise prioriteeti uute funktsioonide loomisel, et meelitada rohkem kasutajaid. Teiseks näitab tõsiasi, et see probleem oli Rust Bitcoinis juba paigatud, erinevate koodibaaside hooldajate vahelise suhtluse puudumist selliste vigade osas. See on üsna arusaadav, sest täiesti erinevad koodibaasid ei pane kedagi, kes ühes vea avastas, kohe mõtlema: "Ma peaksin võtma ühendust teiste meeskondadega, kes kirjutavad sarnast tarkvara täiesti erinevates programmeerimiskeeltes, et hoiatada neid sellise vea võimalikkuse eest." Sa ei leia Windowsis viga ja siis mõtled kohe, et annad veast teada Linuxi kerneli hooldajatele. Bitcoin kui globaalses võrgus hajutatud konsensuse protokoll on siiski väga erinev loom; võib-olla peaksid Bitcoini arendajad hakkama mõtlema Bitcoini tarkvara haavatavuste osas samamoodi. Eriti kui tegemist on konsensusega seotud andmete sõelumise ja tõlgendamisega.

Lõpuks, kui tegemist on protokollidega nagu Lightning, mis sõltuvad plokiahela pidevast jälgimisest, et saaksid turvalisuse säilitamiseks reageerida vanadele kanali olekutele, tuleks andmete sõltumatu sõelumine ja kontrollimine viia absoluutse miinimumini – kui ei eemaldata täielikult ja delegeeritakse Bitcoin Core'ile või sellest otseselt tuletatud andmetele. Core Lightning on sel viisil üles ehitatud, ühendudes Bitcoin Core'i eksemplariga ja sõltudes täielikult sellest plokkide ja tehingute valideerimiseks. Kui LND töötaks samamoodi, poleks kumbki neist btcd vigadest mõjutanud LND kasutajaid viisil, mis seaks nende raha ohtu.

Olenemata sellest, kuidas asju käsitletakse – kas valideerimise täielik väljastpoolt hankimine või lihtsalt sisemise valideerimise minimeerimine ja sellele palju hoolikamalt lähenemine – näitab see juhtum, et 2. kihi tarkvara käsitlemisel konsensusega seotud andmetega suhtlemisel tuleb midagi muuta. Taaskord on kõigil väga vedanud, et seda ei kasutanud ära pahatahtlik näitleja, vaid hoopis asja tõestanud arendaja. Nagu öeldud, ei saa Bitcoin loota, et tal veab või loodab, et pahatahtlikke tegureid pole olemas.

Arendajad ja kasutajad peaksid keskenduma protsesside täiustamisele, et vältida selliste vahejuhtumite kordumist, ja mitte mängima seda mängu, et süüdistada nagu kuuma kartulit.

See on Shinobi külalispostitus. Avaldatud arvamused on täielikult nende omad ja ei pruugi kajastada BTC Inc või Bitcoin Magazine'i arvamusi.