Bitcoin Forum
June 20, 2019, 08:35:05 AM *
News: Latest Bitcoin Core release: 0.18.0 [Torrent] (New!)
 
   Home   Help Search Login Register More  
Pages: [1]
  Print  
Author Topic: [2017-03-16]What Caused the Bitcoin Unlimited Node Crash?  (Read 286 times)
wanderffa
Sr. Member
****
Offline Offline

Activity: 251
Merit: 250



View Profile
March 16, 2017, 03:13:51 AM
 #1

Bitcoin Unlimited nodes went down like a rock yesterday as a vulnerability was exploited. They now appear to have recovered, but the speed with which nodes fell is unprecedented.

The cause appears to be the use of “asserts” in production. This will get a bit technical, but we asked a pseudo-anonymous Bitcoin Unlimited developer who would rather not be named to provide an explanation for a non-technical audience. He told CCN:

“Assertions are used to capture programming errors, i.e. to check whether a condition that the programmer *believes* should hold true at a particular point in the program, actually holds true. If an assertion is triggered (by the expected condition not holding true) then they usually result in a short message and aborting the program.


// Let us help you become financially independent. Read exclusive stories, bitcoin analysis and tutorials. Use the coupon code "CCN" and get $10 off. Join Hacked.com now. //

They are not intended for handling user or run-time errors (e.g. invalid input data), and are therefore generally disabled after a program exits its debugging phase. An assert(0) in C/C++ program code, if hit, will abort the program with certainty.

In bitcoind code (BU as well as Core), assertions are ENABLED in the production builds for reasons that are perhaps a bit too complex to go into here.

What happened: BU developers left an assert(0) in a code path that could be reached due to input data (Xthin protocol request) not being adequately checked. This left a door open to someone who wanted to trigger that assert(0) to craft a special message which would make the BU software enter that code path.”

In more simplified terms, it is a method coders use in testing, but generally this method is automatically disabled once the client is launched for users to download. In bitcoin, however, that’s not the case. This method remains enabled. Thus, if asserts are not removed, that allows anyone with some skill to remote crash the nodes.

The BU developer further states that “it is not good practice to leave asserts active in production code because they are NOT designed for handling run-time errors, should use exceptions for that.

Leaving them ENABLED in production code is dangerous. There is an NDEBUG definition (stands for “no debug”). Normally this will disable asserts for the production version, but for “reasons”, the bitcoind codebases don’t do this.”

Bitcoin Unlimited developers are currently quite busy, so we didn’t press for an explanation of the “reasons,” but he says that the practice of leaving asserts enabled has to be carefully re-evaluated. “It is clearly not good programming practice. It makes such incidents possible.” – he continued.

We reached out to Matt Corallo, a Bitcoin Core developer, and others, to ask if an explanation could be provided on why the practice of leaving asserts enabled is used, but have not received a response in time for publishing.

The BU developer tells CCN :

“[There] needs to be a detailed incident report… touching e.g. code review, release of security-critical fixes, and working with security researchers and other Bitcoin client projects on the topic of responsible disclosure of such vulnerabilities.

As a developer, I am certain that there are more bugs in Bitcoin code, not just BU code. So, this issue is bigger than BU.”

It is not yet clear who exactly discovered the bug, but a fix was merged in BU yesterday around midday London time. Shortly after, Peter Todd, a Bitcoin Core developer, tweeted a link to the bug fix prior to new clients being released. The attack followed soon after. Peter Tschipper, a Bitcoin Unlimited developer, stated yesterday:

“The bug fix was merged…and literally within 30 minutes the attack happened. They just have been monitoring our Git…I was actually talking with [Andrea Suisani] at the time about maybe we should be more careful about using Git for these kind of things… and then minutes later the attack happened.”

Just hours before the attack, CCN published an article on Bitcoin Core supporters threatening zero-day exploits.

Around 200 Bitcoin Unlimited nodes withstood the attack. Haipo Yang, founder of viaBTC, a pool that mines Bitcoin Unlimited, told CCN that they were affected by yesterday’s events, but the pool’s node/s uses auto restart, “so the effect was not big.”

BU’s hashrate appears unchanged, now standing at 33% of network’s share.
https://www.cryptocoinsnews.com/caused-bitcoin-unlimited-node-crash/

Mine RVN and with 0% mining fees and get paid in BTC, ETH, XMR or RVN.

www.cudominer.com Get Cudo Miner
Auto coin switching, third-party miners, overclocking and remote management (Win/Linux)
Run from a USB stick or install from an ISO image (Linux)
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1561019705
Hero Member
*
Offline Offline

Posts: 1561019705

View Profile Personal Message (Offline)

Ignore
1561019705
Reply with quote  #2

1561019705
Report to moderator
1561019705
Hero Member
*
Offline Offline

Posts: 1561019705

View Profile Personal Message (Offline)

Ignore
1561019705
Reply with quote  #2

1561019705
Report to moderator
1561019705
Hero Member
*
Offline Offline

Posts: 1561019705

View Profile Personal Message (Offline)

Ignore
1561019705
Reply with quote  #2

1561019705
Report to moderator
cr1776
Legendary
*
Offline Offline

Activity: 2268
Merit: 1018


View Profile
March 16, 2017, 11:44:46 AM
Last edit: March 16, 2017, 05:41:47 PM by cr1776
 #2

Quote
...
The BU developer further states that “it is not good practice to leave asserts active in production code because they are NOT designed for handling run-time errors, should use exceptions for that.

Leaving them ENABLED in production code is dangerous. There is an NDEBUG definition (stands for “no debug”). Normally this will disable asserts for the production version, but for “reasons”, the bitcoind codebases don’t do this.” ...

And this is why developers who (a) are unfamiliar with the code, and (b) most importantly, are unfamiliar with good practices in developing high reliability, security critical software cannot be trusted to do so.

Testing occurs with the asserts active. Compiling without them (or any other debug code) creates different (and consequently untested) software. When security is critical, this is terrible practice and a mistake novice developers make.  

Further, different code can expose (different) compiler bugs etc.  Changing compiler optimization levels can cause similar issues.  

It is appalling that the BU developers are peddling nonsense like the quotations above - it only exposes their own ignorance.

The reason why asserts are left enabled, for CCN's reference, are as above.

notthematrix
Legendary
*
Offline Offline

Activity: 963
Merit: 1000


The All-in-One Cryptocurrency Exchange


View Profile
March 16, 2017, 12:34:00 PM
 #3

Code is like Mikado https://en.wikipedia.org/wiki/Mikado_(game)

██████
███
███
███
███
███
███
███
███
███
███
███
███
                ▄███
              ▄███▌ █
             ▀▀▀██▄  █
           ▄███▄▄ ▀▀▀█
          █ █████▀▀▀▄▄
         ▄██ ███▄    █
        ▐███▀   ▀█   █
        ████     █   █
       ▄██▀▄█▄▄▄█▀   █
       ▀▄▄███▌      █
   ▄▄▄▀▀▀████       █
 ▄▀    ██ ██       █
▐▌     ██▌▐▌      ▀▄
█      ██ █         ▀▄
█      █▀▄▌          █
█   ▄▀█▄██           █
█ ▄▀      ▀▀▄▄▀▄     █
▀▀             █    █
               █  ▄▀
               ▀▄█
     ▀█████████████▄▄
  ▀ ▀▀▀███████████████▌
   ▀ ▀▀▀▀██▀▀▀▀▀▀██████         ▄███████▄      ▄▄███████▄    ▄███▄    ▄███▄ ▄███▄      ▄███▄
▀ ▀▀▀▀█████▄▄▄▄▄▄█████▌       ▄████▀▀▀████▄   ▐████▀▀█████   ▀████▄  ▄████▀ █████▄    ▄█████
    ▀▀███████████████▀       █████     ████▌          ████▌    ▀████████▀    █████▄  ▄█████▌
   ▀ ▀████████████████▀ ▀    ██████████████▌   ▄▄██████████     ▄██████▄      █████▄▄█████▌
     ██████      ██▀▀▀▀▀▀▀ ▀ █████▀▀▀▀▀▀▀▀    █████▀▀▀█████    ▄████████▄      ██████████▌
     ██████▄▄▄▄▄▄██████▄ ▄    ████▄▄   ▄▄█▄   ████▄  ▄█████  ▄█████▀▀█████▄     ████████▌
     █████████████████▀        ▀███████████   ▀████████████  ████▀    ▀████      ██████▌
     ██████████████▀▀             ▀▀▀▀▀▀▀       ▀▀▀▀▀▀ ▀▀▀    ▀▀        ▀▀        █████
                                                                                ▄█████
                                                                            ▄███████▀
                                                                            ▀████▀▀
███
███
███
███
███
███
███
███
███
███
███
███
██████
|█████████████████
███████████████████
█████████████████████
███████████████████████
███████████████████████
███████████████████████
███████████████████████
███████████████████████
███████████████████████
███████████████████████
███████████████████████
███████████████████████
███████████████████████
  WHITEPAPER 
  LIGHTPAPER...
|Instant Deposit
✓ 24/7 Support
Referral Program
Pages: [1]
  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!