Bitcoin Forum
April 25, 2014, 03:48:59 AM *
News: Due to the OpenSSL heartbleed bug, changing your forum password is recommended.
 
   Home   Help Search Donate Login Register  
Pages: 1 2 3 4 5 [All]
  Print  
Author Topic: URGENT: Windows Bitcoin-Qt update  (Read 16099 times)
Gavin Andresen
Hero Member
*****
Offline Offline

Activity: 1330


Chief Scientist


View Profile WWW

Ignore
March 17, 2012, 12:17:15 AM
 #1

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

A potential security vulnerability has been discovered in the Windows
version of Bitcoin-Qt. If you are running Bitcoin-Qt versions 0.5
through 0.6 on Windows you should shut it down and upgrade to either
version 0.5.3.1 or 0.6rc4 NOW.

The command-line bitcoin daemon (bitcoind), Mac and Linux versions of
Bitcoin-Qt, and versions prior to 0.5 are not affected.

Due to the nature of the vulnerability, we believe it would be very
difficult for an attacker to do anything more than crash the
Bitcoin-Qt process. However, because there is a possibility of such a
crash causing remote code execution we consider this a critical issue.

Binaries are available at SourceForge:
https://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.6.0/test/
https://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.5.3/

If you have questions, feel free to drop by the #bitcoin-dev channel
on FreeNode IRC.

- --
Gavin Andresen
Gregory Maxwell
Matt Corallo
Nils Schneider
Wladimir J. van der Laan
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk9j12IACgkQdYgkL74406iIyQCfbxFTO3yD4Q2bHDjPlDuJn3Mj
9GAAn3mV+ggo+5q1Ujd0A5zwpFYojkE2
=g1Ad
-----END PGP SIGNATURE-----

Will I see you in Amsterdam?
  http://bitcoin2014.com/
1398397739
Hero Member
*
Offline Offline

Posts: 1398397739

View Profile Personal Message (Offline)

Ignore
1398397739
Reply with quote  #2

1398397739
Report to moderator
1398397739
Hero Member
*
Offline Offline

Posts: 1398397739

View Profile Personal Message (Offline)

Ignore
1398397739
Reply with quote  #2

1398397739
Report to moderator
Buy a Blade, Get a 5-Chip Free!
Start Mining with GAWMiners.com
24/7 Live Phone & Tech Support
Free Hosting & Electricity for 1 Year!

Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1398397739
Hero Member
*
Offline Offline

Posts: 1398397739

View Profile Personal Message (Offline)

Ignore
1398397739
Reply with quote  #2

1398397739
Report to moderator
1398397739
Hero Member
*
Offline Offline

Posts: 1398397739

View Profile Personal Message (Offline)

Ignore
1398397739
Reply with quote  #2

1398397739
Report to moderator
1398397739
Hero Member
*
Offline Offline

Posts: 1398397739

View Profile Personal Message (Offline)

Ignore
1398397739
Reply with quote  #2

1398397739
Report to moderator
mcorlett
Donator
Sr. Member
*
Offline Offline

Activity: 308



View Profile

Ignore
March 17, 2012, 12:21:41 AM
 #2

Can we get more information on the nature of the vulnerability itself, please?

JackRabiit
Hero Member
*****
Offline Offline

Activity: 1162


Okey Dokey Lokey


View Profile

Ignore
March 17, 2012, 12:32:38 AM
 #3

when was this discovered?!

kentrolla
Hero Member
*****
Offline Offline

Activity: 504


View Profile

Ignore
March 17, 2012, 12:37:01 AM
 #4

thats nuts.......        can this effect any other processes?

Retired
Jr. Member
*
Offline Offline

Activity: 44



View Profile

Ignore
March 17, 2012, 12:37:40 AM
 #5

I assume you are not publishing more detailed information on purpose, right? And, as JackRabiit asked, when was this discovered?

"A business that makes nothing but money is a poor business"  - Henry Ford
fanquake
Donator
Sr. Member
*
Offline Offline

Activity: 378



View Profile

Ignore
March 17, 2012, 12:38:23 AM
 #6

Can we get more information on the nature of the vulnerability itself, please?
You can check out Github.


I assume you are not publishing more detailed information on purpose, right? And, as JackRabiit asked, when was this discovered?
I would say some time in the last day or so..

Join #bitcoin-aus on Freenode
12eb1xeCnDE1F64vXkvoqq6MrAuSqaCBMG
Clipse
SCAMMER
Hero Member
*****
Offline Offline

Activity: 504


View Profile

Ignore
March 17, 2012, 12:47:27 AM
 #7

bitcoin.org lists the 0.5.3.1 update posted for 16 April 2012, perhaps correct that.

...In the land of the stale, the man with one share is king... >> Clipse

We pay miners at 130% PPS | Signup here : Bonus PPS Pool (Please read OP to understand the current process)
apetersson
Hero Member
*****
Offline Offline

Activity: 633


mycelium.com


View Profile WWW

Ignore
March 17, 2012, 01:01:31 AM
 #8

about 3 days ago i was commenting on the language choice.
from a software architecture standpoint other languages than c++ would make more sense in such a sensitive area.

i am not suggesting that it should be rewritten. but i think it is very important that alternative implementations like BitcoinJ, multibit, armory, electrum exist.
ThiagoCMC
Staff
Hero Member
*****
Offline Offline

Activity: 980


฿itcoin: Currency of Resistance!


View Profile WWW

Ignore
March 17, 2012, 01:17:34 AM
 #9

about 3 days ago i was commenting on the language choice.
from a software architecture standpoint other languages than c++ would make more sense in such a sensitive area.

i am not suggesting that it should be rewritten. but i think it is very important that alternative implementations like BitcoinJ, multibit, armory, electrum exist.

The most important re-implementation of Satoshi's oroginal code, from my point of view, is Libcoin from Michael Grønager.

* Bitfication.com! Turn your fiat, into bits!
mcorlett
Donator
Sr. Member
*
Offline Offline

Activity: 308



View Profile

Ignore
March 17, 2012, 01:18:19 AM
 #10

Can we get more information on the nature of the vulnerability itself, please?
You can check out Github.
Did you check before posting? There is no relevant commit to the main branch.

Luke-Jr
Hero Member
*****
Offline Offline

Activity: 1218



View Profile

Ignore
March 17, 2012, 01:20:55 AM
 #11

The most important re-implementation of Satoshi's oroginal code, from my point of view, is Libcoin from Michael Grønager.
Libcoin is not a reimplementation, it is just the Satoshi client made into a library. Perhaps you meant Amir's libbitcoin?

cypherdoc
Hero Member
*****
Offline Offline

Activity: 1120



View Profile

Ignore
March 17, 2012, 01:22:57 AM
 #12

are the backups in 0.6.0 for windows encrypted?
Luke-Jr
Hero Member
*****
Offline Offline

Activity: 1218



View Profile

Ignore
March 17, 2012, 01:24:25 AM
 #13

are the backups in 0.6.0 for windows encrypted?
No

fanquake
Donator
Sr. Member
*
Offline Offline

Activity: 378



View Profile

Ignore
March 17, 2012, 01:24:59 AM
 #14

Can we get more information on the nature of the vulnerability itself, please?
You can check out Github.
Did you check before posting? There is no relevant commit to the main branch.
Isn't this it https://github.com/bitcoin/bitcoin/commit/8864019f6d88b13d3442843d9e6ebeb8dd938831

Join #bitcoin-aus on Freenode
12eb1xeCnDE1F64vXkvoqq6MrAuSqaCBMG
cypherdoc
Hero Member
*****
Offline Offline

Activity: 1120



View Profile

Ignore
March 17, 2012, 01:29:30 AM
 #15

are the backups in 0.6.0 for windows encrypted?
No

why wouldn't it be?  if you encrypt your working wallet, then run a backup, it should be encrypted as well i would think.
wumpus
Hero Member
*****
Offline Offline

Activity: 644

No Maps for These Territories


View Profile

Ignore
March 17, 2012, 01:29:56 AM
 #16

why wouldn't it be?  if you encrypt your working wallet, then run a backup, it should be encrypted as well i would think.
yes, it's simply a copy

Bitcoin Core developer [PGP]  Tips: 1L125pF2e7himW43Qu752ZFLtBLicxQmng 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.
Luke-Jr
Hero Member
*****
Offline Offline

Activity: 1218



View Profile

Ignore
March 17, 2012, 01:32:14 AM
 #17

are the backups in 0.6.0 for windows encrypted?
No

why wouldn't it be?  if you encrypt your working wallet, then run a backup, it should be encrypted as well i would think.
Encrypted wallets aren't really encrypted entirely. Only your private keys are. There's still a lot of sensitive data in there you probably don't want public.

grue
Staff
Hero Member
*****
Offline Offline

Activity: 1036


It is pitch black. You are likely to be eaten by a grue.


View Profile

Ignore
March 17, 2012, 01:38:35 AM
 #18

so all the 0.4.* versions are still safe, right?

1ELvnrA6PhUyDBS6iR25K1Xx4xXL6VMfJX
Luke-Jr
Hero Member
*****
Offline Offline

Activity: 1218



View Profile

Ignore
March 17, 2012, 01:47:16 AM
 #19

so all the 0.4.* versions are still safe, right?
For this specific bug, yes. But wxBitcoin (the GUI in 0.4.x) is not maintained or supported at all, so it likely has other unfixed vulnerabilities.

da2ce7
Hero Member
*****
Offline Offline

Activity: 1022


Live and Let Live


View Profile

Ignore
March 17, 2012, 02:03:55 AM
 #20

If the installer ain't working for you... Make sure you select 'Run As Administrator'.

Users whom wisely don't run as a super user, will get the error 'cannot access file.'  Instead of a prompt for an escalation of privileges.

Banking Software? I develop it: Open-Transactions
       Windows Open-Transactions Builds
gmaxwell
Staff
Hero Member
*****
Offline Offline

Activity: 1078


View Profile

Ignore
March 17, 2012, 03:20:49 AM
 #21

With respect to detailed questions about the issue, we're currently being somewhat vague— simply because it's helpful to give innocent users as much of a head-start on trouble makers as possible.  

At the current time we don't know that the issue is exploitable. The class of issue and the overall paranoid design of the reference client make it hard to tell for sure. It is probably hard to exploit if it is exploitable at all.  Because of the potential seriousness the issue has been dealt with promptly and as if it were exploitable. (I'm not answering the specific timing questions because they may identify the issue too clearly).

If the issue turns out to be practically exploitable we'd much rather learn of it as a purely academic fact— academic because almost all impacted users had already applied fixes—  a few weeks from now, than learn about that in the form of hundreds of wallets being stolen through an exploit in the next few days.

I always encourage people to review the git history, but if you spot the fix for this issue— please don't point it out yet (and I will remove posts that do), if you like you can contact me privately and I'll gladly tell everyone how smart you were later. Smiley —  Reviewing the commits is generally good advice it's always good to have more eyes on the code, and even if you don't satisfy your curiosity with respect to this issue you may learn something else useful.

hongus
Full Member
***
Offline Offline

Activity: 184


1hongus


View Profile

Ignore
March 17, 2012, 03:55:07 AM
 #22

So if I have 0.5.3.1-beta I'm safe?

1HoNGusEgzyXfvQnxHrJjx4bunJRf9pK19
gmaxwell
Staff
Hero Member
*****
Offline Offline

Activity: 1078


View Profile

Ignore
March 17, 2012, 04:02:52 AM
 #23

So if I have 0.5.3.1-beta I'm safe?

Yes. 0.5.3.1 is the fixed version of 0.5.3.
Killdozer
Full Member
***
Offline Offline

Activity: 204



View Profile

Ignore
March 17, 2012, 09:05:46 AM
 #24

Quote
about 3 days ago i was commenting on the language choice.
from a software architecture standpoint other languages than c++ would make more sense in such a sensitive area.

This is nonsense. If anything, more advanced languages can have their own vulnerabilities which could bitcoin vulnerable without any mistakes acutally made by the developers. This is almost impossible with a low level language like c++.
Apart from that, a program's security does not depend on the language, it depends on the coding.

defxor
Hero Member
*****
Offline Offline

Activity: 530


View Profile

Ignore
March 17, 2012, 09:31:30 AM
 #25


Apart from that, a program's security does not depend on the language, it depends on the coding.

All software developers of any experience and educational background will tell you that programs will always have bugs. It's simply impossible to provable test all possible pathways as soon as you venture beyond Hello World type complexity.

Thus it's better to use a programming and execution environment that protects you, as far as possible, when those bugs are found.

Schwede65
Sr. Member
****
Offline Offline

Activity: 300


View Profile

Ignore
March 17, 2012, 09:38:13 AM
 #26

only a question of a solo-mining-noob:

does an update effect the number of done shares to find a btc-block?

example: i have done 140.000 shares with 0.5.2
what will be there for me with update to 0.5.3.1 - start at share number 0 - without the 140.000?
psiborg
Newbie
*
Offline Offline

Activity: 25


View Profile

Ignore
March 17, 2012, 09:40:05 AM
 #27

If anything, more advanced languages can have their own vulnerabilities which could bitcoin vulnerable without any mistakes acutally made by the developers. This is almost impossible with a low level language like c++.
Apart from that, a program's security does not depend on the language, it depends on the coding.
Or on the (coding of the) language as you stated just earlier Wink
I'm using the anonymity patched bitcoin client (https://bitcointalk.org/index.php?topic=24784.0), hope they get their security patches too.
wachtwoord
Hero Member
*****
Offline Offline

Activity: 896



View Profile WWW

Ignore
March 17, 2012, 09:57:02 AM
 #28

So if I have 0.5.3.1-beta I'm safe?

Yes. 0.5.3.1 is the fixed version of 0.5.3.


What about 0.5.1-beta? (this versioning numbering is quite confusing)

✰ Scared Money Don't Make No Money | PrimeDice.com | The New Way To Roll *Thread*
I now do Bitcoin consultancy! PM to discuss terms.
Selling my signature space! PM to discuss terms.
eeb227823edc2ef43867d2640d26615cb7a3b2194af128c97b5f64770d367ba4
wumpus
Hero Member
*****
Offline Offline

Activity: 644

No Maps for These Territories


View Profile

Ignore
March 17, 2012, 10:08:44 AM
 #29

0.5.1 (-beta) is *not* safe.

only 0.5.3.1 and 0.6.0pre4 are safe right now. As for next versions, 0.5.4 and 0.6.0 (final) and so on will also be safe.

All bitcoin versions have -beta added in the "About" dialog as a statement about the current phase of the project, not about the current version.


Bitcoin Core developer [PGP]  Tips: 1L125pF2e7himW43Qu752ZFLtBLicxQmng 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.
malevolent
Hypernode
Global Moderator
Hero Member
*
Offline Offline

Activity: 1050


View Profile

Ignore
March 17, 2012, 10:36:46 AM
 #30

I always encourage people to review the git history, but if you spot the fix for this issue— please don't point it out yet (and I will remove posts that do)

Shouldn't you adher to full disclosure policy? This would actually encourage people to update.
TheSeven
Hero Member
*****
Offline Offline

Activity: 504


FPGA Mining LLC


View Profile WWW

Ignore
March 17, 2012, 10:38:22 AM
 #31

only a question of a solo-mining-noob:

does an update effect the number of done shares to find a btc-block?

example: i have done 140.000 shares with 0.5.2
what will be there for me with update to 0.5.3.1 - start at share number 0 - without the 140.000?

There is no such thing as shares when you are solo mining, so updating won't affect your solo mining income.

My tip jar: 13kwqR7B4WcSAJCYJH1eXQcxG5vVUwKAqY
Gabi
Hero Member
*****
Offline Offline

Activity: 1050


View Profile

Ignore
March 17, 2012, 12:59:28 PM
 #32

Updated, i have 0.6rc4 now

I wonder what happens now with older wallets...
gmaxwell
Staff
Hero Member
*****
Offline Offline

Activity: 1078


View Profile

Ignore
March 17, 2012, 01:17:55 PM
 #33

Shouldn't you adher to full disclosure policy? This would actually encourage people to update.

If you look a discussion about full disclosure you'll see that much of the discussion is completely moot when the "vendors" of the software are also the discoverers of the issue.  There also isn't much more that could be disclosed right now.

Luke-Jr
Hero Member
*****
Offline Offline

Activity: 1218



View Profile

Ignore
March 17, 2012, 01:47:00 PM
 #34

It's simply impossible to provable test all possible pathways as soon as you venture beyond Hello World type complexity.
It actually isn't impossible, just complex enough it hasn't been accomplished yet. It's quite possible to write a specialized emulator that follows every possible code-path with "quantum" memory states...

coderrr
Member
**
Offline Offline

Activity: 63


View Profile WWW

Ignore
March 17, 2012, 01:48:30 PM
 #35

If anything, more advanced languages can have their own vulnerabilities which could bitcoin vulnerable without any mistakes acutally made by the developers. This is almost impossible with a low level language like c++.
Apart from that, a program's security does not depend on the language, it depends on the coding.
Or on the (coding of the) language as you stated just earlier Wink
I'm using the anonymity patched bitcoin client (https://bitcointalk.org/index.php?topic=24784.0), hope they get their security patches too.

I don't have any info on the vuln or code for the patch.  So I'd advise you not to use my patched binaries until the vuln and fix have been disclosed and I can compile new ones.

Co-Founder of Private Internet Access VPN Service
Original Co-Founder of MtGox Live and BTC.to
Original Developer of the Bitcoin Anonymity Patch
defxor
Hero Member
*****
Offline Offline

Activity: 530


View Profile

Ignore
March 17, 2012, 02:03:00 PM
 #36

It actually isn't impossible, just complex enough it hasn't been accomplished yet.

It's impossible in the same way as brute forcing a 128 bit UUID is impossible Smiley E.g. in our relevant universe.

(And enough so for the discussion at hand)
Luke-Jr
Hero Member
*****
Offline Offline

Activity: 1218



View Profile

Ignore
March 17, 2012, 02:10:39 PM
 #37

If anything, more advanced languages can have their own vulnerabilities which could bitcoin vulnerable without any mistakes acutally made by the developers. This is almost impossible with a low level language like c++.
Apart from that, a program's security does not depend on the language, it depends on the coding.
Or on the (coding of the) language as you stated just earlier Wink
I'm using the anonymity patched bitcoin client (https://bitcointalk.org/index.php?topic=24784.0), hope they get their security patches too.

I don't have any info on the vuln or code for the patch.  So I'd advise you not to use my patched binaries until the vuln and fix have been disclosed and I can compile new ones.
Dev team is doing builds of 0.5.3+coderrr with the fix applied; should be available later today.

malevolent
Hypernode
Global Moderator
Hero Member
*
Offline Offline

Activity: 1050


View Profile

Ignore
March 17, 2012, 03:26:10 PM
 #38

Shouldn't you adher to full disclosure policy? This would actually encourage people to update.

If you look a discussion about full disclosure you'll see that much of the discussion is completely moot when the "vendors" of the software are also the discoverers of the issue.  There also isn't much more that could be disclosed right now.



 Smiley
Luke-Jr
Hero Member
*****
Offline Offline

Activity: 1218



View Profile

Ignore
March 17, 2012, 03:52:12 PM
 #39

You have to be god-like to not create security vulnerabilities in significantly C/C++ software.  'Direct' buffer overflows can be avoided by littering your code with meticulous boiler plate (and praying you haven't made a mistake somewhere).  But integer overflows leading to buffer overflows are so hopelessly trickly that I have no faith in any C/C++ being safe.

Java buffer overflows simply don't exist... a huge class of exploit eradicated by language choice.  And there's a long list of languages immune to buffer overflows (this is mostly a glaring hole in C/C++).  Look up US military/intelligence mandates about language choice.  C/C++ is so bad that it should be immediately abandoned and _never_ used for _anything_.  Why do you think computer security is such a disaster (it was all C/C++ until the recent xss/xsrf/sql havoc - and that too is a design flaw).
Guess what language Java/Python/etc are implemented it.

grue
Staff
Hero Member
*****
Offline Offline

Activity: 1036


It is pitch black. You are likely to be eaten by a grue.


View Profile

Ignore
March 17, 2012, 04:25:51 PM
 #40

Java/Python/Ruby/Lisp buffer overflows simply don't exist... a huge class of exploit eradicated by language choice.  And there's a long list of languages immune to buffer overflows (this is mostly a glaring hole in C/C++).  Look up US military/intelligence mandates about language choice.  C/C++ is so bad that it should be immediately abandoned and _never_ used for _anything_.  Why do you think computer security is such a disaster (it was all C/C++ until the recent xss/xsrf/sql havoc - and that too is a design flaw).
I tried looking it up, but I could only find some random articles about switching to ada, but nothing stating that "C/C++ is so bad that it should be immediately abandoned and _never_ used for _anything_" . Can you point to the article claiming that?

1ELvnrA6PhUyDBS6iR25K1Xx4xXL6VMfJX
stevegee58
Hero Member
*****
Offline Offline

Activity: 616



View Profile

Ignore
March 17, 2012, 06:48:50 PM
 #41

I upgraded my client yesterday and suddenly today I noticed I'm getting hit with a SYN flood attack.

Don't know if it's related but it's damn annoying.  I've stopped my BTC client temporarily to see what happens.

You are in a maze of twisty little passages, all alike.
check_status
Full Member
***
Offline Offline

Activity: 196


Web Dev, Db Admin, Computer Technician


View Profile

Ignore
March 17, 2012, 09:05:09 PM
 #42

NIST publishes 50kish vulnerable code samples in Java/C/C++, is officially krad

SAMATE - Software Assurance Metrics And Tool Evaluation

Welcome to the NIST SAMATE Reference Dataset Project

Veracode - Vulnerability Scanner for Excutable of C, C++, C#, Java

For Bitcoin to be a true global currency the value of BTC needs always to rise.
If BTC became the global currency & money supply = 100 Trillion then ⊅1.00 BTC = $4,761,904.76.
P2Pool Server List | How To's and Guides Mega List |  1EndfedSryGUZK9sPrdvxHntYzv2EBexGA
coinft
Full Member
***
Offline Offline

Activity: 174



View Profile

Ignore
March 18, 2012, 12:22:12 AM
 #43

You have to be god-like to not create security vulnerabilities in significantly C/C++ software.  'Direct' buffer overflows can be avoided by littering your code with meticulous boiler plate (and praying you haven't made a mistake somewhere).  But integer overflows leading to buffer overflows are so hopelessly trickly that I have no faith in any C/C++ being safe.

Java buffer overflows simply don't exist... a huge class of exploit eradicated by language choice.  And there's a long list of languages immune to buffer overflows (this is mostly a glaring hole in C/C++).  Look up US military/intelligence mandates about language choice.  C/C++ is so bad that it should be immediately abandoned and _never_ used for _anything_.  Why do you think computer security is such a disaster (it was all C/C++ until the recent xss/xsrf/sql havoc - and that too is a design flaw).
Guess what language Java/Python/etc are implemented it.

At least python and ruby are both implemented in a wide variety of other languages, not just C. There's even a very good implementation of python in python. Perhaps surprisingly some of these alternate implementations are even faster than their C-built equivalents. Their main drawback of course is lack of ability to link directly with C code.

With excellence and discipline it surely is possible to create decently secure code in C++. For me it's much harder and slower than ruby or python. Some projects are probably best done in C too, but I don't think bitcoin is one of those. Except of course if it's the language the main developers are most comfortable with, which most often is the main overruling argument deciding language for any given project.

-coinft
Luke-Jr
Hero Member
*****
Offline Offline

Activity: 1218



View Profile

Ignore
March 18, 2012, 12:29:56 AM
 #44

At least python and ruby are both implemented in a wide variety of other languages, not just C.
My point is that every language eventually reduces to C somewhere, even C++.

Diapolo
Hero Member
*****
Offline Offline

Activity: 766


Bitcoin-Qt co-developer


View Profile WWW

Ignore
March 18, 2012, 01:17:38 AM
 #45

I always use MS EMET on Windows, to make application bugs or security issues harder to exploit. I can confirm MS EMET 2.1 can be used with 0.6 RC4 and did work with all earlier versions of the BC client. Have a look here: https://www.microsoft.com/download/en/details.aspx?id=1677

You just have to install it and add bitcoin-qt.exe and bitcoind.exe to it's application list.

Dia

Like my work for Bitcoin-Qt?
1PwnvixzVAKnAqp8LCV8iuv7ohzX2pbn5x
bitcoin:1PwnvixzVAKnAqp8LCV8iuv7ohzX2pbn5x?label=Diapolo
Luke-Jr
Hero Member
*****
Offline Offline

Activity: 1218



View Profile

Ignore
March 18, 2012, 01:49:10 AM
 #46

FYI, Windows binaries from the 0.6.0rc4 source (in git) will not get you a fixed build.

Revalin
Hero Member
*****
Offline Offline

Activity: 700


165YUuQUWhBz3d27iXKxRiazQnjEtJNG9g


View Profile

Ignore
March 18, 2012, 02:06:28 AM
 #47

My point is that every language eventually reduces to C somewhere, even C++.


While true, string and array handling is very well-proven in Python/Ruby/etc.  You are far more likely to make an input bounds checking error in C than to discover an existing bug in Python's read().

It's not a silver bullet, but it helps.

      War is God's way of teaching Americans geography.  --Ambrose Bierce
Bitcoin is the Devil's way of teaching geeks economics.  --Revalin 165YUuQUWhBz3d27iXKxRiazQnjEtJNG9g
Luke-Jr
Hero Member
*****
Offline Offline

Activity: 1218



View Profile

Ignore
March 18, 2012, 05:51:08 AM
 #48

Here are Windows binaries for coderrr's coin control patchset with 0.5.3.1 fix applied

Diapolo
Hero Member
*****
Offline Offline

Activity: 766


Bitcoin-Qt co-developer


View Profile WWW

Ignore
March 18, 2012, 10:36:22 AM
 #49

FYI, Windows binaries from the 0.6.0rc4 source (in git) will not get you a fixed build.

How long do you plan to keep the fix "secret" and what's the deadline for making the vulnerability public?

Dia

Like my work for Bitcoin-Qt?
1PwnvixzVAKnAqp8LCV8iuv7ohzX2pbn5x
bitcoin:1PwnvixzVAKnAqp8LCV8iuv7ohzX2pbn5x?label=Diapolo
coreking
Newbie
*
Offline Offline

Activity: 11


View Profile

Ignore
March 18, 2012, 12:56:21 PM
 #50

Sure the language that is chosen eventually reduces to native code, however you can use a minimal amount of native code to "boot strap" the language, then write the more advanced language features in the language itself. Then you only have a small amount of code to review for low level issues, such as memory corruption.

A few languages are implemented in this way, the GHCi Haskell compiler apparently uses a "stripped down" C language called "C--" to do the bootstrapping.

So there definitely appear to be advantages in writing security critical applications in high level languages...
Gavin Andresen
Hero Member
*****
Offline Offline

Activity: 1330


Chief Scientist


View Profile WWW

Ignore
March 18, 2012, 01:44:12 PM
 #51

How long do you plan to keep the fix "secret" and what's the deadline for making the vulnerability public?
We'll release full detail tomorrow (Monday) at 16:00 GMT, after essentially the entire world has had a chance to go into work Monday morning, see the alert message, and shutdown/upgrade.

Will I see you in Amsterdam?
  http://bitcoin2014.com/
CIYAM
Hero Member
*****
Offline Offline

Activity: 910


Ian Knowles - CIYAM Lead Developer


View Profile WWW

Ignore
March 18, 2012, 01:47:19 PM
 #52

And there's a long list of languages immune to buffer overflows (this is mostly a glaring hole in C/C++).

So exactly how do you get a buffer overflow using std::string?

With CIYAM anyone can create 100% generated C++ web applications in literally minutes.

GPG Public Key | 1ciyam3htJit1feGa26p2wQ4aw6KFTejU
coinft
Full Member
***
Offline Offline

Activity: 174



View Profile

Ignore
March 18, 2012, 02:55:57 PM
 #53

Sure the language that is chosen eventually reduces to native code, however you can use a minimal amount of native code to "boot strap" the language, then write the more advanced language features in the language itself. Then you only have a small amount of code to review for low level issues, such as memory corruption.

A few languages are implemented in this way, the GHCi Haskell compiler apparently uses a "stripped down" C language called "C--" to do the bootstrapping.

So there definitely appear to be advantages in writing security critical applications in high level languages...

Exactly. Other examples are pypy (python written in python, capable of creating new advanced pypy versions without a C compiler), and many variations of lisp. The key is having a compiler toolchain written in the language itself. After some iterations the original C-code used to bootstrap (if it was C) can be replaced totally.

After all, you needed assembler or direct machine code to bootstrap a C compiler if you didn't use fortran or something else, C is not  magically special, it's just widely used. You could say everything boils down to machine code eventually, but than there's CPU micro/nano code and the original arguments become quite absurd.

-coinft

cypherdoc
Hero Member
*****
Offline Offline

Activity: 1120



View Profile

Ignore
March 18, 2012, 03:00:24 PM
 #54

How long do you plan to keep the fix "secret" and what's the deadline for making the vulnerability public?
We'll release full detail tomorrow (Monday) at 16:00 GMT, after essentially the entire world has had a chance to go into work Monday morning, see the alert message, and shutdown/upgrade.

take your time.  maybe Tuesday?
Luke-Jr
Hero Member
*****
Offline Offline

Activity: 1218



View Profile

Ignore
March 18, 2012, 06:06:54 PM
 #55

The key is having a compiler toolchain written in the language itself. After some iterations the original C-code used to bootstrap (if it was C) can be replaced totally.
Only if the language can be compiled to native code at all. In which case it's just as "at risk" of buffer overflows etc as C++ is. For Python, Java (for practical purposes; GCJ seems to have trouble with most real Java software), etc, they cannot be compiled to native code, and thus always require a C/equivalent interpretor.

BrightAnarchist
Donator
Hero Member
*
Offline Offline

Activity: 842



View Profile

Ignore
March 18, 2012, 08:21:44 PM
 #56

Quote
about 3 days ago i was commenting on the language choice.
from a software architecture standpoint other languages than c++ would make more sense in such a sensitive area.

This is nonsense. If anything, more advanced languages can have their own vulnerabilities which could bitcoin vulnerable without any mistakes acutally made by the developers. This is almost impossible with a low level language like c++.
Apart from that, a program's security does not depend on the language, it depends on the coding.

I'm sorry but you are completely wrong here.

You have to be god-like to not create security vulnerabilities in significantly C/C++ software.  'Direct' buffer overflows can be avoided by littering your code with meticulous boiler plate (and praying you haven't made a mistake somewhere).  But integer overflows leading to buffer overflows are so hopelessly trickly that I have no faith in any C/C++ being safe.

Java/Python/Ruby/Lisp buffer overflows simply don't exist... a huge class of exploit eradicated by language choice.  And there's a long list of languages immune to buffer overflows (this is mostly a glaring hole in C/C++).  Look up US military/intelligence mandates about language choice.  C/C++ is so bad that it should be immediately abandoned and _never_ used for _anything_.  Why do you think computer security is such a disaster (it was all C/C++ until the recent xss/xsrf/sql havoc - and that too is a design flaw).

That you think "this is nonsense" means that your own code is already insecure, and you just don't know it.


+1

C++ used to be my favorite language... until I learned Lisp and Python.

Now my foot is finally recovering from being shot too many times
defxor
Hero Member
*****
Offline Offline

Activity: 530


View Profile

Ignore
March 18, 2012, 11:32:59 PM
 #57

Only if the language can be compiled to native code at all. In which case it's just as "at risk" of buffer overflows etc as C++ is. For Python, Java (for practical purposes; GCJ seems to have trouble with most real Java software), etc, they cannot be compiled to native code, and thus always require a C/equivalent interpretor.

Sorry, but no. Buffer overflow opportunities don't somehow appear in library code just because the calling program has been compiled. (And Java JIT is a compiler, there's no difference between doing the compiling statically beforehand or dynamically when needed).
Gavin Andresen
Hero Member
*****
Offline Offline

Activity: 1330


Chief Scientist


View Profile WWW

Ignore
March 19, 2012, 04:02:51 PM
 #58

Full disclosure blog post is at:
  http://gavintech.blogspot.com/2012/03/full-disclosure-bitcoin-qt-on-windows.html

Executive summary: we were compiling Windows binaries with the wrong flags.

Will I see you in Amsterdam?
  http://bitcoin2014.com/
makomk
Hero Member
*****
Offline Offline

Activity: 686


View Profile

Ignore
March 19, 2012, 04:29:13 PM
 #59

Full disclosure blog post is at:
  http://gavintech.blogspot.com/2012/03/full-disclosure-bitcoin-qt-on-windows.html

Executive summary: we were compiling Windows binaries with the wrong flags.

Ah, so it was that. A quick Google at the time turned up this mailing list message which has an interesting explanation of what apparently happens if you do that. Not sure if it's accurate though.

Just out of curiosity, are non-gitian Windows compiles of bitcoin-qt safe now?

Quad XC6SLX150 Board: 860 MHash/s or so.
SIGS ABOUT BUTTERFLY LABS ARE PAID ADS
dooglus
Hero Member
*****
Offline Offline

Activity: 1036


firstbits: 1doog7


View Profile WWW

Ignore
March 19, 2012, 04:32:50 PM
 #60

FYI, Windows binaries from the 0.6.0rc4 source (in git) will not get you a fixed build.

Why's that?  The v0.6.0rc4 tag includes the -lmingwthrd fix.

When I first saw your post I figured I must have guessed wrongly what the update was all about, because the changes for safe multi-threading in mingw were included in the rc4 source.

REF
Hero Member
*****
Offline Offline

Activity: 519


View Profile

Ignore
March 19, 2012, 04:34:57 PM
 #61

Full disclosure blog post is at:
  http://gavintech.blogspot.com/2012/03/full-disclosure-bitcoin-qt-on-windows.html

Executive summary: we were compiling Windows binaries with the wrong flags.


nicely worded article. very straight forward and easy to understand. even those with limiting coding knowledge should get it.
Luke-Jr
Hero Member
*****
Offline Offline

Activity: 1218



View Profile

Ignore
March 19, 2012, 04:40:41 PM
 #62

FYI, Windows binaries from the 0.6.0rc4 source (in git) will not get you a fixed build.

Why's that?  The v0.6.0rc4 tag includes the -lmingwthrd fix.

When I first saw your post I figured I must have guessed wrongly what the update was all about, because the changes for safe multi-threading in mingw were included in the rc4 source.
The v0.6.0rc4 tag includes the fix, but it removes -lmingw only in the gitian build of Qt. Since it doesn't also change the filename, there is a probability anyone using gitian will not rebuild Qt; they, and non-gitian builders, will therefore not get the change. I submitted a pull request to move the change to bitcoin-qt.pro where it belongs, and incorporated this into the v0.5.3.1 tag.

While it would be possible (and in the case of the binaries, was done) to build v0.6.0rc4 with the adjusted Qt, doing so required inside knowledge of the fix, and could not be explained without disclosing the nature of the security issue; therefore, I stuck with a blanket "will not" to be on the safe side.

Schwede65
Sr. Member
****
Offline Offline

Activity: 300


View Profile

Ignore
March 19, 2012, 10:24:39 PM
 #63


now please for the non-coders:

are the the posted (above) windows-binaries safe?
Pieter Wuille
Hero Member
*****
Offline Offline

Activity: 938


View Profile WWW

Ignore
March 19, 2012, 10:25:49 PM
 #64


Yes.

aka sipa, core dev team

Tips and donations: 1KwDYMJMS4xq3ZEWYfdBRwYG2fHwhZsipa
Nyaaan
Full Member
***
Offline Offline

Activity: 140


View Profile WWW

Ignore
March 22, 2012, 01:33:23 PM
 #65

Quote
about 3 days ago i was commenting on the language choice.
from a software architecture standpoint other languages than c++ would make more sense in such a sensitive area.

This is nonsense. If anything, more advanced languages can have their own vulnerabilities which could bitcoin vulnerable without any mistakes acutally made by the developers. This is almost impossible with a low level language like c++.
Apart from that, a program's security does not depend on the language, it depends on the coding.

I'm sorry but you are completely wrong here.

You have to be god-like to not create security vulnerabilities in significantly C/C++ software.  'Direct' buffer overflows can be avoided by littering your code with meticulous boiler plate (and praying you haven't made a mistake somewhere).  But integer overflows leading to buffer overflows are so hopelessly trickly that I have no faith in any C/C++ being safe.

Java/Python/Ruby/Lisp buffer overflows simply don't exist... a huge class of exploit eradicated by language choice.  And there's a long list of languages immune to buffer overflows (this is mostly a glaring hole in C/C++).  Look up US military/intelligence mandates about language choice.  C/C++ is so bad that it should be immediately abandoned and _never_ used for _anything_.  Why do you think computer security is such a disaster (it was all C/C++ until the recent xss/xsrf/sql havoc - and that too is a design flaw).

That you think "this is nonsense" means that your own code is already insecure, and you just don't know it.


+1

C++ used to be my favorite language... until I learned Lisp and Python.

Now my foot is finally recovering from being shot too many times

I think you mean your knee.

Also, thank you for the fix, developers.
NothinG
Hero Member
*****
Offline Offline

Activity: 560



View Profile

Ignore
March 23, 2012, 03:23:20 AM
 #66



Anyone else having this problem?

Diapolo
Hero Member
*****
Offline Offline

Activity: 766


Bitcoin-Qt co-developer


View Profile WWW

Ignore
March 23, 2012, 05:53:12 AM
 #67



Anyone else having this problem?

You could try this, perhaps it's related: https://bitcointalk.org/index.php?topic=66887.msg779221#msg779221

Dia

Like my work for Bitcoin-Qt?
1PwnvixzVAKnAqp8LCV8iuv7ohzX2pbn5x
bitcoin:1PwnvixzVAKnAqp8LCV8iuv7ohzX2pbn5x?label=Diapolo
NothinG
Hero Member
*****
Offline Offline

Activity: 560



View Profile

Ignore
March 23, 2012, 05:59:25 AM
 #68


You could try this, perhaps it's related: https://bitcointalk.org/index.php?topic=66887.msg779221#msg779221

Dia
I just tried that, seemed to make it worse. Looked into the logs (new information after what Diapolo said to do), said something about the indexing.
So, I am re-building my blkindex.dat.
I'll post what I find.

JackH
Sr. Member
****
Offline Offline

Activity: 247


View Profile WWW

Ignore
March 24, 2012, 11:53:07 AM
 #69

Is this affecting Bitcoin version 0.3.21?

Want to list your bitcoin related website and get more traffic? Go to http://www.findabitcoin.com

Visit our Web Design company on http://www.thinlinedata.com

-----------------------------------------
Cyprus Central Bank has warned that using the virtual currency Bitcoin is dangerous!

Bacteria has warned that using Penicillin is dangerous.
Vandroiy
Hero Member
*****
Offline Offline

Activity: 980


View Profile

Ignore
March 24, 2012, 01:53:11 PM
 #70

+1 for an implementation in a safer language.

I keep saying the same thing; it's just absurd to use a highspeed-hacker-language for financial transactions.

We need another client for broad usage. If everyone hates Mono so much, well then use Java or something, but not something that cares little about type safety, operates directly on memory pointers etc. Think aspect-oriented programming, contracts, this is the kind of stuff we need, and it's as far from C++ as you get.
Pieter Wuille
Hero Member
*****
Offline Offline

Activity: 938


View Profile WWW

Ignore
March 24, 2012, 01:57:09 PM
 #71

Is this affecting Bitcoin version 0.3.21?

No, only windows version of Bitcoin-Qt are affected, a GUI that was only merged in 0.5.0.

However, it's generally a bad idea to keep using such old versions...

aka sipa, core dev team

Tips and donations: 1KwDYMJMS4xq3ZEWYfdBRwYG2fHwhZsipa
Luke-Jr
Hero Member
*****
Offline Offline

Activity: 1218



View Profile

Ignore
March 24, 2012, 02:02:09 PM
 #72

Is this affecting Bitcoin version 0.3.21?
Not this, but 0.3.* are not maintained and have several security and other bugs. Upgrade to at least 0.4.4.

Diapolo
Hero Member
*****
Offline Offline

Activity: 766


Bitcoin-Qt co-developer


View Profile WWW

Ignore
March 24, 2012, 02:08:05 PM
 #73

+1 for an implementation in a safer language.

I keep saying the same thing; it's just absurd to use a highspeed-hacker-language for financial transactions.

We need another client for broad usage. If everyone hates Mono so much, well then use Java or something, but not something that cares little about type safety, operates directly on memory pointers etc. Think aspect-oriented programming, contracts, this is the kind of stuff we need, and it's as far from C++ as you get.

I hate Java more than Python, than Basic ... Windows is written in what language? Linux kernel is written in?

Dia

Like my work for Bitcoin-Qt?
1PwnvixzVAKnAqp8LCV8iuv7ohzX2pbn5x
bitcoin:1PwnvixzVAKnAqp8LCV8iuv7ohzX2pbn5x?label=Diapolo
Pieter Wuille
Hero Member
*****
Offline Offline

Activity: 938


View Profile WWW

Ignore
March 24, 2012, 02:14:04 PM
 #74

+1 for an implementation in a safer language.

I keep saying the same thing; it's just absurd to use a highspeed-hacker-language for financial transactions.

We need another client for broad usage. If everyone hates Mono so much, well then use Java or something, but not something that cares little about type safety, operates directly on memory pointers etc. Think aspect-oriented programming, contracts, this is the kind of stuff we need, and it's as far from C++ as you get.

I hate Java more than Python, than Basic ... Windows is written in what language? Linux kernel is written in?

Dia

Can you please stop discussing what language Bitcoin clients are supposed to be written in? This thread is about the specific security problem found here.

Start a discussion in the dev section, if you like a language flamewar.

aka sipa, core dev team

Tips and donations: 1KwDYMJMS4xq3ZEWYfdBRwYG2fHwhZsipa
Luke-Jr
Hero Member
*****
Offline Offline

Activity: 1218



View Profile

Ignore
March 26, 2012, 09:16:58 PM
 #75

FWIW, this issue has been assigned CVE-2012-1910

Diapolo
Hero Member
*****
Offline Offline

Activity: 766


Bitcoin-Qt co-developer


View Profile WWW

Ignore
March 27, 2012, 05:23:08 AM
 #76

FWIW, this issue has been assigned CVE-2012-1910

That's a great step, it would be even better to link the advisory. One I found by that number was for JavaRE and the other for Bind DNS :-/.

Dia

Like my work for Bitcoin-Qt?
1PwnvixzVAKnAqp8LCV8iuv7ohzX2pbn5x
bitcoin:1PwnvixzVAKnAqp8LCV8iuv7ohzX2pbn5x?label=Diapolo
Luke-Jr
Hero Member
*****
Offline Offline

Activity: 1218



View Profile

Ignore
March 27, 2012, 05:24:11 AM
 #77

FWIW, this issue has been assigned CVE-2012-1910

That's a great step, it would be even better to link the advisory. One I found by that number was for JavaRE and the other for Bind DNS :-/.

Dia
This thread is the advisory...

Diapolo
Hero Member
*****
Offline Offline

Activity: 766


Bitcoin-Qt co-developer


View Profile WWW

Ignore
March 27, 2012, 05:27:14 AM
 #78

FWIW, this issue has been assigned CVE-2012-1910

That's a great step, it would be even better to link the advisory. One I found by that number was for JavaRE and the other for Bind DNS :-/.

Dia
This thread is the advisory...

Then who did chose that CVE numbers? I thought these numbers were assigned by an external company or organisation ... my fault then.

Like my work for Bitcoin-Qt?
1PwnvixzVAKnAqp8LCV8iuv7ohzX2pbn5x
bitcoin:1PwnvixzVAKnAqp8LCV8iuv7ohzX2pbn5x?label=Diapolo
Pieter Wuille
Hero Member
*****
Offline Offline

Activity: 938


View Profile WWW

Ignore
March 27, 2012, 02:20:12 PM
 #79

The numbers are chosen by an external advisory yes, but apparently it's just a number to identify the problem.

I think it'd be a little more useful if information about the issue could actually be found in online databases directly about it.

aka sipa, core dev team

Tips and donations: 1KwDYMJMS4xq3ZEWYfdBRwYG2fHwhZsipa
Diapolo
Hero Member
*****
Offline Offline

Activity: 766


Bitcoin-Qt co-developer


View Profile WWW

Ignore
March 27, 2012, 02:35:27 PM
 #80

The numbers are chosen by an external advisory yes, but apparently it's just a number to identify the problem.

I think it'd be a little more useful if information about the issue could actually be found in online databases directly about it.

I had exactly this in my mind Smiley, a public database, an external given ID and independent information about issues.

Dia

Like my work for Bitcoin-Qt?
1PwnvixzVAKnAqp8LCV8iuv7ohzX2pbn5x
bitcoin:1PwnvixzVAKnAqp8LCV8iuv7ohzX2pbn5x?label=Diapolo
fabrizziop
Hero Member
*****
Offline Offline

Activity: 557


Mining LTC @ 4.5 MH/s (I'm NOT lending)


View Profile

Ignore
April 01, 2012, 01:28:41 AM
 #81

Is it safe to use the 0.6.0 version?, newly released.

fabrizziop @ overclock.net, Reddit, THV, steam, #bitcoin-otc, TF2WH forum
BTC:1CgmAeaAq5X4kX17sH6kK4ZTJ3yqz9XFAo LTC:LR8M2umTw8yzSCQeNvQ1tXpwRhZgLHGCzQ XPM:AL6eTq3E4gRGruDtPKnuWrTu8BfceXXBYQ
NMC:MwhCNjThygv6Aw46C9YhtgJiKWCFniiYd8 Bitmessage:BM-2D7ardTxmgMsewNGxQuMd3p8448hjjGb7r
Luke-Jr
Hero Member
*****
Offline Offline

Activity: 1218



View Profile

Ignore
April 01, 2012, 01:41:18 AM
 #82

Is it safe to use the 0.6.0 version?, newly released.
Yes

Pages: 1 2 3 4 5 [All]
  Print  
 
Jump to:  

Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!