Bitcoin-qt.exe/bitcoind.exe mantains partial wallet password in memory after wallet password timeout #6924

Some time after unlocking my bitcoin wallet for a transaction I checked the wallet lock status icon and the tooltip indicated that my wallet was locked and encrypted.

Browsing the bitcoin-qt.exe process memory using a tool such as HxD though, shows that part of the wallet password was still in memory.

This could potentially be an issue if a remote exploit is found in bitcoin-qt/bitcoind that allows a remote attacker to read the bitcoin-qt process memory. As a user I expected my locked wallet to not have its password exposed somewhere in process memory.

Is it possible to clear all traces of the password in memory after use? I'm not sure how easy/feasible this is, just a thought.

Platform: Windows 10 Bitcoin Core Version 0.11.1

This is something the application tries very hard to avoid internally. Passwords and key material should always be stored in clear-after-use memory.

However, it's not possible to do this across the entire library stack. It is very likely that Qt or your underlying graphics maintains text entered in password entry fields in regular string-like data structures.

Does this also happen with bitcoind?

I haven't checked this on bitcoind. I will give this a try later.

Yes, this also seems to occur with bitcoind.exe. Examining the bitcoind.exe process memory after setting the wallet password via bitcoin-cli.exe shows the password after password timeout.

I didn't expect the bitcoind result to be different, personally-- as I pointed out during the concern about heartbleed, the prior json rpc request was being left in memory in openssl alone. I wouldn't be surprised if boost asio were doing the same things.

The JSON/HTTP stack will leave (parts of) requests on the heap. Same for the GUI. It is impossible for a fixed string to not leak into memory at any point, especially not consistent over platforms. A hammer solution on Linux is to set mallopt(M_PERTURB). This will overwrite all memory when allocated and when deallocated. That will impact performance (not something we'll do for the entire process by default) and still leaves the stack (per thread) to contend with.

You could also scan the entire memory space periodically using e.g. some moving hash window and wipe the passphrase when found in inactive memory :-) (but mind the the passphrase may still be there in some other form, such as a list of keyboard scancodes ..)

A less fragile (and more serious) solution would be to use, instead of a fixed passphrase, a challenge/response system between a) a sandboxed signing process b) the API client / a secure GUI overlay. This is the only way that has any chance to mitigate remote memory contents leaking.

The feature request didn't seem to attract much attention in the past. Also, the issue seems not important enough right now to keep it sitting around idle in the list of open issues.

Closing due to lack of interest. Pull requests with improvements are always welcome.