URGENT: Windows Bitcoin-Qt update

[Luke-Jr]

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

[1715341611]

1715341611

[1715341611]

1715341611

[1715341611]

1715341611

[1715341611]

1715341611

[Diapolo]

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

[Luke-Jr]

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

[Revalin]

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.

[Luke-Jr]

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

[Diapolo]

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

[coreking]

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]

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.

[CIYAM]

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?

[coinft]

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]

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]

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]

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]

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]

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.

[makomk]

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?

[dooglus]

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]

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]

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]

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/

now please for the non-coders:

are the the posted (above) windows-binaries safe?