Lightning Bugin hyödyntäminen oli eettinen valinta

Tämä on Shinobin mielipidetoimitus, itseoppinut Bitcoin-avaruuden kouluttaja ja tekniikkaan suuntautunut Bitcoin-podcast-isäntä.

Toisen kerran noin kuukauden sisällä btcd/LND:ssä on käytetty hyväksi virhettä, joka sai heidät poikkeamaan yksimielisesti Bitcoin Coresta. Jälleen kerran, Burak oli kehittäjä, joka laukaisi tämän haavoittuvuuden - tällä kertaa se oli selvästi tahallinen - ja jälleen kerran, se oli ongelma koodissa Bitcoin-tapahtumien jäsentämiseksi konsensuskerroksen yläpuolella. Kuten kirjoituksessani käsittelin pala edellisestä bugista jonka Burak laukaisi, ennen Taprootia oli rajoituksia sille, kuinka suuri käsikirjoitus ja todistajatiedot saattoivat olla tapahtumassa. Taprootin aktivoinnin myötä nämä rajoitukset poistettiin jättäen vain itse lohkokokorajoituksen rajoitukset yksittäisten tapahtumien näiden osien rajoittamiseksi. Viimeisimmän virheen ongelmana oli, että huolimatta siitä, että btcd:n konsensuskoodi päivitettiin oikein tämän muutoksen mukaan, vertaislähetystä käsittelevä koodi - mukaan lukien tietojen jäsentäminen ennen lähettämistä tai vastaanottoa - ei päivitetty kunnolla. Joten koodinkäsittelylohkot ja tapahtumat ennen kuin se tosiasiallisesti välitettiin varmennettavaksi konsensusta varten, epäonnistuivat tiedoissa, eivät koskaan siirtäneet sitä konsensuksen vahvistuslogiikkaan ja kyseistä lohkoa ei koskaan vahvistettu.

Hyvin samanlainen tapaus tapahtui tällä kertaa. Toinen rajoitus koodikannan peer-to-peer-osiossa oli todistajien tietojen virheellinen rajoitus rajoittamalla sen enintään 1/8 lohkon koosta, toisin kuin koko lohkon koko. Burak suunnitteli a kauppa todistajatiedoilla vain yksi painoyksikkö yli tiukan rajan ja jälleen pysähtyneet btcd- ja LND-solmut kyseiselle lohkokorkeudelle. Tämä tapahtuma oli epätyypillinen tapahtuma, mikä tarkoittaa, että vaikka se on täysin pätevä konsensussääntöjen mukaan, se ei ole kelvollinen oletusmuistikäytännön mukaan, joten solmut eivät välitä sitä verkon yli. Se on täysin mahdollista saada louhittu lohkoksi, mutta ainoa tapa tehdä se on toimittaa se suoraan kaivostyöläiselle, minkä Burak teki F2Poolin avulla.

Tämä todella ajaa ytimeen, että kaikki koodinpalat, joiden tarkoituksena on jäsentää ja validoida Bitcoin-tietoja, on tarkastettava voimakkaasti, jotta voidaan varmistaa, että se on linjassa Bitcoin Coren kanssa. Sillä ei ole väliä, onko kyseinen koodi solmutoteutuksen konsensusmoottori vai vain osa koodia, joka välittää tapahtumia Lightning-solmulle. Tämä toinen bugi oli kirjaimellisesti aivan viime kuun yläpuolella koodikannassa. Kukaan ei edes löytänyt sitä Lightning Labsissa. AJ Towns ilmoitti siitä 11. lokakuuta, kaksi päivää sen jälkeen, kun Burakin 998/999 multisig-tapahtuma laukaisi alkuperäisen virheen. Se oli julkaistu julkisesti Githubissa 10 tuntia ennen kuin se poistettiin. Sitten tehtiin korjaus, mutta sitä ei julkaistu, tarkoituksena korjata ongelma hiljaa seuraavassa LND-julkaisussa.

Nyt tämä on melko tavallinen menettely vakavalle haavoittuvuudelle, varsinkin Bitcoin Coren kaltaisessa projektissa, jossa tällainen haavoittuvuus voi itse asiassa aiheuttaa vakavaa vahinkoa peruskerroksen verkolle/protokollalle. Mutta tässä nimenomaisessa tapauksessa se aiheutti vakavan riskin LND-käyttäjien varoille, ja kun otetaan huomioon se tosiasia, että se oli kirjaimellisesti aivan edellisen virheen vieressä, jolla oli samat riskit, todennäköisyys, että se löydettäisiin ja sitä hyödynnettäisiin, oli erittäin korkea. kuten Burak osoitti. Tämä herättää kysymyksen siitä, onko hiljainen patch lähestymistapa oikea tapa edetä, kun kyse on tämänkaltaisista haavoittuvuuksista, jotka voivat jättää käyttäjät avoimeksi varojen varastamiselle (koska heidän solmunsa ei pysty havaitsemaan vanhoja kanavatiloja ja rankaisemaan niitä oikein).

Kuten menin viimeistä vikaa käsittelevässä artikkelissani, jos pahantahtoinen toimija olisi löytänyt virheet ennen hyvää tarkoittavaa kehittäjää, hän olisi voinut taktisesti avata uusia kanavia haavoittuville solmuille, reitittää kanavien koko sisällön takaisin itselleen ja sitten käyttänyt bugia hyväkseen. Sieltä heillä olisi nämä varat hallinnassaan ja he voisivat myös sulkea kanavan alkuperäisellä tilalla, kirjaimellisesti kaksinkertaistaen rahansa. Se, mitä Burak teki aktiivisesti hyödyntäessään tätä ongelmaa ironisella tavalla, suojeli LND-käyttäjiä tällaiselta hyökkäykseltä.

Kun sitä hyödynnettiin, käyttäjät olivat avoimia tällaisille hyökkäyksille jo olemassa olevilta käyttäjiltä, ​​joiden kanssa heillä oli jo avoimet kanavat, mutta he eivät enää pystyneet joutumaan erityisesti uusien kanavien kohteena. Heidän solmunsa pysähtyivät, eivätkä ne koskaan tunnista tai käsitteli maksuja kanavien kautta, joita joku yritti avata solmunsa pysäyttäneen lohkon jälkeen. Joten vaikka se ei poistanut kokonaan käyttäjien hyväksikäytön riskiä, ​​se rajoitti riskin ihmisiin, joiden kanssa heillä oli jo kanava. Burakin toiminta lievensi sitä. Henkilökohtaisesti uskon, että tämän tyyppinen toiminta vastauksena virheeseen oli järkevää; se rajoitti vahinkoa, sai käyttäjät tietoisiksi riskeistä ja johti sen nopeaan korjaamiseen.

LND ei myöskään ollut ainoa, joka vaikutti. Nesteitä myös kiinnitysprosessi katkesi, jotka vaativat päivityksiä liiton toimijoilta sen korjaamiseksi. Rust Bitcoinin vanhemmat versiot vaikuttivat myös, mikä sai pysähtymisen vaikuttamaan joihinkin lohkotutkijoihin ja electrs-instanssiin (Electrum Walletin taustapalvelimen toteutus). Lukuun ottamatta Liquidin kiinnitystä, joka lopulta paljastaa varat Blockstreamin hallussa oleville hätäpalautusavaimille aikalukon umpeutumisen jälkeen – ja realistisesti varkaustyylisessä elokuvajutussa, jossa Blockstream varasti nämä varat, kaikki tietävät tarkalleen, kenen perässä – nämä muut. asiat eivät koskaan vaaranna kenenkään varoja missään vaiheessa. Lisäksi Rust Bitcoin oli itse asiassa korjannut tämän vian uudemmissa versioissa, mikä ei ilmeisesti johtanut minkäänlaiseen kommunikointiin muiden koodikantojen ylläpitäjien kanssa tällaisten ongelmien potentiaalin korostamiseksi. Ainoastaan ​​verkossa tapahtuva bugin aktiivinen hyödyntäminen paljasti laajasti, että ongelma oli olemassa useissa koodikantoissa.

Tämä tuo esiin suuria ongelmia, kun kyse on tämän kaltaisista haavoittuvuuksista Bitcoinin Layer 2 -ohjelmistossa. Ensinnäkin, kuinka vakavasti nämä koodikannat tarkastetaan tietoturvavirheiden varalta ja kuinka se priorisoidaan uusien ominaisuuksien integrointiin verrattuna. Mielestäni on hyvin kuvaavaa, että turvallisuutta ei aina aseteta etusijalle, koska koodikannan ylläpitäjät eivät edes löytäneet tätä toista bugia, jossa se oli, vaikka se oli kirjaimellisesti aivan viime kuussa löydetyn alkuperäisen vian vieressä. Eikö koodikannan sisäistä tarkastusta tehty yhden suuren virheen jälkeen, joka vaaransi käyttäjien varat? Tarviiko joku projektin ulkopuolelta löytää se? Tämä ei osoita, että käyttäjien varojen turvaaminen on ensisijaisen tärkeää uusien ominaisuuksien rakentamisen sijaan, jotta se houkuttelee lisää käyttäjiä. Toiseksi se tosiasia, että tämä ongelma korjattiin jo Rust Bitcoinissa, osoittaa kommunikoinnin puutetta eri koodikantojen ylläpitäjien välillä koskien tämänkaltaisia ​​bugeja. Tämä on melko ymmärrettävää, sillä täysin erilaiset koodikannat eivät saa yhdestä vian löytäneestä heti ajattelemaan: "Minun pitäisi ottaa yhteyttä muihin tiimeihin, jotka kirjoittavat samanlaisia ​​ohjelmistoja täysin eri ohjelmointikielillä varoittaakseni heitä tällaisen virheen mahdollisuudesta." Et löydä vikaa Windowsista ja mieti heti, että ilmoittaisit virheestä Linux-ytimen ylläpitäjille. Bitcoin globaalissa verkossa hajautetun konsensuksen protokollana on kuitenkin hyvin erilainen peto; ehkä Bitcoin-kehittäjien pitäisi alkaa ajatella näitä linjoja, kun kyse on Bitcoin-ohjelmiston haavoittuvuuksista. Varsinkin kun on kyse konsensukseen liittyvien tietojen jäsentämisestä ja tulkinnasta.

Lopuksi, ehkä kun on kyse protokollista, kuten Lightning, jotka ovat riippuvaisia ​​lohkoketjun tarkkailusta jatkuvasti voidakseen reagoida vanhoihin kanavan tiloihin turvallisuuden ylläpitämiseksi, tietojen riippumaton jäsennys ja todentaminen tulisi pitää ehdottoman minimissä – jos ei poistettu kokonaan ja delegoitu Bitcoin Corelle tai suoraan siitä johdetulle tiedolle. Core Lightning on suunniteltu tällä tavalla yhdistäen Bitcoin Coren ilmentymään ja täysin riippuvaisesti siitä lohkojen ja tapahtumien validoinnissa. Jos LND toimisi samalla tavalla, kumpikaan näistä btcd:n virheistä ei olisi vaikuttanut LND-käyttäjiin tavalla, joka olisi vaarantanut heidän varat.

Riippumatta siitä, miten asioita käsitellään – joko ulkoistamalla validointi kokonaan tai yksinkertaisesti minimoimalla sisäisen validoinnin ja lähestymällä sitä paljon huolellisemmin – tämä tapaus osoittaa, että jotain on muutettava lähestyttäessä sitä, kuinka Layer 2 -ohjelmisto käsittelee vuorovaikutusta konsensukseen liittyvien tietojen kanssa. Jälleen kerran, kaikki ovat onnekkaita, että tätä ei käyttänyt hyväkseen pahantahtoinen toimija, vaan kehittäjä, joka todistaa asian. Tästä huolimatta Bitcoin ei voi luottaa siihen, että hänellä on onnea tai toivo, ettei pahantahtoisia toimijoita ole olemassa.

Kehittäjien ja käyttäjien tulisi keskittyä parantamaan prosesseja, jotta tällaiset tapaukset eivät toistuisi, eikä leikkiä syyllistämistä kuin kuumaa perunaa.

Tämä on Shinobin vieraspostaus. Esitetyt mielipiteet ovat täysin heidän omiaan eivätkä välttämättä vastaa BTC Inc:n tai Bitcoin Magazinen mielipiteitä.