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

Análise técnica da CVE-2008-0166 no Bitcoin 2009-2012, examinando as fraquezas do PRNG do OpenSSL 0.9.8c, falhas de entropia no Windows e reconstrução do espaço de chaves.

RandAddSeed (util.cpp:57-92):

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

Geração de chaves (key.h:75-78):

Importante: as versões 0.1.5 até 0.3.24 não tinham keypool. GetRand() usa RAND_bytes(8) para outros propósitos (nonces de rede, apelidos de IRC), assim perturbando o estado do PRNG entre chamadas sucessivas de GenerateNewKey().

A versão 0.4.0 (setembro de 2011) introduziu TopUpKeyPool() com um pool padrão de 100 chaves (GetArg("-keypool", 100)).

3. O Patch: make-OpenSSL-0-9-8c-vulnerable-again.diff

O grupo THC (The Hackers Choice) desenvolveu o thc-btc-rng-bruteforce, usando um OpenSSL 0.9.8c modificado. Três mudanças críticas:

A. Introdução de THC_hitme() (md_rand.c:133-180)

• THC_hitme(0): zera state_num, state_index, entropy, initialized, stirred_pool, md_count[0..1], md[], state[] — reset completo do PRNG.
• THC_hitme(pid): armazena pid na variável estática thc_pid.

B. ssleay_rand_add() — conteúdo do buffer ignorado (linha 344)

RAND_add ainda avança state_index em num e incrementa md_count[1], mas o conteúdo do buffer não tem efeito no estado do PRNG.

C. ssleay_rand_bytes() — substituição de PID (linhas 550-561)

• Chamada original de getpid() removida.
• curr_pid = thc_pid — valor constante de THC_hitme.
• MD_Update(&m, &curr_pid, sizeof(curr_pid)) adicional injeta o PID como a única entrada de variável externa.

Conclusão

No OpenSSL com patch, o estado do PRNG depende apenas de:

1. Valor do PID (via THC_hitme)
2. Ordem e tamanho das chamadas RAND_add (parâmetro num, não o conteúdo do buffer)
3. Número de chamadas RAND_bytes antes da geração de chaves

4. Diferença de Arquitetura: le32 vs le64

No OpenSSL 0.9.8c, BN_ULONG é definido por opensslconf.h:

No Linux 64-bit, o OpenSSL usa SIXTY_FOUR_BIT_LONG por padrão, alterando sizeof(BN_ULONG) de 4 para 8 bytes. Isso afeta:

• Tamanho de static long md_count[2] (8 vs 16 bytes)
• Representação interna de bignum no SHA
• O fluxo de saída inteiro do PRNG

Vetor de Teste SelfCheck do THC (perfil 0.3.24, PID 31337):

• le32: 1FkLYqPpfKPAR6EZh2RC6sDwTUA6Axb1XQ
• le64: 1JbxBrkBiSwpJUJN2bXrYJc51pH5rjrzTD

O Bitcoin 2009 rodava no Windows XP 32-bit, então a reconstrução correta de chaves requer compilação com THIRTY_TWO_BIT forçado (edite include/openssl/opensslconf.h antes de compilar).

5. O Bug de Sergio Lerner (Bitcointalk 2012)

Em um post de 27 de setembro de 2012 (topic=113496), Sergio Lerner descreveu:

(a) RandAddSeed() chama QueryPerformanceCounter() — requer alinhamento QWORD de seu argumento. O compilador gcc no Windows poderia falhar em alinhar a variável de pilha em 8 bytes, causando falha silenciosa.

(b) RegQueryValueExA(HKEY_PERFORMANCE_DATA, "Global", ...) usa um buffer fixo de 250.000 bytes. No Windows XP, os dados de performance eram ~280 KB — a função retornava ERROR_MORE_DATA e nunca era chamada novamente com um buffer maior. O debug.log não continha nenhum aviso.

Se ambos os mecanismos falhassem, a única fonte de entropia era RAND_screen() (bitmap da tela). No OpenSSL com patch, até RAND_screen é irrelevante porque o conteúdo do buffer é ignorado.

Lerner recomendou registrar essas falhas no debug.log — essa correção foi incorporada em versões posteriores do Bitcoin Core.

6. Evolução da Inicialização do RNG no Bitcoin Core (2009-2012)

Verificado em bitcoin-code-r252 (tags: 0.1.5, 0.2.0, 0.3.0) e no repositório bitcoin/bitcoin (tags: 0.3.24, 0.4.0, 0.5.0, 0.6.0):

Principais Descobertas

• RAND_screen() foi usado em todas as versões do Windows até 2012.
• O keypool (100 chaves pré-geradas sem reset do PRNG) apareceu apenas na 0.4.0 — versões anteriores geravam uma chave por requisição.
• Perfmon: a 0.1.5 usava SHA256(pdata) -> RAND_add(32), versões posteriores passavam pdata bruto para RAND_add (tamanho num diferente importa no OpenSSL com patch porque apenas o tamanho, não o conteúdo, afeta o estado).

7. Conclusões

O espaço de chaves para o ataque (no OpenSSL com patch):

Os parâmetros tick, screen, cursor, hwnd, queue são irrelevantes neste modelo porque o conteúdo do buffer de RAND_add é ignorado.

Os autores originais do THC escreveram: "We did not find any." — eles não encontraram nenhuma chave na blockchain. A análise confirma sua descoberta: a probabilidade de uma chave vulnerável existir on-chain depende inteiramente de se alguma carteira Bitcoin foi realmente gerada em um sistema Windows XP com o OpenSSL quebrado e perfmon/QPC falhando silenciosamente.

Referências

[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