Sfruttare il fulmine è stata la scelta etica

Questo è un editoriale di opinione di Shinobi, un educatore autodidatta nello spazio Bitcoin e host di podcast Bitcoin orientato alla tecnologia.

Per la seconda volta in circa un mese, btcd/LND ha subito lo sfruttamento di un bug che li ha portati a deviare nel consenso da Bitcoin Core. Ancora una volta, Burak è stato lo sviluppatore che ha attivato questa vulnerabilità – questa volta era chiaramente intenzionale – e ancora una volta si è trattato di un problema con il codice per l'analisi delle transazioni Bitcoin al di sopra del livello di consenso. Come ho discusso nel mio pezzo sul bug precedente che Burak ha attivato, prima di Taproot c'erano limiti sulla dimensione dello script e dei dati testimone in una transazione. Con l'attivazione di Taproot, tali limiti sono stati rimossi lasciando solo le limitazioni sulla dimensione del blocco stesso per limitare queste parti delle singole transazioni. Il problema con l'ultimo bug era che, nonostante il codice di consenso in btcd fosse stato aggiornato correttamente per riflettere questo cambiamento, il codice che gestiva la trasmissione peer-to-peer, inclusa l'analisi dei dati prima dell'invio o durante la ricezione, non veniva aggiornato correttamente. Quindi il codice che elabora i blocchi e le transazioni prima che venisse effettivamente spacciato per essere convalidato per il consenso non ha superato i dati, non li ha mai passati alla logica di convalida del consenso e il blocco in questione non è mai stato convalidato.

Questa volta è successa una cosa molto simile. Un altro limite nella sezione peer-to-peer del codebase era l'applicazione errata di una restrizione sui dati testimone, limitandoli a un massimo di 1/8 della dimensione del blocco rispetto alla dimensione completa del blocco. Burak ha realizzato a delle transazioni con i dati testimoni solo una singola unità di peso oltre il limite rigoroso e ancora una volta bloccati i nodi btcd e LND a quell'altezza del blocco. Questa transazione era una transazione non standard, il che significa che anche se è perfettamente valida secondo le regole di consenso, non è valida secondo la politica mempool predefinita e quindi i nodi non la trasmetteranno attraverso la rete. È perfettamente possibile inserirlo in un blocco, ma l'unico modo per farlo è fornirlo direttamente a un minatore, che è ciò che ha fatto Burak con l'aiuto di F2Pool.

Ciò porta davvero a capire che qualsiasi pezzo di codice il cui scopo è analizzare e convalidare i dati Bitcoin deve essere sottoposto a controlli approfonditi per garantire che sia in linea con ciò che farà Bitcoin Core. Non importa se quel codice è il motore di consenso per l'implementazione di un nodo o semplicemente un pezzo di codice che trasmette transazioni per un nodo Lightning. Questo secondo bug era letteralmente proprio sopra quello del mese scorso nella base di codice. Non è stato nemmeno scoperto da nessuno ai Lightning Labs. AJ Towns lo ha segnalato l'11 ottobre, due giorni dopo che il bug originale era stato attivato dalla transazione multisig 998 su 999 di Burak. È stato pubblicato pubblicamente su Github per 10 ore prima di essere eliminato. È stata quindi apportata una correzione, ma non rilasciata, con l'intenzione di correggere il problema nella prossima versione di LND.

Ora, questa è una procedura abbastanza standard per una vulnerabilità grave, specialmente con un progetto come Bitcoin Core in cui tale vulnerabilità può effettivamente causare gravi danni alla rete/protocollo di livello base. Ma in questo caso specifico, rappresentava un serio rischio per i fondi degli utenti della LND, e dato che era letteralmente accanto al bug precedente che presentava gli stessi rischi, le probabilità che venisse trovato e sfruttato erano molto alte, come dimostrato da Burak. Ciò solleva la questione se l’approccio quiet-patch sia la strada da percorrere quando si tratta di vulnerabilità come questa che possono lasciare gli utenti esposti al furto di fondi (perché il loro nodo non è in grado di rilevare i vecchi stati del canale e penalizzarli adeguatamente).

Come ho spiegato nel mio articolo sull'ultimo bug, se un utente malintenzionato avesse trovato i bug prima di uno sviluppatore ben intenzionato, avrebbe potuto aprire tatticamente nuovi canali ai nodi vulnerabili, reindirizzare l'intero contenuto di quei canali a se stesso e poi sfruttato il bug. Da lì avrebbero avuto quei fondi sotto il loro controllo e avrebbero anche potuto chiudere il canale con lo Stato iniziale, raddoppiando letteralmente i loro soldi. Ciò che Burak ha fatto, sfruttando attivamente questo problema in modo ironico, ha di fatto protetto gli utenti della LND da un simile attacco.

Una volta sfruttato, gli utenti erano esposti a tali attacchi da parte di colleghi preesistenti con cui avevano già canali aperti, ma non erano più in grado di essere presi di mira in modo specifico con nuovi canali. I loro nodi erano bloccati e non avrebbero mai riconosciuto o elaborato i pagamenti attraverso i canali che qualcuno aveva tentato di aprire dopo il blocco che aveva bloccato il loro nodo. Quindi, anche se non ha eliminato completamente il rischio che gli utenti venissero sfruttati, ha limitato tale rischio alle persone con cui avevano già un canale. L'azione di Burak l'ha mitigata. Personalmente penso che questo tipo di azione in risposta al bug avesse senso; ha limitato i danni, ha reso gli utenti consapevoli del rischio e ha portato a una rapida applicazione delle patch.

Anche la LND non è stata l’unica ad essere colpita. Quelli liquidi anche il processo di ancoraggio è stato interrotto, richiedendo aggiornamenti ai funzionari della federazione per risolverlo. Versioni precedenti di Rust Bitcoin sono stati colpiti, il che ha causato lo stallo ad influenzare alcuni block explorer e istanze di elettrici (un'implementazione del server backend per Electrum Wallet). Ora, con l'eccezione del peg di Liquid che alla fine espone i fondi alle chiavi di recupero di emergenza detenute da Blockstream dopo una scadenza temporale - e, realisticamente nella trama del film in stile rapina in cui Blockstream ha rubato questi fondi, tutti sanno esattamente a chi inseguire - questi altri i problemi non mettono mai a rischio i fondi di nessuno in nessun momento. Inoltre, Rust Bitcoin ha effettivamente corretto questo bug specifico nelle versioni più recenti, il che apparentemente non ha portato ad alcuna comunicazione con i manutentori di altri codebase per evidenziare il potenziale di tali problemi. È stato solo lo sfruttamento attivo del bug in rete a rivelare ampiamente che il problema esisteva in più codebase.

Ciò solleva alcuni grossi problemi quando si tratta di vulnerabilità come questa nel software Layer 2 su Bitcoin. Innanzitutto, la serietà con cui queste basi di codice vengono controllate per individuare eventuali bug di sicurezza e il modo in cui viene data la priorità rispetto all'integrazione di nuove funzionalità. Penso che sia molto significativo che la sicurezza non sia sempre una priorità dato che questo secondo bug non è stato nemmeno trovato dai manutentori del codice in cui era presente, anche se era letteralmente proprio accanto al bug iniziale scoperto il mese scorso. Dopo un grave bug che ha messo a rischio i fondi degli utenti, non è stato effettuato alcun controllo interno di quella base di codice? Ci è voluto qualcuno esterno al progetto per scoprirlo? Ciò non dimostra una priorità nel salvaguardare i fondi degli utenti rispetto alla creazione di nuove funzionalità per attirare più utenti. In secondo luogo, il fatto che questo problema sia già stato risolto in Rust Bitcoin dimostra una mancanza di comunicazione tra i manutentori di diverse basi di codice riguardo a bug come questo. Ciò è abbastanza comprensibile, poiché il fatto di avere basi di codice completamente diverse non fa sì che qualcuno che abbia trovato un bug in uno di essi pensi immediatamente: "Dovrei contattare altri team che scrivono software simile in linguaggi di programmazione completamente diversi per avvisarli del potenziale di un simile bug". Non trovi un bug in Windows e poi pensi immediatamente di andare a segnalare il bug ai manutentori del kernel Linux. Tuttavia, Bitcoin come protocollo per il consenso distribuito su una rete globale è una bestia molto diversa; forse gli sviluppatori Bitcoin dovrebbero iniziare a pensare in questo senso quando si tratta di vulnerabilità nel software Bitcoin. Soprattutto quando si tratta di analizzare e interpretare dati legati al consenso.

Infine, forse quando si tratta di protocolli come Lightning, che dipendono dall'osservazione costante della blockchain per poter reagire ai vecchi stati del canale al fine di mantenere la sicurezza, l'analisi indipendente e la verifica dei dati dovrebbero essere ridotte al minimo assoluto, se non rimossi interamente e delegati a Bitcoin Core o ai dati direttamente derivati ​​da esso. Core Lightning è architettato in questo modo, collegandosi a un'istanza di Bitcoin Core e dipendendo interamente da quella per la convalida di blocchi e transazioni. Se LND funzionasse allo stesso modo, nessuno di questi bug in btcd avrebbe influenzato gli utenti LND in modo tale da mettere a rischio i loro fondi.

In qualunque modo vengano gestite le cose – esternalizzando completamente la convalida o semplicemente riducendo al minimo la convalida interna e affrontandola con molta più attenzione – questo incidente mostra che qualcosa deve cambiare nell’affrontare la questione di come il software di livello 2 gestisce l’interazione con i dati relativi al consenso. Ancora una volta, tutti sono molto fortunati che questo non sia stato sfruttato da un utente malintenzionato, ma invece da uno sviluppatore che ha dimostrato qualcosa. Detto questo, Bitcoin non può contare sulla fortuna o sulla speranza che non esistano attori malintenzionati.

Gli sviluppatori e gli utenti dovrebbero concentrarsi sul miglioramento dei processi per evitare che incidenti come questo si ripetano e non sul gioco di gettare la colpa come una patata bollente.

Questo è un guest post di Shinobi. Le opinioni espresse sono interamente proprie e non riflettono necessariamente quelle di BTC Inc o Bitcoin Magazine.