Crash dumps from bitcoin-qt contain wallets #16824

On a crash, bitcoin-qt may dump a core file that contains what was in memory at the time of the crash, for debugging purposes. The problem here is that bitcoin-qt stores the user's wallet.dat unencrypted in memory. With this information it becomes rather trivial to reconstruct parts of a user's wallet.dat from a .core dump alone. You can find the wallets within the core file simply by grepping for known parts of a wallet.dat ex: xxd bitcoin-qt.core | grep "6231 0500" With this information you can find the offset of the wallet within the core file, and reconstruct it per a known wallet.dat's length. Upon reloading the extracted wallet into bitcoin-qt, you'll lose address book information - but balance is retained. This has been assigned CVE-2019-15947.

https://gist.github.com/oxagast/50a121b2df32186e0c48411859d5861b https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-15947

The wallet is stored on disk unencrypted and you can encrypt the wallet with the encryptwallet RPC

@oxagast First, thanks for putting time into trying to find flaws in Bitcoin Core - that is always appreciated :)

With that said: is the claim that this is a implementation bug or a design bug? I think the point @MarcoFalke is making is that the behaviour you are describing is by design.

To be clear: Bitcoin never makes crash dumps, that's the operating system doing that, if enabled. Crash dumps by design contain the entire address space, which might contain private keys.

Maybe there is a flag that could be set to disable crash dumps by default for the program?

Anyhow, there's a best-effort attempt to clear decrypted keys after use, if your wallet.dat is encrypted, see use of memory_cleanse. Even this can never be 100% effective as the application might crash at any time. If your wallet.dat is not encrypted, then parts of that file (including raw private keys) might be cached and are part of the memory and it's fully expected.

See also #15600

Maybe we should take just the DONTDUMP part?

MADV_DONTDUMP (Linux) and MAP_NOCORE (FreeBSD) is how libsodium avoids sensitive data being written to core dumps.

OpenBSD has MAP_CONCEAL since OpenBSD 6.5.

@practicalswift was this issue ever addressed? If it was could you kindly point me to the fixing commit? Please note that CVE-2019-15947 was assigned. Thanks in advance !

#15600 was merged a month ago

@MarcoFalke Thanks for the quick reply ! Have a good day :)