Bitcoin Forum

A serious bug was been found in the "encrypt wallet" function of bitcoin versions 0.4 and 0.5: private keys may be left unencrypted in the wallet.dat file after encryption.

If your encrypted 0.4 wallet file is stolen, an attacker may be able to recover some or all of your private keys and steal some or all of your bitcoins.

The development team has been working on fixes for bitcoin versions 0.4 and 0.5, but it will take at least a few days to test them thoroughly. Until they are available, you should assume that your 'encrypted' wallets are as vulnerable as an unencrypted wallet, and follow all the best practices for keeping them safe (see here for a list (https://en.bitcoin.it/wiki/Wallet_Security_Dos_and_Don%27ts_(Windows))).

It is embarrassing and astonishing that this critical a bug was not caught before the 0.4 release; constructive suggestions on how to improve the testing and release processes that do not assume access to hundreds of thousands of dollars of funds to hire security consultants or QA teams are welcome. Getting sufficient testing of code BEFORE it is released has been a chronic problem for this project.

Very much appreciate the notice, Gavin. Thank you!

Thanks for the heads-up. We appreciate your hard work.

This issue can be "worked around" by generating a new address and sending all bitcoin there.

You should also remember to change all existing static addresses left on the web

How was this particular bug discovered?  That might help us formulate strategies for catching similar problems going forward.

Just a wild idea; but Google and others give bounties for security bugs that are submitted. Perhaps we could set up a small fund, and pay anyone who finds critical bugs in beta versions?

https://bitcointalk.org/index.php?topic=51474.0

That's not quite right-- you need to exhaust all of the keys in your 'key pool' to be safe, so you'd have to ask for 101 new keys.

Part of the fix is marking all of the keys in the keypool as used.

This fix should be back-ported to version 0.4.0

It will be, for bitcoind at least. If someone wants to step up to maintain wxBitcoin, contact me (or join #bitcoin-stable on FreeNode).

Features seem to be considered stable way too quickly. I'd like a version scheme like this:
- Add new features to 0.5.
- At some point, stop adding new features to 0.5 and call that the "unstable" release. Start adding new features to 0.6.
- 0.4 remains the "stable" release for at least 6 months, and it is recommend that newbies use this version. The unstable version is also available in binary form and can be easily used.
- Once 0.5 has been unstable for 6+ months, call that one stable.
- As many past 0.x releases as possible continue to get bugfixes for people who like to use really stable software.

I'm still using 0.3.19, and it works fine with only a few modifications. I avoided several bugs by doing this.

Once this problem is fixed, it would be a good idea to issue an alert for users of affected versions. Maybe not many users are affected, but it seems irresponsible to not notify these users when they can be notified.

Thank you for this information! :o

No intention to offend somebody, but this is FAIL. How such thing is possible? My solution - change wallet.dat format. First bits - wallet! identification string, next bits - wallet format version, next bit - encrypted or not. Every next bit is encrypted similar to truecrypt volume, and have included checks for correctness of supplied password. The wallet.dat file is decrypted on-the-fly as it is acessed by bitcoin software. The only inconvinience is that the wallet password must be supplied every time when starting bitcoin client, not only when sending coins.

Which totally defeats the purpose of wallet encryption. If you're going to do it that way, you might as well just encrypt on backup only (which would be a very nice feature anyway...)

Meanwhile, Zipping with encryption still works perfectly.....

The encryption of only private keys are no solution either. Just wait until victim sends the coins to someone, then recover the password using keylogger. It can only protect against trivial attacks such as grabbing the wallet.dat file right away. There is no real way of securing the wallet.dat file on compromised computer. But if I use encryption, I would like the whole wallet.dat to be encrypted, so even if shit hits the fan and my wallet.dat is leaked, all my adresses are not disclosed to attacker.

I guess the opaqueness of the wallet data file prevents people from having a poke around and reading it.

Binary formats are efficient for the computer, but they aren't very transparent and actively discourage casual reading by curious users. If the wallet were in XML, JSON or some other text-based format then I guess this would have been immediately obvious to anyone with a text editor and a pair of eyes.

"Thanks for all your hard work!" is not good enough. IMO, You guys need to figure out an organized way to fund Gavin's work.  

When he says, "It is embarrassing and astonishing that this critical a bug was not caught before the 0.4 release...Getting sufficient testing of code BEFORE it is released has been a chronic problem for this project..."

...That is developer-speak for, "I need better Q/A volunteers or I need funding to pay for them, and it's embarrassing that I even have to say this in the first place when I should be focused on my code right now."

Support your guy.

"Doesn't actually do what it's supposed to" is an embarrassing bug. It might've even encouraged people to not bother putting their wallet in some kind of encryption.

Would it be possible to leverage the ability of major community stake holders (Mt. Gox, Pool Operators) to incentivize or encourage activity on the testnet for new builds?

Maybe a bounty system would work. Depending on the severity of the bug you earn a few BTC for reporting it.

It's too late for a lot of testing, you can't just fuzz test Bitcoin without setting up your own gapped network of nodes and doing lots of mining first. Lets say a bug was introduced where if you send an address starting with 11 over 2^40 base units, the transaction's output address gets messed up? Oops if you are the one to find that.

I guess hex searching your hard drive for private keys before and after a 0.4.0 upgrade with encryption would be the big test that wasn't done...

put virtual keyboard in client, so user picks letters/symbols with a mouse and keyloggers defeated

IIRC, Gavin is paid full time for Bitcoin development as well as some other guy for Bitcoin QA.

I know this doesn't solve the problem of lack of QA, but the only reason I know about this problem is because I decided to read some threads with people arguing that are always in the "Bitcoin Discussion" forum.

It'd be nice if this information was on the bitcoin.org homepage.

It would be really nice if there was a release/security-issue mailing list I could subscribe to.  (I know it's not much work, but if you need a volunteer I'll be happy to setup a moderated list on google groups or something like that.)

This would also make it more likely that I personally would run release candidates, betas, etc.

Well I guess it looks like such a list is already active on sourceforge, but it isn't documented anywhere, and doesn't have emails for RC's or security advisories.

Lucky i don't leave a raw "encrypted" wallet .

Luke-Jr is planning on supporting 0.4-based releases (finding somebody to fix wxWidgets-related bugs is an issue, though).

The issue I have with calling any pre-1.0-release 'stable' is it implies a level of maturity that I don't think we're at yet. I can see 1-year develompment->unstable->stable release cycles once we're at a solid Bitcoin 1.0 release that I can actually feel comfortable recommending to my non-geek relatives.

My fear is that developers would happily code away and use the development branch, bugs would pile up against the unstable branch (and would get ignored because developers were happily coding away on dev, and nobody really wants to do bug fixing or QA testing), and unstable would never become stable enough to tag 'stable.' But I've never led an open source software project before, so I might very well be wrong (best way to convince me is to point to other small open source projects that we can emulate-- I don't think emulating big projects like Ubuntu will work).

I agree that when a fix has been tested and is available an alert to the affected versions is a good idea.

Unfortunately, TruCoin ran into a funding crunch because an investor got cold feet and had to stop paying for anything besides directly-related-to-TruCoin work.

I think something along these lines is a good way to ensure proper testing.

The use of a reward type system would be ideal.

For example, a set reward amount, to be awarded by private exchange or business owners, for discovering a bug.

If I were to test the code and get a reward from the community for each bug discovered, I would be much more motivated to do so.  The higher the reward, the higher the incentive for bug testing.

Another way of funding: Say in the client, put in an option to auto-contribute a tiny portion of each transaction to a bug testing reward pool that people may chose to opt into.

Something else to consider:  a bug testing reward tracking website that people could also contribute to?  Perhaps funded by auto-contributions from the client?

If anyone has unexpectedly leaked their wallet as a result of this, I am willing to offer 0-fee acceptance of a single transaction of any legit size via Eligius, under the following conditions:

• This offer expires 3 months after a fixed GUI (or bitcoind, whichever is later) client is released
• All inputs must be from transactions confirmed earlier than this post (exceptions might be made on a case-by-case basis)
• I must either already trust that you can be found reliably before making this post (ie, you're a regular who's been part of the community for a long time) or I will need some way to verify your full name and address.

I'm not happy entirely with the last requirement, but it's the only way I can think of to ensure thiefs can't abuse this offer. If you prove your identity to me, I promise not to share it except if subpoena'd (eg, by someone else who claims to own the coins and has already filed a lawsuit against you).

Please contact me directly if you have leaked your wallet and want to take advantage of this. Also note that I am not offering to help create the transaction for you (that's your responsibility), just accept it.

Don't know who would come up with the money for it, but it wouldn't be hundreds of thousands of dollars: Maybe offer BTC-bounties for bugs found in "official test releases". They probably wouldn't have to be high to motivate people in the bitcoin community to do better testing than is done now.

About coming up with the money: I've had quite some success (although not yet what I hoped for) with collecting donations for a common cause (https://bitcointalk.org/index.php?topic=51133.0). Maybe enough people would be willing to donate to "bitcoin testing", especially after things like the encryption bug or maybe even more serious stuff happen.

Is there anything an average Windows user without much programming experience could do to help with testing? Do all you experts and "experts" realize how obscure things are?  I looked at the development subforum, hoping to see a stickie. Nothing. I looked at bitcoin.org. Nothing. I looked at sourceforge. No leads. Sure, from random posts on this forum I infer that there is something called testnet, but I have no idea if and how I could help running a client on it.

How can I help at this stage of bitcoin development?

You forgot to check the Wiki. ;D

https://en.bitcoin.it/wiki/Testnet

I sure did forget, thanks! 

So, if i understand it correctly:

1: the fix is still being worked upon ?
2: Gavin has troubles with funding the work on the client ?

Greetz.

We all should. Why not include a donation option in the client? Make it optional, but set it by default so that 0.01% or whatever of each transaction is donated to a fund used to pay Gavin, other developpers and for bug bounties.  There was talk of a bitcoin foundation a while ago, not sure how thats going, but they could manage those funds.

In fact, even making such a donation mandatory wouldnt be such a bad thing, like a tobin tax, or like the transaction fees we already pay to miners. Although of course some people will just fork and use a client without the "tobin tax", if you set a hardcoded lower limit low enough, most people wouldnt mind I think.

That indeed explains what testnet is. That's not the only thing that was asked for, I think.

I think niko was looking for a place where "normal users" would be able to obtain information on how they could help with testing. Such a place would include

• explanation about what "testnet" is
• information about the planned release milestones and testing timelines
• downloads of test releases
• information on how to submit bug reports and other test results.
• info about how to test
• info about what needs testing and maybe current status

I'm sure the information is out there, it's just not easy to get to it if you're not quite heavily involved on developer mailing-lists, github, #bitcoin-dev, etc...

In other words: the bitcoin developer circle is quite a hard place to get into for joe schmoe, am I right? So maybe it would be cool to somehow make it easier for the "normal user" to help.

I agree.


I don't agree. It'd be very bad from a marketing point of view to make such a mandatory "tax". I'm experiencing a lot of troubles marketing bitcoin to friends (key import/export is a big one, by the way, because I use casascius coins to get people started, they inevitably want to see proof that it's working (and it's a big "AHA", when it finally does). Fiddling with pywallet ("what? that's not even in ubuntu repository") and having the client "stuck on blockchain rescan" with no gui showing for minutes ("that pywallet screwed up bitcoin, now it doesn't start any more, glad I have a backup") doesn't help the cause. But that's a different matter).

Having a tobin tax would only add to the troubles I'm having "selling" bitcoin to people.

Its just the name you object to I think. There already is such a "tax"in the form of transaction fees. Now they benefit miners, I dont see why we could not redirect part of it to a bitcoin foundation.

The difference between "bitcoin foundation" and "miners" is (lack of) decentralization, one of bitcoins main selling points.

I'm not against "bitcoin foundation" at all. But they shouldn't get to put "developer fee" code into the client (to avoid the evil "tax" word here). I probably wouldn't mind myself, but explain that to someone you just explained the coolness of decentralization and "basically free" transactions. It's hard enough to explain the tx fees, but it usually works out with a nice AHA-effect in the end when you explain mining incentive after block reward drops to close to nothing.

I was going to say that, but you also don't have to use this client, so the fee is still decentralized in that respect. Having a fee to the client developer also make the centralized-client issue more visible to the end users, which may be a good thing to get it solved sooner. It also gives clients an incentive to be competitive.

Gavin, thanks for all your hard work. I am sure you know this, but there are many people, hidden away in the background, that are impressed with your efforts. You have a sound strategic vision and have done important work in this crucial early stage. As an experienced professional, you already know that these bugs do happen in complex software. For us less-experienced people, please keep letting us know how to test the code or otherwise contribute.

Thanks again.

How about a more generalized donation percentage kind of thing? Give people a choice of a few bundled donation targets and prompt them to choose on the first run. Also extensible so it's possible to click a link on a website and have a new one added to the list.

For references, this issue has been assigned CVE-2011-4447

+1 Many thanks to Gavin and all the other devs that contribute

Test please: http://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.4.1/test/

Obviously, be sure you have a wallet backup or two.

YES!. Thanks Gavin!

Has this bug been fixed in 0.5.1 which I downloaded today after 6 months not using bitcoin and which I used today for encrypting my old wallet (5 minutes *before* I read about this bug)?

I think so, but until someone can confirm for certain, you're safe so long as you protect your wallet.dat - ie, don't upload it to the public.

All hail the great gavin and satoshi..... All hail the great gavin and satoshi....


I joke but in all seriousness thanks to every one who has, is and will continue to contribute to the bitcoin project wheather its the bitcoin client code its self or some kind of help service or goods you provide or even those bring up the topic of a digital currency with their friends or college class mates -- thanks err'body