Il 28 ottobre Bitcoin Core ha pubblicato tre security advisory su bug individuati da una scansione automatica con un modello linguistico, tutti corretti nelle versioni 29.5, 30.4, 31.2 e 32.1. Due consentono a un peer malevolo di riempire la memoria di un nodo fino al suo spegnimento, mentre il terzo permette di mandare in crash con facilità qualsiasi nodo che non giri su Linux.
Bug 1: dati TCP urgent su Windows, macOS e BSD
Sulle piattaforme diverse da Linux, Bitcoin Core monitora i socket con un backend basato su select(). Secondo l'advisory di Bitcoin Core, quel backend controllava le condizioni eccezionali anche quando la lettura da un peer era in pausa.
Un peer poteva inviare dati TCP urgent (out-of-band) per aggirare il meccanismo di backpressure e mettere in coda una quantità illimitata di dati. In pratica, un peer malevolo può mandare in crash con facilità qualsiasi nodo Windows, macOS o BSD a cui è connesso.
- Gravità: Medium, classificato come facilmente individuabile
- I nodi Linux non sono colpiti, perché usano poll()
- Identificato il 23 ottobre, PR #36665 aperta da Antoine Poinsot il 26 ottobre
Bug 2: crescita lenta della memoria con peer pre-BIP31
Bitcoin Core mette in coda gli annunci, soprattutto gli INV delle transazioni, per tutti i peer, anche quelli in pausa. I peer che non rispondono a un ping con nonce entro 20 minuti vengono disconnessi, ma questa regola non vale per i peer che non supportano BIP 31, spiega la seconda advisory.
Un attaccante può fingere di non supportare BIP 31 e ritardare in modo strategico la lettura dei messaggi, lasciando crescere la coda senza limiti.
- Crescita della memoria: fino a 2 MB all'ora per peer in entrata e 5 MB all'ora per peer in uscita
- I nodi avviati con -blocksonly sono molto meno colpiti
- Gravità Medium; scoperto da Loupe il 15 settembre e riscoperto in modo indipendente da L0rinc il 21 settembre
Bug 3: overflow dei file undo
Un miner può produrre blocchi validi i cui dati undo sono molto più grandi dei blocchi stessi, abbastanza da portare un singolo file rev*.dat oltre i 4 GiB. Le posizioni erano salvate come interi a 32 bit, quindi i nuovi dati undo sovrascrivono quelli più vecchi: se una reorg colpisce poi un blocco interessato, il nodo non riesce a leggerlo e si spegne, spiega la terza advisory. Riavviare non serve: per il recupero occorre un -reindex con una versione corretta.
Su Windows e sui sistemi a 32 bit il limite è di 2 GiB e non serve alcuna reorg: il nodo non riesce a scrivere i dati undo e si spegne a ogni riavvio.
- Gravità: Low; sfruttarlo su sistemi a 64 bit non è praticabile
- Un attaccante dovrebbe minare diverse migliaia di blocchi, circa un mese della produzione dell'intera rete
- I sistemi a 32 bit e i nodi che salvano i blocchi su FAT32 restano colpiti anche dopo il fix
- Segnalato da Loupe l'8 luglio, poi in modo indipendente da L0rinc (21 agosto) e Andrew Dorman (23 ottobre)
Chi li ha trovati e perché sono già pubblici
Tutti e tre i bug sono emersi da una scansione automatica con LLM nell'ambito di Project Loupe, guidato da Elias Rohrer di Spiral. Gregory Sanders ha validato i risultati e li ha passati al team di sicurezza di Bitcoin Core.
La policy di Bitcoin Core definisce facilmente individuabili le vulnerabilità trovate con il minimo sforzo, per esempio con un semplice prompt a un LLM. In questi casi il team rilascia una point release con la correzione per ogni versione major mantenuta, più un'advisory, senza il periodo di embargo standard.
Con la tempistica normale, i bug di gravità Medium e High vengono divulgati due settimane dopo che l'ultima versione interessata raggiunge la fine del supporto, circa un anno dopo la prima versione major che contiene il fix.
Versioni corrette | Data di rilascio |
|---|---|
31.2 e 32.1 | 27 ottobre 2026 |
29.5 e 30.4 | 28 ottobre 2026 |