Bitcoin Forum
April 27, 2015, 12:03:45 PM *
News: Latest stable version of Bitcoin Core: 0.10.0 [Torrent]
 
   Home   Help Search Donate Login Register  
Pages: 1 2 3 4 5 [All]
  Print  
Author Topic: URGENT: Windows Bitcoin-Qt update  (Read 20140 times)
Gavin Andresen
Legendary
*
Offline Offline

Activity: 1652


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

How often do you get the chance to work on a potentially world-changing project?
1430136225
Hero Member
*
Offline Offline

Posts: 1430136225

View Profile Personal Message (Offline)

Ignore
1430136225
Reply with quote  #2

1430136225
Report to moderator
pocketdiceAttention! This game is too realistic
and very addictive
Play now!
For the brave only

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

Posts: 1430136225

View Profile Personal Message (Offline)

Ignore
1430136225
Reply with quote  #2

1430136225
Report to moderator
1430136225
Hero Member
*
Offline Offline

Posts: 1430136225

View Profile Personal Message (Offline)

Ignore
1430136225
Reply with quote  #2

1430136225
Report to moderator
1430136225
Hero Member
*
Offline Offline

Posts: 1430136225

View Profile Personal Message (Offline)

Ignore
1430136225
Reply with quote  #2

1430136225
Report to moderator
1430136225
Hero Member
*
Offline Offline

Posts: 1430136225

View Profile Personal Message (Offline)

Ignore
1430136225
Reply with quote  #2

1430136225
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?

Fiyasko
Legendary
*
Offline Offline

Activity: 1428


Okey Dokey Lokey


View Profile

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

when was this discovered?!

http://bitcoin-otc.com/viewratingdetail.php?nick=DingoRabiit&sign=ANY&type=RECV <-My Ratings
https://bitcointalk.org/index.php?topic=857670.0 GAWminers and associated things are not to be trusted, Especially the "mineral" exchange
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: 54



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..
Clipse
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: 666


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
Legendary
*
Offline Offline

Activity: 1134


฿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
Legendary
*
Offline Offline

Activity: 1582



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
Legendary
*
Offline Offline

Activity: 1484



View Profile

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

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

Activity: 1582



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
cypherdoc
Legendary
*
Offline Offline

Activity: 1484



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: 784

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] 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
Legendary
*
Offline Offline

Activity: 1582



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
Global Moderator
Legendary
*
Offline Offline

Activity: 1400



View Profile

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

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

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

Tired of annoying signature ads? Ad block for signatures
Luke-Jr
Legendary
*
Offline Offline

Activity: 1582



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
Legendary
*
Offline Offline

Activity: 1134


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.

One off NP-Hard.
gmaxwell
Staff
Legendary
*
Offline Offline

Activity: 1442


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: 185


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
Legendary
*
Offline Offline

Activity: 1442


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: 309


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
Legendary
*
Offline Offline

Activity: 1162



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)

wumpus
Hero Member
*****
Offline Offline

Activity: 784

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] 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
can into space
Global Moderator
Legendary
*
Offline Offline

Activity: 1330



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
Legendary
*
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
Legendary
*
Offline Offline

Activity: 1442


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
Legendary
*
Offline Offline

Activity: 1582



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
Legendary
*
Offline Offline

Activity: 1582



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
can into space
Global Moderator
Legendary
*
Offline Offline

Activity: 1330



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
Legendary
*
Offline Offline

Activity: 1582



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
Global Moderator
Legendary
*
Offline Offline

Activity: 1400



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?

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

Tired of annoying signature ads? Ad block for signatures
stevegee58
Hero Member
*****
Offline Offline

Activity: 770



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: 185



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
Legendary
*
Offline Offline

Activity: 1582



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: 769


Bitcoin Core (GUI) 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 Core? Drop me a donation via:
1PwnvixzVAKnAqp8LCV8iuv7ohzX2pbn5x
bitcoin:1PwnvixzVAKnAqp8LCV8iuv7ohzX2pbn5x?label=Diapolo
Luke-Jr
Legendary
*
Offline Offline

Activity: 1582



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: 728


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
Legendary
*
Offline Offline

Activity: 1582



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: 769


Bitcoin Core (GUI) 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 Core? Drop me a donation via:
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
Legendary
*
Offline Offline

Activity: 1652


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.

How often do you get the chance to work on a potentially world-changing project?
CIYAM
Legendary
*
Online Online

Activity: 1260


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: 185



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
Legendary
*
Offline Offline

Activity: 1484



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
Legendary
*
Offline Offline

Activity: 1582



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
Legendary
*
Offline Offline

Activity: 853



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
Legendary
*
Offline Offline

Activity: 1652


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.

How often do you get the chance to work on a potentially world-changing project?
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
Legendary
*
Offline Offline

Activity: 1400



View Profile

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: 526


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
Legendary
*
Offline Offline

Activity: 1582



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: 309


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
Legendary
*
Offline Offline

Activity: 1008


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: 769


Bitcoin Core (GUI) 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 Core? Drop me a donation via:
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: 278


View Profile

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

Is this affecting Bitcoin version 0.3.21?
Vandroiy
Legendary
*
Offline Offline

Activity: 1008


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
Legendary
*
Offline Offline

Activity: 1008


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
Legendary
*
Offline Offline

Activity: 1582



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: 769


Bitcoin Core (GUI) 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 Core? Drop me a donation via:
1PwnvixzVAKnAqp8LCV8iuv7ohzX2pbn5x
bitcoin:1PwnvixzVAKnAqp8LCV8iuv7ohzX2pbn5x?label=Diapolo
Pieter Wuille
Legendary
*
Offline Offline

Activity: 1008


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
Legendary
*
Offline Offline

Activity: 1582



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: 769


Bitcoin Core (GUI) 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 Core? Drop me a donation via:
1PwnvixzVAKnAqp8LCV8iuv7ohzX2pbn5x
bitcoin:1PwnvixzVAKnAqp8LCV8iuv7ohzX2pbn5x?label=Diapolo
Luke-Jr
Legendary
*
Offline Offline

Activity: 1582



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: 769


Bitcoin Core (GUI) 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 Core? Drop me a donation via:
1PwnvixzVAKnAqp8LCV8iuv7ohzX2pbn5x
bitcoin:1PwnvixzVAKnAqp8LCV8iuv7ohzX2pbn5x?label=Diapolo
Pieter Wuille
Legendary
*
Offline Offline

Activity: 1008


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: 769


Bitcoin Core (GUI) 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 Core? Drop me a donation via:
1PwnvixzVAKnAqp8LCV8iuv7ohzX2pbn5x
bitcoin:1PwnvixzVAKnAqp8LCV8iuv7ohzX2pbn5x?label=Diapolo
fabrizziop
Hero Member
*****
Offline Offline

Activity: 567


Not mining anymore :(


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
Legendary
*
Offline Offline

Activity: 1582



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!