Bitcoin Forum

We have been quietly notifying the largest exchanges, merchant service providers and mining pools about this issue, and waited until they upgraded or patched their code to go public with this:

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

CVE-2012-2459: Critical Vulnerability

A denial-of-service vulnerability that affects all versions of
bitcoind and Bitcoin-Qt has been reported and fixed. An attacker
could isolate a victim's node and cause the creation of blockchain
forks.

Because this bug could be exploited to severely disrupt the Bitcoin
network we consider this a critical vulnerability, and encourage
everybody to upgrade to the latest version: 0.6.2.

Backports for older releases (0.5.5 and 0.4.6) are also available if
you cannot upgrade to version 0.6.2.

Full technical details are being withheld to give people the
opportunity to upgrade.

Thanks to Forrest Voight for discovering and reporting the vulnerability.


Questions that might be frequently asked:

How would I know if I am the victim of this attack?

Your bitcoin process would stop processing blocks and would have a
different block count from the rest of the network (you can see the
current block count at websites like blockexplorer.com or
blockchain.info).  Eventually it would display the message:

"WARNING: Displayed transactions may not be correct!  You may need to
upgrade, or other nodes may need to upgrade."

(note that this message is displayed whenever your bitcoin process
detects that the rest of the network seems to have a different
block count, which can happen for several reasons unrelated to
this vulnerability).


Could this bug be used to steal my wallet?

No.


Could this bug be used to install malware on my system?

No.


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Darwin)

iQIcBAEBCgAGBQJPsTpaAAoJECnZ7msfxzDB76cQALBqcEb40dQOtopbsk7vHDuL
FL4xd56B1/s3idyHGeCuwJX5bgxGD9b3svayXhDiLo9O+5E3sxsLY1HehTXnU8KV
BGpIQ7I+XLDcmarGYrDLMNMDLFOp/1hTipi08X3cr6oHNdYOxGbdtqCQR8xxtdfh
Mmo07ReYYWamlF+QbwoXIJQOEka2UVeWWgmk1C+WW1phI3P3Of5EvWvkmOurZsY1
zew7G3sk0Lu8glxSt8qq1SKlDXOaSqTBPxs+2FtgkUplNrAIyufu0vCTsnC44oie
ndJD6XZAaG6cYr3adGQKmUjRR+oyZarMtBdDHBvYHkrQI4uQclL1aS7DhkLtH8kp
fBRHdqmbBJpmpWOcs+OZeaQCzrArKihuVVZqP4HYbHgGHLV3Ls1bebyWm5eLZH6Z
C5l3B4Hz/lp50gJpVsIZI291l3KWfoBW2qGyQv51U4uByLU8tPzgr5bdyo6YCo4N
XQZHveNInMDI8jSimGyHg7WNm0YjkSAM8PEIJhQuL+RaHKgN/ghLPR+1K1YZnMjq
BPdJZVDpP2bgClyj6P+UkhAplEoenxZUsjyRmcs9EWjHZo3UUI9MLZW96vkR0Wlv
UBgq0/jSNQ6s3U3YwKM8CDFJ4OB7Mu1Ln6sn+Tu5sl3xtPyapARA5K67FYSpvqVX
GNIME8aiNjICQmtIFiuX
=9L8G
-----END PGP SIGNATURE-----

Responsible disclosure FTW.

GAVIN FTW   .. Outstanding work *bump* this.

#bitcoin-police

good thing I updated to 0.6.2 today. Nice work on the client gavin, peter, and the rest of the team

+1

Well done. :)

Which email did you use to notify WalletBit?

Kind regards
Kris

For anyone who is unaware, Forrest is the creator of the decentralized peer-to-peer mining pool p2pool - which will now be even more DoS resistant.  :)

Many thanks guys.

Uh, what? p2pool is more susceptible to DoS than other pools, and this fix to bitcoind/Bitcoin-Qt does nothing to change that.

Explain it like I'm 10 please :)

"You really want to upgrade ASAP..."

Every bitcoind upgraded on my side, Thanks.

Forrest's (http://forre.st/) bitcoin address: 1HNeqi3pJRNvXybNX4FKzZgYJsdTSqJTbk

Well, this is good and bad. Good that you caught it!

You guys might want to include a link to the software update...

Anyways, bump, bump, bump!

Was a network alert (getinfo.errors) broadcasted for this?

Absolutely a good call.   Thank you.

Dalkore

It really says something when the first I hear of a critical vuln is when I'm getting the link to the patch.
Handled quite well gentleman, good job.

If you run a p2pool node you need run bitcoind, so with this vulnerability patched the net result is a system that is less susceptible to DoS, is it not?  I didn't mean to suggest this bug had anything to do with p2pool itself, which Forrest made it clear in the p2pool thread.

Regarding the DoS susceptibility, do you mind answering in the p2pool thread?  I don't want to hijack/derail this thread with a pool discussion - http://bitcointalk.org/index.php?topic=18313.msg901218#msg901218

Isn't Bitcoin meant to be public or something, not 'public when you want it to be'?

Sometimes you gotta let the "honest nodes" know about something to fix it before the "dishonest nodes" take advantage of it... I think that's an inevitable reality of fixing issues with the least disruption.

Fact is, a lot of software companies would never make it public. You're free to try to find the vulnerability in the code yourself, but nobody is obligated to tell you what it is. The code is public. Go read it.

Additionally, it will be made public. It's unimportant the details of what happened as long as a fix has been released. (At least in the short-term.)

FWIW, the network is now 5% secure against CVE-2012-2459.

Huge thanks to Gavin and all involved for handling this professionally.  You are first class!

It is open and public, you could have looked through the code to find it yourself, don't be lazy and expect everyone else to tell you the results of their work.

I'm glad you understand what this means.  I assume it's a good thing.

Thanks to all of your programmers fighting the good fight!

Why Gavin did not use 0xBE38D3A8 key for signing the post? Did I got wrong key in my chain?

And when sf.net will have latest 0.4.x uploaded?

SourceForge uploads require 3 independent people to build the same binaries to verify their integrity. Want to volunteer to help out with 0.4.x? :p

In light of Gavin's statements, this seemed like a very reasonable post to me.

Anyhow...

Thanks for the update, Gavin. And thanks to all the coders and testers involved with fixing this.

No, you didn't. I'm curious of this myself.

I don't know if it is relevant, but I happened to see the post when it was first put up, and I saw a signed statement, and upon refresh I saw the signature removed, and another refresh I saw the signature put back on. Unfortunately, I didn't keep any copies of the first post and its initial signature.

The key Gavin used is signed by 0xBE38D3A8. It's his code-signing key.

I can't speak for why Gavin signed the message with his "CODE SIGNING KEY" rather than his normal one, but at least I can confirm that this key is 4096-bit (his normal one is only 1024-bit) and signed by the normal one. It's also the one he uses to sign all his release builds.

It's not relevant. The signature was removed when he edited the post to correct the stable version numbers (he had 1 higher than the correct versions), and he resigned the corrected message later.

First of all I did not doubt the genuinity of Gavin's post at all. I was surprised that the Gavin's key did not match one stored in my keyring, and I was lazy enough to not look for other signatures.Maybe. The wx version sure needs to live on, as it is better in all aspects than qt version in my opinion. The biggest problem is that I'm not a programmer. I can compile software from source, I can take look at the code and guess what it probably does, and that's all.

wxBitcoin is for all "official" purposes unmaintained and dead. I only support bitcoind 0.4.x, not wxBitcoin. If you want to resurrect it, I'm happy to help, but there will need to be at least one real developer who cares about it...

Getting stuff on SourceForge requires being able to compile with gitian, not much more. That requires Ubuntu right now. If you can help with this, ping me in #Bitcoin-Dev (IRC) and I'll try to help you through it.

Wasn't BitcoinD the same Bitcoin client in "headless" mode?Probably not by me, unless someone want to run Bitcoin look-alike wallet stealer :D But there is some people who like the wx version better. Maybe starting to collect bounty to be paid for releasing up-to-date Bitcoin-wx is a better idea.

Yes, wxBitcoin and bitcoind 0.4 share(d) the same codebase, and bitcoind 0.4.x is still built with wxBitcoin to avoid breaking anything subtle. But nobody is looking out for or fixing GUI-specific issues, for example. Ideally, someone would bring it up to speed with a port to the 0.6.x codebase too (which I could then just backport fixes from).

Maybe, but it'd need to be someone else doing it - I really hate wx ;)

It might be more efficient to raise funds to fix whatever you don't like in the -qt GUI— even if there are irreconcilable differences maintaining a fork of the QT gui would be a lot less work than WX, it's easier to get people willing to work with QT, and the WX version is even a pain to build.

Oh my. I think I may have an idea what this is all about, and if I'm right this attack would be scarily easy to implement.

Can Qt version be made to look and function indistinguishable from wx? I don't think so. There are some software based on Qt that look good and are intuitive to use, but not many.

What an offtopic.

Probably. Does wx have a consistent look? I thought it just wrapped GTK+ :p
As for function, it should be possible, though probably a lot of work.

Qt doesn't have "looks"; Qt applications just adopt the appearance of your OS, whatever that may be (at least by default; I understand there's some way to "skin" Qt applications...).

wx wraps whatever your native window drawing library happens to be. So GTK+, or Aqua, or whatever the heck Windows uses...

It doesn't wrap native here. I use a Qt-based system.

Is there something about 0.6+ that refuses to read block chain files copied in from earlier versions? Just built it, but every time I run it, it ignores the blk*.dat files and deletes the __db.* files from the configuration directory. Then it tries to reload the whole block chain off the network. I wouldn't mind doing that on a spare machine, but now I'm worried if I do let it run, then when I copy the directory over to a hot machine it'll just start all over again.

Has anyone else run into this problem?

Stupid question, although I think someone else was wondering the same...

How was that mass 'vulnerability' message sent and displayed within the affected Bitcoin GUIs/Clients ?

I saw that (in the lower left of my Bitcoin-QT Windows GUI) before I saw the forum warning....

I guess what I am most wondering is, what call was used on the client-side to retrieve that warning ? (getmininginfo.something ?)

I would like to be able to display future warnings etc in my Web Mining monitor, that I also display other BTC info in using API calls.

Should be in the getinfo "errors" key. It uses a hardcoded private key to relay across the p2p network.

Thanks.

Can I use getinfo()'errors' to display future message broadcasts in a web app ?

Should be fine, though I'd advise against posting it publicly, just in case some attacker is googling for vulnerable services.

Of course. It will just be on my local mining monitor app for CGMiner.
Thanks again.

The QT version won't run on my minimal linux machine.  I've been running 0.4.0 forever.  Where can I find this 0.4.6 backport you speak of?

Nevermind, I got it to run.  :)

https://bitcointalk.org/?topic=79651

Since update I see some lags caused by bicoind/bicoin-qt. From time to time (even every 10 sec) bitoin is eating full cpu for 0.5-1 second freezing my machine. Any1 noticed this?

I've put together a chart (http://luke.dashjr.org/programs/bitcoin/files/charts/security.html) with the status of listening nodes.

      2 32300 ".ljr2" vulnerable

Is that you? :P

No, that's an ancient version I made in early 2011. ;)

I wanted to add here that it is worrying, how much power here is vested in developers. And as much of a great job they do, they do make mistakes. Every time I have to upgrade, there is always a thought on the back of my mind - what if there is a vulnerability or exploit? Even worse is that even those of us who don't upgrade for that reason still depend on the 50% of other nodes to be not vulnerable

At this time most nodes upgraded to the new version, and it is behemoth. Satoshi's client was no fun, but compared to amount of code in the current version, it is nothing! It is simply impossible to tell that there is no hack/vulnerability/backdoor in all this code. Even if there is not any in the bitcoin code per se, there is no way to tell about all dependent libraries. So, at this time,  everybody runs this oversized, unreliable client, and why? Because there is bug, and nobody maintains original daemon, so the latest one is the one fixed.

I'd say, if bitcoin community ever gets to the times when network could run safe, robust, and reliable, it will be when a stable, simple client goes out, which does only what is needed, and nothing more, and the code gets frozen, except for security updates. GUI shouldn't be part of the client, especially when client already supports xml-rpc to perform the tasks. When there is an issue with the code, but GUI has the ways to go around it, that leads to the bugs, that never get fixed, that go unnoticed.

I beg developers: please focus on the core. Make it stable. Bring the daemon to the state, where it is usable by external GUIs, and let them have at it. There shouldn't be a way for dev to destroy bitcoin by mistake of developer.

The daemon is already useable by external GUIs, and is also much more stable when performing that task. Take for instance the Armory client which uses bitcoind in the backend. There are others as well.

You don't have to have the GUI to run the daemon; indeed you shouldn't even need to look at a single line of QT code at all.

Huh? Bitcoin-Qt is much lighter and abstracted in comparison to the old wxBitcoin...

We (especially Gavin) have been working on unit tests to ensure changes don't affect behaviour of the client. This is a big step forward in being able to audit changes. Additionally, many developers (including myself) read every single commit (or at least most) - so anything fishy should get picked up.

Why do you say nobody maintains the original bitcoind? I've been maintaining it since 0.4 - the current version of which is 0.4.6 (https://bitcointalk.org/?topic=79651) and has this vulnerability (as well as the others (https://en.bitcoin.it/wiki/CVEs)) fixed. The stable branches only get bugfixes and mandatory protocol updates.

That's a goal, but it's unfortunately a far way off :(

I'm pretty sure Armory doesn't really use bitcoind, just the files bitcoind makes/maintains... Spesmilo does try to use bitcoind.

From the bitcoinarmory.com website:


Although I believe etotheipi is planning on changing that.

This doesn't bother me one bit as I keep most of my coin on paper wallets.  My exposure to a client bug is always limited to the amount of coin I have online at any given time.

I wish the idea of putting bitcoins on paper had more favor with the developers and was considered an important feature for the client.  "Click File, Print, Print Money.  Be your own bank."  Specifically, having the private key sweep/import feature exposed in the UI and for it to not need a full blockchain scan to execute would go a long way toward users ability to protect themselves from risks, including future client bugs.  The more this feature is offered by lightweight clients, the fewer full bitcoind nodes there are going to be on the network as people choose those other clients.

"WARNING: Displayed transactions may not be correct!  You may need to
upgrade, or other nodes may need to upgrade."

 :o I had that message! I then tried to upgrade and nearly lost my wallet!

And this is what you don't realize, and many people don't either. With too-widespread software flaw, you can lose bitcoin EVEN if nobody picks your private key, or hacks into your PC. The bitcoin network is only as good as the software. If there is a critical bug introduced, and too many people use the client that has this bug, you could push through any transaction you want. Those would technically be invalid transactions, and clients not affected by bug would reject them, but if too many clients will accept, it will become de-facto a new block. And once a bunch of blocks are stacked over invalid block, it will be practically impossible to rollback. So, your paper money would lose the balance and you wouldn't even know.

This is why, to my mind, it is so important to have the most basic, the most minimal client possible.

Command line daemon could have been it, but unfortunately there are known, 100% reproducible bugs in it, such as this one (https://github.com/bitcoin/bitcoin/issues/1231), that have been there for years, and nobody would put a permanent fix. I realize, I'm jumping from a critical bug scenario to the one of real low priority, but bugs like that are the reason not too many UIs exist for a daemon

Bitcoin has had to rolled back up to 53 blocks before (CVE-2010-5139 (https://en.bitcoin.it/wiki/CVEs#CVE-2010-5139)), so I wouldn't say it's impossible. Integrity of the currency comes before miners' income.

Interesting!!!! I didn't realize that actually have already happened once. So, I guess, that illustrates my point very nicely, how much the whole community depends on a small number of developers. It is very good to know that they already handled such situation appropriately, kudos to devs.

Yet, it also confirms that there ARE reasons to be concerned. We are all humans, and there are organizations out there, which wield significant power, and can put enormous pressure on a person. There would be significantly more certainty if there was a client, code of which never gets touched.