URGENT: Windows Bitcoin-Qt update - page 2.

Luke-Jr

legendary

Activity: 2576

Merit: 1186

Quote from: dooglus on March 19, 2012, 11:32:50 AM

Quote from: Luke-Jr on March 17, 2012, 08:49:10 PM

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.

REF

hero member

Activity: 529

Merit: 500

Quote from: Gavin Andresen on March 19, 2012, 11:02:51 AM

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.

dooglus

legendary

Activity: 2940

Merit: 1333

Quote from: Luke-Jr on March 17, 2012, 08:49:10 PM

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.

makomk

hero member

Activity: 686

Merit: 564

Quote from: Gavin Andresen on March 19, 2012, 11:02:51 AM

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?

Gavin Andresen

legendary

Activity: 1652

Merit: 2316

Chief Scientist

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.

defxor

hero member

Activity: 530

Merit: 500

Quote from: Luke-Jr on March 18, 2012, 01:06:54 PM

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

BrightAnarchist

donator

Activity: 853

Merit: 1000

Quote from: ?? on ??

Quote from: Killdozer on March 17, 2012, 04:05:46 AM

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

Luke-Jr

legendary

Activity: 2576

Merit: 1186

Quote from: coinft on March 18, 2012, 09:55:57 AM

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.

cypherdoc

legendary

Activity: 1764

Merit: 1002

Quote from: Gavin Andresen on March 18, 2012, 08:44:12 AM

Quote from: Diapolo on March 18, 2012, 05:36:22 AM

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?

coinft

full member

Activity: 187

Merit: 100

Quote from: coreking on March 18, 2012, 07:56:21 AM

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

CIYAM

legendary

Activity: 1890

Merit: 1086

Ian Knowles - CIYAM Lead Developer

Quote from: grue on March 17, 2012, 11:25:51 AM

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?

Gavin Andresen

legendary

Activity: 1652

Merit: 2316

Chief Scientist

Quote from: Diapolo on March 18, 2012, 05:36:22 AM

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.

coreking

newbie

Activity: 11

Merit: 0

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

Diapolo

hero member

Activity: 772

Merit: 500

Quote from: Luke-Jr on March 17, 2012, 08:49:10 PM

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

Luke-Jr

legendary

Activity: 2576

Merit: 1186

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

Revalin

hero member

Activity: 728

Merit: 500

165YUuQUWhBz3d27iXKxRiazQnjEtJNG9g

Quote from: Luke-Jr on March 17, 2012, 07:29:56 PM

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

legendary

Activity: 2576

Merit: 1186

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

Diapolo

hero member

Activity: 772

Merit: 500

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

legendary

Activity: 2576

Merit: 1186

Quote from: coinft on March 17, 2012, 07:22:12 PM

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

coinft

full member

Activity: 187

Merit: 100

Quote from: Luke-Jr on March 17, 2012, 10:52:12 AM

Quote from: ?? on ??

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

Topic: URGENT: Windows Bitcoin-Qt update - page 2. (Read 28272 times)