Un difetto di Core Lightning può mantenere i nodi in crash dopo un aggiornamento finché il trigger memorizzato non viene rimosso

Un difetto divulgato in Core Lightning, il software per la rete di pagamenti Lightning di Bitcoin, può lasciare un nodo in crash a ogni riavvio anche dopo un aggiornamento, perché l'annuncio dannoso che ha causato il crash rimane memorizzato su disco.

Il ricercatore Nishant Bansal ha divulgato il problema il 24 ottobre, identificando le versioni dalla v25.02 alla v26.04 come interessate. Una volta salvato l'annuncio, ogni riavvio ricarica lo stesso trigger, e Bansal afferma che l'operatore deve rimuovere manualmente il record incriminato per ripristinare il nodo.

Bitcoin Optech, una newsletter tecnica che segue gli sviluppi ingegneristici di Bitcoin, ha evidenziato il problema il 30 ottobre, ma la patch preventiva ha ormai diversi mesi. Core Lightning ha integrato la pull request #9082 il 24 aprile e ha rilasciato la correzione nella versione v26.04.1 il 25 aprile. La divulgazione di ottobre spiega quindi un difetto la cui correzione preventiva era disponibile da aprile.

Perché la patch non rimuove un trigger memorizzato

Gli annunci di canale comunicano ai nodi le connessioni nel grafo di routing Lightning. I pagamenti passano attraverso queste connessioni registrate, quindi ogni nodo di routing dipende da una copia accurata del grafo per spostare i fondi. In questo caso, un annuncio appositamente costruito indicava lo stesso nodo previously sconosciuto come entrambi gli endpoint. Il software vulnerabile lo ha accettato, l'ha scritto nel gossip_store su disco e lo ha quindi caricato nel grafo di routing.

Il grafo ha quindi tentato di inserire quel nodo due volte. Un meccanismo di salvaguardia contro i duplicati ha abortito gossipd, il componente che gestisce questi annunci, e Core Lightning ha trattato tale guasto come fatale per l'intero nodo.

La patch verifica l'ordine degli endpoint prima di accettare un annuncio. Richiedere che il primo ID nodo sia strettamente minore del secondo respinge anche gli ID uguali, impedendo che l'input malformato venga accettato e memorizzato in primo luogo.

La validazione si applica, tuttavia, solo agli annunci in arrivo. All'avvio vengono comunque letti i record già presenti nel gossip_store, e l'aggiornamento non rimuove un record dannoso salvato prima del crash. Ecco perché, secondo Bansal, il ripristino richiede la rimozione manuale del record dannoso dal gossip_store.

La sola pulizia lascia inoltre un'installazione vulnerabile esposta a un altro crash: secondo la divulgazione, un attaccante può inviare nuovamente lo stesso annuncio fintanto che l'output di finanziamento controllato dall'attaccante—l'output on-chain che ha aperto il canale—rimane non speso.

Esposizione via relay, indicazioni per l'aggiornamento e rischio di tempi di fermo

Bitcoin Optech nota che le versioni di Core Lightning precedenti alla v25.02 potevano accettare e inoltrare tali annunci senza andare loro stesse in crash. Un attaccante non necessitava quindi di una connessione diretta a ogni nodo vulnerabile, poiché un annuncio inoltrato viene girato ai peer di ciascun nodo e può portare il record malformato più a fondo nella rete.

Per gli operatori che scelgono di aggiornare ora, la v26.04.1 segna la prima versione contenente la correzione per questo difetto. Al 2 novembre, l'ultima versione del progetto è la v26.06.9, rilasciata il 7 ottobre, che i manutentori raccomandano vivamente di installare.

I tempi di fermo comportano un rischio di monitoraggio dei pagamenti oltre al servizio non disponibile. In Lightning, l'applicazione delle regole di canale spetta all'operatore del nodo. Bansal avverte che un nodo offline non può sorvegliare la blockchain per uno stato di canale revocato o per una richiesta di pagamento a tempo limitato che deve essere effettuata prima della scadenza. Perdere questi eventi può mettere a rischio i fondi.

Servizio originale: CryptoSlate