Core Lightning, una delle principali implementazioni software utilizzate per gestire i nodi di pagamento Lightning di Bitcoin, ha rilasciato la versione 26.06.10 con un nuovo set di correzioni di sicurezza, e i suoi manutentori chiedono a tutti gli utenti di aggiornare il prima possibile. L'aggiornamento abbina la patch software a un secondo compito per gli operatori: la revisione delle credenziali che consentono comandi remoti sui propri nodi, un passo che i manutentori descrivono come separato dall'installazione della nuova versione. Combinisce il rafforzamento del plugin che gestisce i comandi remoti con modifiche al modo in cui i nodi valutano le aperture di canale e le condizioni di pagamento.

Si tratta del terzo point release consecutivo pubblicato senza periodo di embargo. Le versioni 26.06.8 e 26.06.9 hanno seguito lo stesso approccio, con correzioni rese pubbliche immediatamente. Come per quei rilasci, i manutentori hanno di nuovo trattenuto i test legati alle correzioni di sicurezza. Secondo le note di rilascio, questo rende più difficile trasformare le correzioni in exploit funzionanti e concede agli utenti più tempo per aggiornarsi. Il modello di disclosure stabilisce inoltre le conseguenze per gli operatori: una volta che un rilascio è pubblico, lo sono anche le vulnerabilità che affronta, il che significa che un nodo in ritardo con gli aggiornamenti esegue software con difetti documentati.

Revisione delle credenziali aggiunta alla checklist di aggiornamento

Le rune e commando sono al centro del lavoro di sicurezza di questo aggiornamento. Commando consente a un peer direttamente connesso di chiedere a un nodo di eseguire un comando, e il peer generalmente necessita di una rune — una credenziale di autorizzazione — per farlo.

L'aggiornamento chiude un modo per aggirare i limiti delle rune sui nomi dei parametri tramite nomi duplicati o varianti con segni di punteggiatura. Corregge inoltre un crash di commando causato dal riutilizzo di un ID comando dopo un comando fallito. Le rune di dimensioni eccessive vengono ora rifiutate direttamente; in precedenza, il software poteva impiegare tempo quadratico per decodificarle.

I manutentori raccomandano di vincolare ogni rune utilizzata tramite commando al node ID dell'app che la usa. Con questa restrizione id in atto, la rune non può essere utilizzata da nessun altro luogo. Gli operatori sono inoltre invitati a mettere in blacklist tutte le rune di cui non possono rendere conto utilizzando il comando blacklistrune, per poi emettere nuove rune con restrizioni più rigorose. Letti insieme, i passaggi costituiscono un audit di ogni credenziale che può attivare comandi remoti su un nodo, con le rune inspiegate revocate prima dell'emissione delle sostitutive.

Correzioni per canali e pagamenti

La nuova versione verifica le firme delle transazioni di un peer durante l'apertura di canali con finanziamento dual-funded e lo splicing, l'operazione che adegua i fondi di un canale senza chiuderlo. Ciò è in linea con la specifica BOLT 2 del protocollo Lightning, che copre la creazione dei canali e il normale funzionamento peer-to-peer, secondo il changelog.

Un'altra correzione riguarda un contratto di pagamento condizionale noto come HTLC. Un HTLC appena rimosso poteva essere confuso con uno attivo che condivideva il suo payment hash, l'importo e la scadenza, causando il fallimento del pagamento attivo da parte del nodo mentre il peer poteva comunque riscuoterlo.

La gestione delle aperture di canale è anche più severa. I nodi ora rifiutano le aperture di canale quando un peer propone un dust limit — la soglia sotto la quale gli output sono trattati come dust — superiore a 5.000 satoshi; il changelog spiega che il vecchio comportamento permetteva a un peer di ridurre il saldo del nodo a commissioni durante una chiusura forzata. Per le aperture dual-funded, viene rifiutato anche il dust limit di un peer superiore alla riserva del canale, e un'apertura v2 zero-conferma — un canale che va attivo prima che la sua transazione di finanziamento sia confermata — viene rifiutata a meno che l'operatore non abbia impostato il nodo per accettarla da quel peer. Il dual funding rimane sperimentale, e i manutentori sconsigliano i canali zero-conferma con peer non affidabili.

Altre modifiche forniscono una risposta predefinita sicura quando un hook di plugin fallisce, invece di un crash o un blocco. Gli incrementi delle commissioni di splice ora utilizzano almeno 25/24 del feerate precedente, come richiesto da peer come Eclair. I nodi che hanno eseguito build di sviluppo non possono effettuare il downgrade alla serie 26.06.x perché il loro schema di database è più recente. Il rilascio include binari riproducibili per Ubuntu 22.04, 24.04 e 26.04, oltre a immagini Docker.

Disclosure e tempistiche di rilascio

Le vulnerabilità corrette in questo rilascio sono state segnalate da quasi 20 fonti nominate, tra cui The Bitcoin Red Team, Matt Morehouse e Niklas Gögge. Altre hanno chiesto di non essere nominate.

GitHub indica una data di rilascio del 4 novembre per la versione, mentre il changelog taggato mostra l'11月 5 novembre. L'aggiornamento fa seguito a un separato crash da trigger memorizzato reso noto il 2 novembre. Al momento della redazione, bitcoin veniva scambiato vicino a 76.002 dollari, con un calo del 5,29% in 24 ore.