CVE-2008-0166-BTC-satoshi-mining-wallets

Analisi tecnica di CVE-2008-0166 in Bitcoin 2009-2012, esaminando le debolezze del PRNG di OpenSSL 0.9.8c, i fallimenti di entropia di Windows e la ricostruzione dello spazio delle chiavi.

RandAddSeed (util.cpp:57-92):

• QueryPerformanceCounter -> RAND_add(&PerformanceCount, 8, 1.5)
• RegQueryValueEx(HKEY_PERFORMANCE_DATA, "Global", ..., buf=250000) -> if ERROR_SUCCESS: SHA256(pdata) -> RAND_add(&hash, 32, entropy)

Generazione delle chiavi (key.h:75-78):

Importante: le versioni dalla 0.1.5 alla 0.3.24 non avevano keypool. GetRand() usa RAND_bytes(8) per altri scopi (nonce di rete, nickname IRC), perturbando così lo stato del PRNG tra chiamate successive a GenerateNewKey().

La versione 0.4.0 (settembre 2011) introdusse TopUpKeyPool() con un pool predefinito di 100 chiavi (GetArg("-keypool", 100)).

3. La patch: make-OpenSSL-0-9-8c-vulnerable-again.diff

Il gruppo THC (The Hackers Choice) sviluppò thc-btc-rng-bruteforce, utilizzando una versione modificata di OpenSSL 0.9.8c. Tre modifiche critiche:

A. Introduzione di THC_hitme() (md_rand.c:133-180)

• THC_hitme(0): azzera state_num, state_index, entropy, initialized, stirred_pool, md_count[0..1], md[], state[] — reset completo del PRNG.
• THC_hitme(pid): memorizza pid nella variabile statica thc_pid.

B. ssleay_rand_add() — contenuto del buffer ignorato (riga 344)

RAND_add avanza comunque state_index di num e incrementa md_count[1], ma il contenuto del buffer non ha alcun effetto sullo stato del PRNG.

C. ssleay_rand_bytes() — sostituzione del PID (righe 550-561)

• Chiamata originale a getpid() rimossa.
• curr_pid = thc_pid — valore costante da THC_hitme.
• Un ulteriore MD_Update(&m, &curr_pid, sizeof(curr_pid)) inietta il PID come unico input variabile esterno.

Conclusione

Nell'OpenSSL modificato, lo stato del PRNG dipende solo da:

1. Valore del PID (tramite THC_hitme)
2. Ordine e dimensione delle chiamate a RAND_add (parametro num, non il contenuto del buffer)
3. Numero di chiamate a RAND_bytes prima della generazione delle chiavi

4. Differenza di architettura: le32 vs le64

In OpenSSL 0.9.8c, BN_ULONG è definito da opensslconf.h:

Su Linux a 64 bit, OpenSSL usa per impostazione predefinita SIXTY_FOUR_BIT_LONG, cambiando sizeof(BN_ULONG) da 4 a 8 byte. Questo influisce su:

• Dimensione di static long md_count[2] (8 vs 16 byte)
• Rappresentazione interna dei bignum in SHA
• L'intero flusso di output del PRNG

Vettore di test SelfCheck di THC (profilo 0.3.24, PID 31337):

• le32: 1FkLYqPpfKPAR6EZh2RC6sDwTUA6Axb1XQ
• le64: 1JbxBrkBiSwpJUJN2bXrYJc51pH5rjrzTD

Bitcoin 2009 girava su Windows XP 32-bit, quindi la corretta ricostruzione delle chiavi richiede la compilazione con THIRTY_TWO_BIT forzato (modificare include/openssl/opensslconf.h prima della build).

5. Il bug di Sergio Lerner (Bitcointalk 2012)

In un post del 27 settembre 2012 (topic=113496), Sergio Lerner descrisse:

(a) RandAddSeed() chiama QueryPerformanceCounter() — richiede l'allineamento a QWORD del suo argomento. Il compilatore gcc su Windows poteva non allineare a 8 byte la variabile sullo stack, causando un fallimento silenzioso.

(b) RegQueryValueExA(HKEY_PERFORMANCE_DATA, "Global", ...) usa un buffer fisso di 250.000 byte. Su Windows XP, i dati sulle prestazioni erano ~280 KB — la funzione restituiva ERROR_MORE_DATA e non veniva mai più chiamata con un buffer più grande. debug.log non conteneva alcun avviso.

Se entrambi i meccanismi fallivano, l'unica fonte di entropia era RAND_screen() (bitmap dello schermo). Nell'OpenSSL modificato persino RAND_screen è irrilevante perché il contenuto del buffer viene ignorato.

Lerner raccomandò di registrare questi fallimenti in debug.log — questa correzione fu incorporata nelle versioni successive di Bitcoin Core.

6. Evoluzione dell'inizializzazione dell'RNG in Bitcoin Core (2009-2012)

Verificato in bitcoin-code-r252 (tag: 0.1.5, 0.2.0, 0.3.0) e nel repository bitcoin/bitcoin (tag: 0.3.24, 0.4.0, 0.5.0, 0.6.0):

Risultati chiave

• RAND_screen() fu usato su tutte le versioni di Windows fino al 2012.
• Il keypool (100 chiavi pre-generate senza reset del PRNG) apparve solo nella 0.4.0 — le versioni precedenti generavano una chiave per richiesta.
• Perfmon: la 0.1.5 usava SHA256(pdata) -> RAND_add(32), le versioni successive passavano pdata grezzo a RAND_add (una dimensione num diversa conta nell'OpenSSL modificato perché solo la dimensione, non il contenuto, influisce sullo stato).

7. Conclusioni

Lo spazio delle chiavi per l'attacco (nell'OpenSSL modificato):

I parametri tick, screen, cursor, hwnd, queue sono irrilevanti in questo modello perché il contenuto del buffer di RAND_add viene ignorato.

Gli autori originali di THC scrissero: "We did not find any." — non trovarono alcuna chiave sulla blockchain. L'analisi conferma il loro risultato: la probabilità che esista una chiave vulnerabile on-chain dipende interamente dal fatto che qualche wallet Bitcoin sia stato effettivamente generato su un sistema Windows XP con l'OpenSSL difettoso e perfmon/QPC che fallivano silenziosamente.

Riferimenti

[1] Sergio Lerner, "Possible new vulnerability: poor entropy in Windows generated keypairs", Bitcointalk 2012-09-27: link

[2] Bitcoin StackExchange — "Was Satoshi using Windows or Linux?": link

[3] THC, thc-btc-rng-bruteforce: link

[4] Bitcoin Core tags (0.1.5, 0.2.0, 0.3.0, 0.3.24, 0.4.0, 0.5.0, 0.6.0): link

[5] OpenSSL 0.9.8c + patch make-OpenSSL-0-9-8c-vulnerable-again.diff

[6] Analiza_entropy_win.txt — technical report, 2026-09-10