Bitcoin Forum
August 23, 2017, 01:03:48 AM *
News: Latest stable version of Bitcoin Core: 0.14.2  [Torrent].
 
   Home   Help Search Donate Login Register  
Pages: « 1 2 [3] 4 »  All
  Print  
Author Topic: URGENT: Windows Bitcoin-Qt update  (Read 26651 times)
Luke-Jr
Legendary
*
Offline Offline

Activity: 2240



View Profile
March 18, 2012, 12:29:56 AM
 #41

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

1503450228
Hero Member
*
Offline Offline

Posts: 1503450228

View Profile Personal Message (Offline)

Ignore
1503450228
Reply with quote  #2

1503450228
Report to moderator
1503450228
Hero Member
*
Offline Offline

Posts: 1503450228

View Profile Personal Message (Offline)

Ignore
1503450228
Reply with quote  #2

1503450228
Report to moderator
1503450228
Hero Member
*
Offline Offline

Posts: 1503450228

View Profile Personal Message (Offline)

Ignore
1503450228
Reply with quote  #2

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

Posts: 1503450228

View Profile Personal Message (Offline)

Ignore
1503450228
Reply with quote  #2

1503450228
Report to moderator
Diapolo
Hero Member
*****
Offline Offline

Activity: 769



View Profile WWW
March 18, 2012, 01:17:38 AM
 #42

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

Liked my former work for Bitcoin Core? Drop me a donation via:
1PwnvixzVAKnAqp8LCV8iuv7ohzX2pbn5x
bitcoin:1PwnvixzVAKnAqp8LCV8iuv7ohzX2pbn5x?label=Diapolo
Luke-Jr
Legendary
*
Offline Offline

Activity: 2240



View Profile
March 18, 2012, 01:49:10 AM
 #43

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
March 18, 2012, 02:06:28 AM
 #44

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



View Profile
March 18, 2012, 05:51:08 AM
 #45

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

Diapolo
Hero Member
*****
Offline Offline

Activity: 769



View Profile WWW
March 18, 2012, 10:36:22 AM
 #46

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

Liked my former work for Bitcoin Core? Drop me a donation via:
1PwnvixzVAKnAqp8LCV8iuv7ohzX2pbn5x
bitcoin:1PwnvixzVAKnAqp8LCV8iuv7ohzX2pbn5x?label=Diapolo
coreking
Newbie
*
Offline Offline

Activity: 11


View Profile
March 18, 2012, 12:56:21 PM
 #47

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
March 18, 2012, 01:44:12 PM
 #48

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

Activity: 1848


Ian Knowles - CIYAM Lead Developer


View Profile WWW
March 18, 2012, 01:47:19 PM
 #49

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



View Profile
March 18, 2012, 02:55:57 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...

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



View Profile
March 18, 2012, 03:00:24 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.

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

Activity: 2240



View Profile
March 18, 2012, 06:06:54 PM
 #52

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
March 18, 2012, 08:21:44 PM
 #53

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
March 18, 2012, 11:32:59 PM
 #54

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
March 19, 2012, 04:02:51 PM
 #55

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
March 19, 2012, 04:29:13 PM
 #56

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



View Profile
March 19, 2012, 04:32:50 PM
 #57

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.

Just-Dice                 ██             
          ██████████         
      ██████████████████     
  ██████████████████████████ 
██████████████████████████████
██████████████████████████████
██████████████████████████████
██████████████████████████████
██████████████████████████████
██████████████████████████████
██████████████████████████████
██████████████████████████████
██████████████████████████████
    ██████████████████████   
        ██████████████       
            ██████           
   Play or Invest                 ██             
          ██████████         
      ██████████████████     
  ██████████████████████████ 
██████████████████████████████
██████████████████████████████
██████████████████████████████
██████████████████████████████
██████████████████████████████
██████████████████████████████
██████████████████████████████
██████████████████████████████
██████████████████████████████
    ██████████████████████   
        ██████████████       
            ██████           
   1% House Edge
REF
Hero Member
*****
Offline Offline

Activity: 527


View Profile
March 19, 2012, 04:34:57 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.


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



View Profile
March 19, 2012, 04:40:41 PM
 #59

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
March 19, 2012, 10:24:39 PM
 #60


now please for the non-coders:

are the the posted (above) windows-binaries safe?
Pages: « 1 2 [3] 4 »  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!