Bitcoin Forum
July 16, 2024, 03:27:50 PM *
News: Latest Bitcoin Core release: 27.0 [Torrent]
 
   Home   Help Search Login Register More  
Pages: [1]
  Print  
Author Topic: Can Bitcoin Core be compromised by Heartbleed - are private keys exposed? - How?  (Read 2772 times)
Rampion (OP)
Legendary
*
Offline Offline

Activity: 1148
Merit: 1018


View Profile
April 09, 2014, 10:51:24 AM
Last edit: April 11, 2014, 01:44:52 AM by gmaxwell
 #1

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
Hero Member
*****
qt
Offline Offline

Activity: 812
Merit: 1022

No Maps for These Territories


View Profile
April 09, 2014, 11:24:46 AM
 #2

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.


Bitcoin Core developer [PGP] Warning: For most, coin loss is a larger risk than coin theft. A disk can die any time. Regularly back up your wallet through FileBackup Wallet to an external storage or the (encrypted!) cloud. Use a separate offline wallet for storing larger amounts.
gmaxwell
Moderator
Legendary
*
expert
Offline Offline

Activity: 4214
Merit: 8494



View Profile WWW
April 10, 2014, 02:52:38 AM
 #3

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
Legendary
*
qt
Offline Offline

Activity: 1652
Merit: 2226


Chief Scientist


View Profile WWW
April 10, 2014, 09:37:21 PM
 #4

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 :


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.

How often do you get the chance to work on a potentially world-changing project?
defaced
Legendary
*
Offline Offline

Activity: 2184
Merit: 1011


Franko is Freedom


View Profile WWW
April 11, 2014, 01:54:35 AM
 #5

Thanks for clearing it all up fellas.

Fortune Favors the Brave
Borderless CharityEXPANSEEXRAllergy FinderFranko Is Freedom
Rampion (OP)
Legendary
*
Offline Offline

Activity: 1148
Merit: 1018


View Profile
April 11, 2014, 08:30:59 AM
 #6

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

piotr_n
Legendary
*
Offline Offline

Activity: 2053
Merit: 1356


aka tonikt


View Profile WWW
April 11, 2014, 01:29:24 PM
Last edit: April 11, 2014, 01:48:47 PM by piotr_n
 #7

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? Smiley
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! Smiley

Check out gocoin - my original project of full bitcoin node & cold wallet written in Go.
PGP fingerprint: AB9E A551 E262 A87A 13BB  9059 1BE7 B545 CDF3 FD0E
Loozik
Sr. Member
****
Offline Offline

Activity: 378
Merit: 250


Born to chew bubble gum and kick ass


View Profile
April 11, 2014, 03:17:26 PM
 #8

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
Legendary
*
Offline Offline

Activity: 1974
Merit: 1029



View Profile
April 11, 2014, 03:20:21 PM
 #9

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
Sr. Member
****
Offline Offline

Activity: 378
Merit: 250


Born to chew bubble gum and kick ass


View Profile
April 11, 2014, 03:32:43 PM
 #10


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
Legendary
*
qt
Offline Offline

Activity: 1652
Merit: 2226


Chief Scientist


View Profile WWW
April 11, 2014, 04:12:59 PM
 #11

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! Smiley
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.

How often do you get the chance to work on a potentially world-changing project?
piotr_n
Legendary
*
Offline Offline

Activity: 2053
Merit: 1356


aka tonikt


View Profile WWW
April 12, 2014, 11:21:25 AM
Last edit: April 12, 2014, 11:37:42 AM by piotr_n
 #12

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! Smiley
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! Smiley

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).

Check out gocoin - my original project of full bitcoin node & cold wallet written in Go.
PGP fingerprint: AB9E A551 E262 A87A 13BB  9059 1BE7 B545 CDF3 FD0E
Pages: [1]
  Print  
 
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!