Wallet encryption bug found (IMPORTANT!) - page 2.

Luke-Jr

legendary

Activity: 2576

Merit: 1186

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.

michaelsuede

jr. member

Activity: 39

Merit: 1

Quote from: LightRider on November 12, 2011, 02:27:09 AM

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?

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?

Gavin Andresen

legendary

Activity: 1652

Merit: 2216

Chief Scientist

Quote from: theymos on November 11, 2011, 08:08:40 PM

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.

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.

Quote from: Luke-Jr on November 12, 2011, 09:56:19 AM

Quote from: fellowtraveler on November 12, 2011, 12:16:30 AM

IMO, You guys need to figure out an organized way to fund Gavin's work.

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

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.

finway

hero member

Activity: 714

Merit: 500

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

kgo

hero member

Activity: 548

Merit: 500

Quote from: kgo on November 12, 2011, 11:52:28 AM

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.

kgo

hero member

Activity: 548

Merit: 500

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.

Luke-Jr

legendary

Activity: 2576

Merit: 1186

Quote from: fellowtraveler on November 12, 2011, 12:16:30 AM

IMO, You guys need to figure out an organized way to fund Gavin's work.

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

jkminkov

hero member

Activity: 698

Merit: 500

Quote from: MysteryMiner on November 11, 2011, 10:26:21 PM

Quote from: Luke-Jr on November 11, 2011, 10:14:45 PM

Quote from: MysteryMiner on November 11, 2011, 10:12:05 PM

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

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.

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

deepceleron

legendary

Activity: 1512

Merit: 1028

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

Bitsky

hero member

Activity: 576

Merit: 514

Quote from: Gavin Andresen on November 11, 2011, 05:57:20 PM

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.

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

LightRider

legendary

Activity: 1500

Merit: 1021

I advocate the Zeitgeist Movement & Venus Project.

Quote from: Gavin Andresen on November 11, 2011, 05:57:20 PM

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

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.

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?

Fluttershy

sr. member

Activity: 420

Merit: 250

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

fellowtraveler

sr. member

Activity: 440

Merit: 250

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

bitplane

sr. member

Activity: 321

Merit: 250

Firstbits: 1gyzhw

Quote from: Gavin Andresen on November 11, 2011, 05:57:20 PM

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.

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.

MysteryMiner

legendary

Activity: 1470

Merit: 1029

Show middle finger to system and then destroy it!

Quote from: Luke-Jr on November 11, 2011, 10:14:45 PM

Quote from: MysteryMiner on November 11, 2011, 10:12:05 PM

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

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.

Xenland

legendary

Activity: 980

Merit: 1003

I'm not just any shaman, I'm a Sha256man

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

Luke-Jr

legendary

Activity: 2576

Merit: 1186

Quote from: MysteryMiner on November 11, 2011, 10:12:05 PM

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

MysteryMiner

legendary

Activity: 1470

Merit: 1029

Show middle finger to system and then destroy it!

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.

bitstarter

sr. member

Activity: 300

Merit: 250

BitcoinStarter.com Support Account

Thank you for this information! Shocked

theymos

administrator

Activity: 5166

Merit: 12850

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.

Topic: Wallet encryption bug found (IMPORTANT!) - page 2. (Read 30594 times)