Can Bitcoin Core be compromised by Heartbleed - are private keys exposed? - How?

[Rampion]

Some questions about Heartbleed and Bitcoin Core:

• Could somebody describe how the attack would work if somebody had been using Bitcoin Core 0.9.0 and clicked on a "bitcoin:" link?
  
• Could the private keys be compromised even if I generated the "bitcoin:" link myself and clicked it just to see how the new payment function worked?
• In that case, how the private keys would have been exposed? Because of a MITM? How would it work?
• Would the wallet be considered compromised if I clicked on a "bitcoin:" link but didn't go through the payment, and thus I did not sign any transaction?

I just cannot wrap my head around it yet.

[wumpus]

bitcoin: links can contain a link to a payment request (starting from 0.9), either on http or https. A merchant could thus make your client fetch a payment request from a hostile SSL server. Due to the nature of the OpenSSL heartbleed bug it may leak up to 64k of memory to that server. If this memory happens to contain private keys, you leak private keys.

It is unlikely, but possible, so upgrading to 0.9.1 is strongly encouraged.

If you only used your own bitcoin: URIs (that do not request a payment request from a https server) you're safe.

[gmaxwell]

Also, RPC SSL. If you don't know what it is, you're not using it, though.

I've tested the RPC SSL pretty extensively with this attack and was unable to get it to leak anything more private than the prior rpc request.  This isn't surprising, OpenSSL basically has its own allocator and doesn't free memory.  While I can't promise that there isn't some crazy sequence of operations that makes it leak something else in the RPC case, it appears unlikely and I was unable to get it to do so in practice.

I wasn't able to get a fake SSL server working to try triggering it in the payment protocol case. I would hope expect the behavior to be similar there, but since I haven't even tested it I'm less confident.

[Gavin Andresen]

https://github.com/Lekensteyn/pacemaker is a little SSL server to test SSL clients for heartbleed vulnerability.

I installed Bitcoin Core version 0.9.0 on my Mac (compiled against the vulnerable openssl 1.0.1f), created a web page to launch a payment request fetch from pacemaker...

... and I get good news:

Code:

Connection from: 127.0.0.1:62937
Possibly not vulnerable

Step-by-step so you can help test on other OS'es :

• git clone https://github.com/Lekensteyn/pacemaker.git
• cd pacemaker
• python pacemaker.py
• Run Bitcoin Core GUI version 0.9.0
• In your browser, visit https://bitcoincore.org/~gavin/heartbleed.html  

pacemaker.py should report a connection, and then either say "Client returned blah bytes" or "Possibly not vulnerable"

It looks to me like pacemaker.py IS working; visiting https://127.0.0.1:4433/ in Chrome pacemaker tells me:

Code:

Connection from: 127.0.0.1:62514
Client returned 7 (0x7) bytes
0000: 15 03 03 00 02 02 2f                             ....../

This isn't a definitive "no need to worry even if you HAVE clicked on payment-protocol-enabled bitcoin: links at an untrustworthy website" ... but given the evidence I've seen, it seems to me extremely unlikely anybody's private keys have been compromised.

[defaced]

Thanks for clearing it all up fellas.

[Rampion]

Wumpus, Gregory, Gavin: Thank you very much for your efforts. You are all doing a GREAT job, it has to be said!

[piotr_n]

FWIW, I absolutely disagree with how the openssl team solved the heartbleed bug.
Fist of all, the very issue of the problem originates not at this change, but at this one (or maybe even sooner, when they introduced an internal memory heap, to the library).
"Memory saving patch" - really?
This guy wrapped it up very well: http://article.gmane.org/gmane.os.openbsd.misc/211963

Had they not introduced the own heap to openssl in the first place, this heartbleed bug would have been causing memory access violation and the issue would be spotted long ego.
Moreover, the only reason for a security lib to have its own heap manager is to provide more security - meaning: make sure to clear all the memory while freeing it.
What this heap does instead is actually making sure that no memory is being cleared, no matter how you had built the lib!
So whatever buffer you allocate, in whatever function, there is a decent change that you will get it filled with some crucial data, like a private key used just a moment ago.
And therefore, knowing life, I am pretty certain that there are also other functions that leak the private data from openssl's internal heap - its just a matter of time before someone finds them.

The proper way to fix that issue was by fixing the internal heap (make it to clear the memory while being freed), or just removing it because it wasn't necessary in the first place.
But definitively not just fixing it like this, abstracting from the actual original cause.

At the other hand, it is a developer's (who uses this lib) duty to clear up all the crucial data from the memory, before freeing any buffer that would contain it, and preferably even sooner; as soon as the crucial data isn't needed anymore.
But apparently only few developers actually do that and bitcoin core devels don't seem to be on that list... at last as far as I had checked this code.
So, shame on you too!

[Loozik]

Is this attack vector is possible?

1. Someone infects your computer with malware / you download malware yourself.

2. The purpose of this malware is to maintain an SSL connection between your computer and the attacker server or the purpose of this malware is to trigger such an SSL connection once every few hours.

3. Through this malware-induced SSL connection the attacker gains access to your RAM data on constant or periodical basis.

[dserrano5]

3. Through this malware-induced SSL connection the attacker gains access to your RAM data on constant or periodical basis.

Only the memory of the affected process is dumped, the rest of the system is safe.

Unless the process runs with elevated privileges but in that case you don't need a vulnerable openssl to win.

[Loozik]

Only the memory of the affected process is dumped, the rest of the system is safe.

So if the affected process happens to be firefox.exe then the attacker would get the passwords I use to login to exchanges and webmails, etc?

[Gavin Andresen]

On further testing, it looks like OSX and Linux payment protocol requests with the released 0.9.0 binaries are not vulnerable.

The released Windows 0.9.0 binaries are vulnerable, so Wladimir just sent an alert message urging everybody running 0.9.0 to upgrade.

But apparently only few developers actually do that and bitcoin core devels don't seem to be on that list... at last as far as I had checked this code.
So, shame on you too!

Check again; see the use of CKeyingMaterial/CPrivKey which uses a secure_allocator (which asks the operating system not to swap the memory to disk, and which zeros memory on free). If I recall correctly, the RPC importprivkey should be the only place where the normal memory allocator is used (the keys exist as ordinary hex strings in memory before they are processed by the importprivkey code).

Careful review (and testing and patches) is always welcome, of course. You shouldn't trust my famously faulty memory.

[piotr_n]

But apparently only few developers actually do that and bitcoin core devels don't seem to be on that list... at last as far as I had checked this code.
So, shame on you too!

Check again; see the use of CKeyingMaterial/CPrivKey which uses a secure_allocator (which asks the operating system not to swap the memory to disk, and which zeros memory on free). If I recall correctly, the RPC importprivkey should be the only place where the normal memory allocator is used (the keys exist as ordinary hex strings in memory before they are processed by the importprivkey code).

I see. Sorry - my bad.
Shame on me, then!

Well in such a case, the consequences of the vulnerability should not be so big after all, even if exploited.
If the keys are not left there, on the heap, no attacker can get them.
At the other hand to be really sure, one would need to dig into the actual openssl code, and audit that nowhere there such "secured" memory gets copied into some intermediate buffers. I mean, during any of the operations that involve some secret (priv key or a password).