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

Analyse technique de CVE-2008-0166 dans Bitcoin 2009-2012, examinant les faiblesses du PRNG d'OpenSSL 0.9.8c, les défaillances d'entropie sous Windows et la reconstruction de l'espace de clés.

RandAddSeed (util.cpp:57-92) :

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

Génération de clés (key.h:75-78) :

Important : les versions 0.1.5 à 0.3.24 n'avaient aucun keypool. GetRand() utilise RAND_bytes(8) à d'autres fins (nonces réseau, pseudonymes IRC), perturbant ainsi l'état du PRNG entre les appels successifs à GenerateNewKey().

La version 0.4.0 (septembre 2011) a introduit TopUpKeyPool() avec un pool par défaut de 100 clés (GetArg("-keypool", 100)).

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

Le groupe THC (The Hackers Choice) a développé thc-btc-rng-bruteforce, en utilisant un OpenSSL 0.9.8c modifié. Trois changements critiques :

A. Introduction de THC_hitme() (md_rand.c:133-180)

• THC_hitme(0) : remet à zéro state_num, state_index, entropy, initialized, stirred_pool, md_count[0..1], md[], state[] — réinitialisation complète du PRNG.
• THC_hitme(pid) : stocke pid dans la variable statique thc_pid.

B. ssleay_rand_add() — contenu du buffer ignoré (ligne 344)

RAND_add avance toujours state_index de num et incrémente md_count[1], mais le contenu du buffer n'a aucun effet sur l'état du PRNG.

C. ssleay_rand_bytes() — substitution du PID (lignes 550-561)

• Appel original à getpid() supprimé.
• curr_pid = thc_pid — valeur constante issue de THC_hitme.
• Un MD_Update(&m, &curr_pid, sizeof(curr_pid)) supplémentaire injecte le PID comme seule entrée de variable externe.

Conclusion

Dans l'OpenSSL patché, l'état du PRNG dépend uniquement de :

1. La valeur du PID (via THC_hitme)
2. L'ordre et la taille des appels à RAND_add (paramètre num, pas le contenu du buffer)
3. Le nombre d'appels à RAND_bytes avant la génération de clés

4. Différence d'architecture : le32 vs le64

Dans OpenSSL 0.9.8c, BN_ULONG est défini par opensslconf.h :

Sur Linux 64 bits, OpenSSL utilise par défaut SIXTY_FOUR_BIT_LONG, changeant sizeof(BN_ULONG) de 4 à 8 octets. Cela affecte :

• La taille de static long md_count[2] (8 vs 16 octets)
• La représentation interne des bignums dans SHA
• L'intégralité du flux de sortie du PRNG

Vecteur de test SelfCheck de THC (profil 0.3.24, PID 31337) :

• le32 : 1FkLYqPpfKPAR6EZh2RC6sDwTUA6Axb1XQ
• le64 : 1JbxBrkBiSwpJUJN2bXrYJc51pH5rjrzTD

Bitcoin 2009 fonctionnait sous Windows XP 32 bits, donc une reconstruction correcte des clés nécessite une compilation avec THIRTY_TWO_BIT forcé (modifier include/openssl/opensslconf.h avant la compilation).

5. Le bug de Sergio Lerner (Bitcointalk 2012)

Dans un message du 27 septembre 2012 (topic=113496), Sergio Lerner décrivait :

(a) RandAddSeed() appelle QueryPerformanceCounter() — ce qui nécessite un alignement QWORD de son argument. Le compilateur gcc sous Windows pouvait échouer à aligner sur 8 octets la variable de pile, provoquant un échec silencieux.

(b) RegQueryValueExA(HKEY_PERFORMANCE_DATA, "Global", ...) utilise un buffer fixe de 250 000 octets. Sous Windows XP, les données de performance faisaient ~280 Ko — la fonction retournait ERROR_MORE_DATA et n'était jamais rappelée avec un buffer plus grand. debug.log ne contenait aucun avertissement.

Si les deux mécanismes échouaient, la seule source d'entropie était RAND_screen() (bitmap de l'écran). Dans l'OpenSSL patché, même RAND_screen est sans importance car le contenu du buffer est ignoré.

Lerner recommandait de journaliser ces échecs dans debug.log — ce correctif a été intégré dans les versions ultérieures de Bitcoin Core.

6. Évolution de l'init du RNG dans Bitcoin Core (2009-2012)

Vérifié dans bitcoin-code-r252 (tags : 0.1.5, 0.2.0, 0.3.0) et le dépôt bitcoin/bitcoin (tags : 0.3.24, 0.4.0, 0.5.0, 0.6.0) :

Principales conclusions

• RAND_screen() était utilisé sur toutes les versions de Windows jusqu'en 2012.
• Le keypool (100 clés pré-générées sans réinitialisation du PRNG) est apparu seulement dans la 0.4.0 — les versions antérieures généraient une clé par requête.
• Perfmon : la 0.1.5 utilisait SHA256(pdata) -> RAND_add(32), les versions ultérieures passaient pdata brut à RAND_add (une taille num différente compte dans l'OpenSSL patché car seule la taille, pas le contenu, affecte l'état).

7. Conclusions

L'espace de clés pour l'attaque (dans l'OpenSSL patché) :

Les paramètres tick, screen, cursor, hwnd, queue sont sans importance dans ce modèle car le contenu du buffer de RAND_add est ignoré.

Les auteurs originaux de THC ont écrit : « We did not find any. » — ils n'ont trouvé aucune clé sur la blockchain. L'analyse confirme leur conclusion : la probabilité qu'une clé vulnérable existe on-chain dépend entièrement du fait qu'un portefeuille Bitcoin ait réellement été généré sur un système Windows XP avec l'OpenSSL défectueux et le perfmon/QPC échouant silencieusement.

Références

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

[2] Bitcoin StackExchange — « Was Satoshi using Windows or Linux? » : lien

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

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

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

[6] Analiza_entropy_win.txt — rapport technique, 2026-09-10