Bitcoin Forum

Greg Maxwell's announcement: 
http://sourceforge.net/p/bitcoin/mailman/message/33221963/

Summary:

There is a problem with the most recent release of OpenSSL which will cause issues for some users of Bitcoin Core on Linux. This is not a critical security issue, but everyone using Bitcoin Core on Linux should read the following information, especially if you're automatically processing Bitcoin payments. The worst-case scenario is that you might accept transactions as confirmed which are later reversed.

You are likely to be affected only if:

- You use Linux.
- You installed Bitcoin Core using your distro's package manager or you compiled Bitcoin Core yourself without using gitian. You are not affected if you use the binaries on bitcoin.org.
- You upgrade your system's OpenSSL to 1.0.0p or 1.0.1k. These were security-fix releases, so your package manager might have updated them automatically.

If you are affected, then your client might become stuck at a particular block, and you'll have to reindex the block chain to fix it. In some conceivable but unlikely scenarios, you might see incoming transactions as having 6+ confirmations when the transactions are actually invalid. If you are a pool operator, then you could conceivably start mining on a false chain, which would cause you to lose all of your future blocks until you fix this.

If you are using an affected version of Bitcoin Core, you should either make sure that your system OpenSSL does not get updated or shut down Bitcoin Core until an update fixing this is released in a day or two. If Bitcoin Core is already stuck and showing the "We do not appear to fully agree with our peers!" message, shut it down until an update fixing this is released; when you run that version, you'll have to run it with the -reindex switch.

Lol, what is this? OpenSSL is becoming more of a joke every day.

Or maybe it is being done on purpose.

The question is, why do the OpenSSL developers push compatibility breaking updates to the stable branches? They have 1.0.2-beta for all kinds of experiments.

Seems so... :-\

Thank you theymos for this info.
Best regards
Christian

thanks theymos OpenSSL lets me down once again :(

Is the issue having the new version of OpenSSL at compile-time, or at run-time? (My build of 0.10rc1 links dynamically to /lib/x86_64-linux-gnu/libssl.so.1.0.0, but I don't know about 0.9.3 or builds made on the PPA as part of a Debian build process).

Furthermore, to prevent such drama later if OpenSSL is still used down the road, is there a documented, secure, and feasible way to statically link to a known version of OpenSSL that is passing tests?

Because openssl is one giant mess, it's so horrid that it is immune to auditing but it is so widely used that we're just stuck with it.
I for one commend the developers for at least trying to fix it, anyone else would have given up years ago.

Arch Linux just updated to 1.0.1k so this affects my node.
Think I'll just shut my node down till the patch.

This is serious.

Anybody knows when is a patch coming ?

ubuntu 14.04
affected?

Start openssl from terminal wait for it start and use version to see if you have one of the versions in question. Close openssl with quit

This is actually a twofold problem - Bitcoin Core's use of signature validation plays an equal part in this.

I know how to check openssl version, question was about bitcoin-qt binary package from ppa

Just for checking, I have version 1.0.1f in ubuntu but I'm using bitcoin core 0.9.2.1 from bitcoin.org, so no need to change or panic, is that right? :)
And thanks for the heads up, theymos - this is exactly what makes this community awesome!

Perhaps try apt-get upgrade and see if it wants to install the new version. Then do not hit Y to install?

I think it showed up on my ec2 server this morning and I installed it since it is just a web server.  I didn't note it though and am not in a position to check right now.

It looks like there is now a patch for it from Wladimir, per the mail list, btw.

edit:
I did check to see if 14.04 was offering to install the update via apt-get and it was not as of now. 

http://www.libressl.org/

Kind of makes me glad I haven't bothered upgrading openssl in some time.

Just open the debug window and you will see what version of OpenSSL the executable was linked against.



*blank stare*

Heartbleed much?

Like you said, there is LibreSSL.  :D

it seems system version of OpenSSL used

thats like mega gay dude since we use bitcoind on debian.

What does the "p" and "k" stand for in:

"[...] OpenSSL to 1.0.0p or 1.0.1k [...]"???

 ???

I use FreeBSD, is it affected?

Can you even autoupdate freebsd's ports?

You can check if your compiled binary is working correctly by executing the command "make check" in the source code directory. This will then iterate through tests. It will return either pass or fail.

Yes. I probably should have said "unix-like". The issue affects any system where you're dynamically linking Bitcoin Core against the system OpenSSL. This could even be done on Windows, though that'd be very unusual.


Yes.


It's an issue of what Bitcoin Core will use. If it's statically linking an OK version of OpenSSL, then updated your system OpenSSL is OK. If it's dynamically linking, then you'll have problems. The binaries on bitcoin.org statically link OpenSSL. I think that almost all Linux distros distribute versions of bitcoind/bitcoin-qt that dynamically link.

If you're compiling Bitcoin Core using the normal configure+make, then it'll link dynamically. I'm not sure how to force this to link statically.

It is possible with PKGNG, but I build my own package repositories to manage updates.



Thank You.  I will watch out for this when building the next set of updates.

Not stable or tested enough yet.
People, stop suggesting LibreSSL. One can seriously fuck up his/hers system by replacing a core library by an unstable solution.

Once LibreSSL is proven not to be dangerous, it can be used instead of OpenSSL

I presume it doesn't matter what version of Linux you are running?

It is just Linux in general?

same OS, my version is:
I understand that this version is fine and I only don't need to upgrade to version 1.0.1k, but wait for the following one.
Did I understand that correctly?

I second this question.

So this affects any flavor of linux or unix-like system, including the BSDs? Got it.

Theymos said it affects any system that dynamically links OpenSSL to Bitcoin Core. Ok. Good to know.



So how does one force a static link in lieu of a dynamic link?

Basically any OS even windows although highly unusual with a dynamically linked openssl versions 1.0.0p or 1.0.1k.
To build it statically you need to generate the object files with gcc, then use ar to bundle them into a static library. But you do need to use a version of openssl which is NOT 1.0.0p or 1.0.1k, otherwise the whole exercise is pointless.

Excellent. Thank you.

Debian published this update:
https://www.debian.org/security/2015/dsa-3125 (https://www.debian.org/security/2015/dsa-3125)

For Wheezy, the version number is still 1.0.1e. However, the description says it solves CVE-2014-8275, which is exactly the change that should trigger the Bitcoin problem.

So, on Debian Wheezy, the latest patched 1.0.1e can also cause problems? I guess I should first apply the Bitcoin patch, before applying this OpenSSL upgrade...

Subj. is not a problem of openssl itself. New versions of openssl are rejecting non-standard signatures, while Bitcoin allows them. As the result, you can create block which will be accepted by some nodes but rejected by others.

Not sure where you've gotten "unstable" from, but I suspect you just didn't inform yourself before posting. LibreSSL is a new fork, yes, but it's beyond the "unstable" phase. The current version of OpenBSD has entirely replaced OpenSSL with their LibreSSL project, not just for the OS portion, but consequently also for every single package in the ~9000 items large repository making use of OpenSSL. All of it works, and it's stable.

That said, there are still a few odd cases of badly written OpenSSL-centric software that needs reworking before it's even possible to link against LibreSSL. This is a different matter.

IMHO bitcoin core should maintain it's own SSL library to avoid such issues in the future, in fact it shouldn't rely on 3rd party, regardless if they're open source or not dynamically linked libraries to avoid any possible attacks too. 

In software development, it's generally considered unwise to reinvent something that already exists in an established and scrutinized form.

LibreSSL isn't reinventing the wheel, but rather repairing a broken wheel. As LibreSSL grows more mature, and since it's a drop-in replacement for OpenSSL, it will with time deprecate OpenSSL and I'm sure the Bitcoin devs are wise enough to make the switch at some point.

I wasn't implying that they should reinvent the wheel, but to maintain their own fork of the libraries used.
The only reason why you want to build dynamically linked binaries is to reduce their size, but it's pointless for bitcoin since you have to download 30 or so gb blockchain data, so why not ship it with a bundle of all libraries used and statically link them, the binary file will be bigger by couple of megabytes but I don't see it as a big deal. And this will prevent issues such as this as well as prevent attacks from 3rd party developers who willingly or unwillingly introduce vulnerabilities in the bitcoin core via updates.

I now confirmed this, by first successfully running the Bitcoin 0.9.3 test suite, then upgrading OpenSSL (it still says 1.0.1e), and then getting a failure from the test suite:
http://www.ultimatestunts.nl/bitcoin/bitcoin_openssl_unittest_result.txt (http://www.ultimatestunts.nl/bitcoin/bitcoin_openssl_unittest_result.txt)

...and after applying the patch, Bitcoin passes its test again.  :) Good work!

*blank stare*
[/quote]

 :D I guess he's being sarcastic

Appologies if its answered already, does this effect Mac OSX?

Somebody knows ETA of a fix coming out ?

It affects all OSes. But unless you plan on updating your OS X-installation's openssl dylib yourself (and something tells me you're not), then you don't need to worry at this point. Everything is fine.

Arch Linux users only needs to upgrade to 0.9.3-4 version.

Gentoo 0.8.6-r1 and 0.9.3-r1 have the patch to workaround the issue.

Unless LibreSSL is guaranteeing bug-for-bug compatibility with old OpenSSL, it cannot safely be used with Bitcoin.
That means it MUST make sure all bugs in OpenSSL 1.0.1j are still bugs in LibreSSL.
As far as I know, that is not a goal of either OpenSSL nor LibreSSL, and is exactly why the new version of OpenSSL breaks Bitcoin by fixing a bug.

The binaries from Bitcoin.org are not effected, not on any operating system.

Virtually all users on Windows and OSX are not impacted, because virtually all of them use provided binaries. The only way you are possibly effected on those platforms is if you built the software for yourself and if you update OpenSSL.

I looked at that a while back and their massive house-keeping makes the _changes_ more or less impossible to review. (Of course, OpenSSL is more or less impossible to review to begin with; so for their purposes I cannot blame them.)

Keep in mind the Bitcoin protocol doesn't use SSL. That we're using a SSL library here is an accident of history, and a bad call in general. As this update demonstrates, our needs are at odds with the needs of a SSL library.

For most people, this will be the answer:


If you did compile your own software, then you can run "make check" in the source tree to see if you're affected. If all tests pass, you're not affected. You might want to check again after you update your system's OpenSSL.

Those who compile their own software can fix their software by applying a patch. The required changes are available on Github; e.g. here (https://github.com/bitcoin/bitcoin/commit/488ed32f2ada1d1dd108fc245d025c4d5f252783) for the 0.9 branch.

I created a version of the 0.9 sources that's nearly identical to the official 0.9.3 source code release for Linux, but with the fix applied:
https://github.com/cornwarecjp/bitcoin/tree/b146f97935d6c17927406ea549409d232eb7ce3c (https://github.com/cornwarecjp/bitcoin/tree/b146f97935d6c17927406ea549409d232eb7ce3c)

I wouldn't recommend doing development on that branch(*), but since it's nearly identical to the official release source code, it should be OK for compiling your own Bitcoin binary. Check for yourself with a diff tool what the differences are with the 0.9.3 sources and make sure you agree. In Linux desktops, you can e.g. use the "Meld" program for this, and use it to compare directories.

(*) The reason being that it's become quite different from development branches, which might make it more difficult to merge things.

I was thinking about setting up a bitcoin node but i guess i'll wait till all these issues gets resolved
But i do not think anyone would have believed a year ago, that the most secure systems on the planet would get hacked.
This far we constant read about super secure systems being infiltrated.
Lets be honest the increase in calculate power and increased usage of the internet does open up doors we never had thought about.
Look at the power which modern graphic cards already have, i guess some people used the tech used for mining to make machines to break code as well.
As they did in the paste with graphics cards as well

If you use the binaries from bitcoin.org you are safe (regarding this issue). Go on setting up your peer!

I moved to 0.10rc2 this morning and if you are running that branch, the notes include preventive measures.

I guess this answers my main question!


This problem would also affect self-compiled altcoin-wallets for which no altcoin.org-version exist, wouldn't it?

Run make test and see.

well, apparently not.
Version 1.0.1f (6 Jan 2014) seems to be affected, too.
Running reindexing now.

Well sarcasm is one of those things that doesn't translate well on forums sometimes. [/sarcasm] tags may be appropriate in the future.

Sorry, but what is the actually BC version atm?

0.9.4 is current stable.
0.10.0rc3 is release candidate.

Today Ubuntu 14.10 had the new bitcoin-qt and bitcoind binaries. Kudos to the package maintainers!
Now bitcoin-qt reindexes the blocks, it's taking forever  >:(
I'm all for using a less volatile EC library (and static linking) to avoid this in the future...

Onkel Paul

Ubuntu 14.04 myself, after the latest repository update of openssl 1.0.1f problems started.
I am reindexing right now, for the last 12+ hours (stacked somewhere in August 2014 with about 30k blocks to go).
Do you know if there is any way to speed it up?

Nope, I guess indexing the blocks just takes its time since it covers all transactions, and there are a lot of transactions by now...
Mine is in May 2014, 33 weeks to go.

Onkel Paul

so i have openssl 1.0.1f but everything seems up to date with the blockchain w/o any obvious problems.  any need to reindex?

If you have 0.9.4 or 0.10.0rc3, and your blockchain isn't stuck already, you don't need to reindex.
If you're not on the latest versions, then if your blockchain isn't stuck, it will be eventually.

Damn...Saw this a little too late...oh well...I'm on the school's internet  ;D

so i just upgraded from 0.9.3 to 0.9.4 but left openssl at 1.0.1f.  blockchain is not stuck at this pt.  ok?

For Linux users not on Ubuntu could we get https://bitcoin.org/en/download updated with the .tgz and/or some suggestion of which repository can be trusted.. and perhaps have the News alert on this site updated with a pointer to downloads, as that was always useful.

If you havent upgraded in some time you are likely vulnerable to heartbleed.

I thought OpenSSL has always been a joke...right?

A joke on which a lot of the internet relies on.

The problem is that we are using the current version of SSL (whatever's on the system/linked) to check the validity of blocks that were accepted with past versions of SSL.  

This is why the makefile for bitcoind specified static linking in the first place.

I am ... upset.  We should be using current versions of SSL for communications, because SSL gets valuable security upgrades.  But we should be using it for protocol only, because checking past blocks with a version that was not the version which governed their acceptance  risks exactly this sort of divergence.  Our need for SSL as a communications protocol does not affect the validity of data already transmitted.  

SSL will continue to change, and those changes cannot be allowed to affect data already transmitted and received, nor our software's opinion about whether that already-accepted data is valid.  Neither our stored blockchain data nor our ability to check our stored data should have anything to do with it.

Our need for cryptographic functions once a block is accepted are different, and absolutely NOT subject to revision.  That is, whatever's required to CHECK blockchain validity absolutely must not be something that can be altered by any change in a system library.  

I presume that SSL will continue to "tighten" its spec - that is, whatever is acceptable to future versions will also be acceptable to past versions. Therefore using routines from a three-year-old version of SSL to check data transmitted and received using the current version of SSL ought never fail, and using the current version for communications should get us the benefit of security fixes.  Updated routines can be compiled into the client NO SOONER THAN they are known to work with the entire current blockchain.


Cryddit

I'm using 1.0.1h.

Is this version OK?
It's still finishing up syncing and hasn't stuck yet.

New versions of OpenSSL such as 1.0.0Q and 1.0.0L came out.

Are they affected by the bug ?

All new versions of OpenSSL for the foreseeable future will be affected.
They don't see it as a bug, as they never guaranteed consensus compatibility.

Oh, that is just beautiful.

We're working on a 0.9.5 (and 0.10 of course) that will softfork to make us independent of OpenSSL so this can never happen again.
See sipa's proposal at http://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg06744.html

Yeah, I already know about this. Good work, guys. (Yes - you too, Luke - even though i really hate your Gentoo patches).

I can confirm that Version 1.0.1f (6 Jan 2014) caused 4 test failures here as well.

Any word on 1.0.2 ? 

Thanks a lot for giving us info to us because any info from u is validate
For us and it very better for us . good for us

The problem is that distributions tend to backport updates that are marked as security updates (as this one).

Here you go for Ubuntu: this is the security update that backports this patch to Ubuntu 14.10, Ubuntu 14.04 LTS,
Ubuntu 12.04 LTS, and Ubuntu 10.04 LTS: http://www.ubuntu.com/usn/usn-2459-1/

That means: if you are running any of the Ubuntu (server) versions above, you are very likely affected. If you are running Ubuntu LTS, you are for sure affected. In these cases, don't upgrade your OpenSSL installation.

Here's the list of package versions that you should NOT install (that is, the package versions with the backported patch):


How to avoid upgrading accidentally? Simply execute:


PS: don't trust the version reported by
as it does not cover the backports. Execute
to see which version you have.

Hello,

I am develop a trading platform now, I must to compile the bitcoin source code by myself,
so, which version of the openssl I can use? Thanks.

my other question is, why the bitcoin system don't maintain one correct branch of openssl?

At this point, just use 0.9.4.

Too large a codebase of mostly obfuscated spaghetti code.
It's going to be replaced with libsecp256k1 (which we do maintain) "soon" (planned since before this issue).

Thank you very much. Can I use 0.9.4 and openssl-0.9.8?

I plan to support more peer-to-peer Internet currency on my trading platform, I guess other p2p currency have the same problem, so I want to use the unified version of openssl to compile all the source code.

And, I run official  bitcoind 0.9.3 to download all block data, no any transactions yet, but a few days ago I change to 0.9.3 source code compile with openssl 1.0.0k , continue to sync the block data. Whether I still need to run -reindex to fix it?

how do you downgrade ?

You need to search for the version you need, download if for your architecture, and install it manually.

For example, in this case you search for 1.0.1f-1ubuntu2.7. You can find it here: https://launchpad.net/ubuntu/+source/openssl/1.0.1f-1ubuntu2.7
Select your architecture and download the .deb package of openssl and libssl (and the -dev packages if you need them). Then install them using dbpg.

Assuming that you're on 64bit:


That's it :)

Thank you very much for this
But it seems now i can't update & upgrade ubuntu, it says something about wrong dependencies, any solution for that?

Without you telling me which dependencies are wrong, no. ;) Most likely, you downgraded only part of your openssl packages, leaving some at the newer version. Make sure that you downgrade them all.

Do a dpkg -l | grep '1.0.1f' so see if there are different versions installed.

Okay, i think you are correct, here is the output-
iU  libssl1.0.0:amd64                                     1.0.1f-1ubuntu2.7                                   amd64        Secure Sockets Layer toolkit - shared libraries
iF  libssl1.0.0:i386                                      1.0.1f-1ubuntu2.8                                   i386         Secure Sockets Layer toolkit - shared libraries
hi  openssl                                               1.0.1f-1ubuntu2.7                                   amd64        Secure Sockets Layer toolkit - cryptographic utility

it have libssl 2.8, how do i completly remove it?
i am using ubuntu 14.04 64 bit,

Thank you very much!

You also need to download the i386 version of libssl (same procedure as the other packages above).

You have broken packages, those "iU" and "iF" at the beginning of the lines are pretty nasty. Run 'apt-get -f install'.

This is probably well after most people have already patched or defended against this, but the patch in question just got rolled out for Debian Jessie. 

Jessie has been on openssl1.0.1j up until now, and they're rolling out the 'k' version.

When upgrading Debian Jessie:

If you are otherwise vulnerable (compiled it yourself) you need to hold three items because of the way Debian breaks things up into smaller chunks.

Before upgrading your system do the following, either with 'sudo' or as root:  

apt-mark hold openssl libssl1.0.0 libssl-dev

It looks like no altcoins have addressed this.  What does this mean for their vulnerability? 

Those based on Bitcoin or Litecoin sources (which, to be fair, is almost all of them) are at least possibly vulnerable if they have not merged the recent fixes from Bitcoin core or formed equivalent fixes.

That said, their blockchains are mostly much smaller and contain, in relative numbers, almost no transactions.  Whether they are vulnerable in practice depends on whether their blockchains do or don't contain any blocks that the new SSL will find problematic when their users upgrade their SSL.   

So, if someone wanted to destroy a whole bunch of altcoins right now, he could deliberately mine blocks that fail the new SSL check and pass the old SSL check.  They'd all hang when they tried to process the bogus block.

We applied a patch to our source back on the 9th Jan (https://github.com/dogecoin/dogecoin/commit/6fa9a5e31a46120ffc772d7e8ca748b851c78f7f), and new binaries have been released compiled against OpenSSL 1.0.1l. I've also worked on a couple of open source libraries to ensure they're compatible as well.

I believe Darkcoin patched very early on too.

So; I would imagine a large number of alts haven't applied these patches, but it's almost certainly not "no altcoins".

My understanding (which is to say, I've only read the documentation, I haven't run a full simulation of this) is that the code doesn't hang, it simply rejects non-strict DER signatures. What you'd see is some nodes accepting transactions which others reject, so the result is actually a hard fork.

Does this affect Armory, which uses Bitcoin core? If so, how does it affect it?

It seems t wouldn't since a "holy-grail feature of Armory (https://bitcointalk.org/index.php?topic=139601.msg1486635#msg1486635)" is that it doesn't download such a huge chunk of the blockchain that BitcoinQt does, right?

Guys,

I'm running Ubuntu 14.04.1, 64-bit, with Bitcoin 0.9.4 from its PPA, I just upgraded everything (openssl version 1.0.1f-1ubuntu2.8, linux version 3.16).

Is that okay?

This node that I am running, have no coins (I have no coins), it is just a node to help the network... I hope to not bring problems...

Cheers!