Security audit finds vulnerabilities across Bitcoin forks | Hacker News Reader

Security audit finds vulnerabilities across Bitcoin forks

bitcoinsv.io

68 pointsgalapago26 comments

As stated currently, the attacks are all DoS (but perhaps they downplay the severity before the full nature of attacks will be disclosed to the public?)

    The three vulnerabilities have been rated as medium 
    severity with low difficulty to exploit and expose the 
    Bitcoin node software to Denial of Service attacks 
    resulting in a high overall risk rating.

Would a DOS attack enable someone to do a double spend by taking honest nodes offline?

Yeah I think that's the problem: an attacker can gain a majority of dishonest nodes.

That isn't the case here.

(also, in Bitcoin "majority of nodes" doesn't do much to aid attacks)

Why not?

If you have a sizeable percentage of the mining power, and you can DDoS enough other miners to leave you with 51% of the mining power, doesn't that allow you to double-spend?

Edit: After reading other comments, I take it the answer to "why not?" is "because this isn't actually a DDoS".

Also because if it were, what you'd have to DDOS is hashpower not nodes-- and lots (hopefully most) hashpower is not directly inbound reachable: it connects outward, and only gets inbound connections via backup nodes at other locations.

This makes it harder to DOS attack since you don't know where it is.

This is just propaganda against other forms, by a well know conman who claims to be Satoshi. Someone should check the accounts to set I'd the positive comments are from him or bots.

Bitcoin SV is not Bitcoin. Just Curious, who actually owns the Bitcoin trademark?

The great thing about cryptocurrency being FOSS is that this can and likely will be fixed across all Bitcoin forks.

> CVE-2018-1000891 – Uncontrolled resource consumption when receiving messages with invalid checksums

This is really just a bandwidth DoS, which no client can protect against.

> CVE-2018-1000892 – Uncontrolled resource consumption when receiving sendheaders messages

This is really just a bandwidth DoS, which no client can protect against.

> CVE-2018-1000893 – Uncontrolled resource consumption when deserializing transactions

This is why the buffer is smaller in bitcoin than in these scamcoins.

Edit: Seems I made the scammers mad.

> This is really just a bandwidth DoS, which no client can protect against.

Couldn't the client just find and blacklist misbehaving nodes? (Which Bitcoin already does, right?)

> Couldn't the client just find and blacklist misbehaving nodes? (Which Bitcoin already does, right?)

That particular report is essentially "if you send a message with an invalid checksum, the peer just ignores the message and carries on instead of banning you and thereby wastes bandwidth and cpu time".

But this is kind of a pointless report (of a sort all too often produced by paid auditors :( ) -- the same "attacker" can simply send the same messages with a _valid_ checksum at no more cost to them, using the same resources, but totally bypassing the ban. So why bother?

There may be good or bad reasons to disconnect or ban a peer that does something incorrect or unexpected-- depending on the nature of the incorrect action--, but bans that can be evaded by sending one constant instead of another with the same resource usage are not useful protections against denial of service. A downside of this particular ban is that you'll ban hosts that are guilty of the crime of being behind an overactive NAT or idiotic censorware proxy...

[In fact, a lot of the motivation of the checksum is simply to avoid inappropriately banning peers whos messages were invalid simply due to the network corrupting their traffic. Banning on an invalid checksum defeats much of the purpose of the checksum in the first place.]

Bitcoin is moving away from bans more or less completely because of their minimal utility (over otherwise necessary anti-isolation handling) compared to the amount that they amplify the negative effects of simple misconfigration (or even, have themselves resulted in attacks).

The earlier poster's comment about bandwidth usage attacks is probably referring to the fact that no matter what your bitcoin software does a third party can still chew up inbound bandwidth by e.g. sending ICMP echo requests, SYNs, etc.

Not resilient against Sybil attack but might help mitigate poorly executed DoS.

What makes you think it's a bandwidth DoS (and therefore unprotectable)? The vague description sound more like the program is using excessive resources to handle certain messages, which reminds me of the hash algorithm collision DoSs, which weren't just bandwidth attacks. Do you know more details?

Calling it "scamcoin" without explaining anything just makes you seem uncredible. If you have information, please share it instead.

"Bitcoin SV" is the cryptocurrency created and promoted by a well known conman, Craig Wright ( https://en.bitcoin.it/wiki/Craig_Wright ), who has earned the ire of the Bitcoin community by, among many other things, fraudulently claiming to be the creator of Bitcoin.

More recently his creation of an incompatible competing clone of Bitcoin and calling it the confusingly similar name "Bitcoin Satoshi's Vision" has only furthered that irritation.

It's great and well appreciated that their development staff followed a good procedure with these reports (even though the reports weren't terribly interesting in this case), but that in no way excuses or validates the underlying fraudulent actions.

Craig Wright sounds like an ass. That doesn't help me understand why the poster was claiming these issues are irrelevant.

They describe issues fundamental to any software accepting remote connections from untrusted peers, ie they are entirely irrelevant.

You asked why he called that cryptocurrency a scam, -- you have your answer. :) He did not call it a scam due to the reports themselves, he addressed their merits individually.

The crypto space is full of trolls on all sides constantly making religious extremist type of statements against other crypto projects. It seems to me 80%+ of social media comments are of this type and was my primary decision point to sell any crypto assets where the community was more focused on infighting than solving issues like adoption, regulation, and security.

"This is why the buffer is smaller in bitcoin than in these scamcoins."

Are you saying that the buffer is smaller in Bitcoin because of that CVE issue? As in, the issue was discovered and the solution was the make the buffer smaller, instead of resolving the issue correctly?

Because reading that article seems to imply, at least, that core is affected that issue or am I reading that wrong? Or do you mean something like "lucky the buffer is smaller in core"? Saying that 'something is why something else' reads like that something else is what caused the something, and like I say, I find it hard to believe that the solution to that CVE was "forget fixing the actual problem, we'll just make the buffer smaller"...

The buffers in Bitcoin were specifically sized in response to known vulnerabilities long ago, some of which have been reintroduced by clones.

Appropriately sizing buffers is the correct fix in some cases... For example, when the vulnerability is that an attacker can make N connections and begin N max_size messages, causing the allocation of N*max_size ram a perfectly reasonable fix is making sure that the protocol guarantees that the maximum size of any single message is small enough that decoding N in parallel isn't an issue.

That's fair... I was completely misunderstanding the problem.

So is it that core is not affected by that last CVE at all, or just not as much as the others?

> So is it that core is not affected by that last CVE at all

Not at all.

"re: deserialization memory allocation: as should be obvious from the code snippet in the report, the Unersialize_impl function for vector types does not allocate more than 5MB at a time, instead ensuring the input stream has the neccessary amount of data to fill the allocation first. Thus, this function will never allocate (materially) more than the input stream, which in this case is limited by the maximum message size. In the case of Bitcoin Core this is limited to around 4MB, though again, I understand Bitcoin SV has significantly increased this limit. Thanks again for the report!"

Nice. I know this is a thing that I should be able to just read myself, but it's way too early (or is it late?) here, so I appreciate the information! Thanks.

Hello, CEO of Trail of Bits here -- we performed the security review of the Bitcoin Cash / Bitcoin SV code. Your characterization of the issues as "bandwidth denial of service" is incorrect and does not properly describe the impact.

The most significant findings in our report detail ways for messages to waste a victim’s CPU and network resources without triggering any of the denial-of-service mitigations that normally detect and ban misbehaving peers. We also discovered a variety of edge cases that enable similar denial of service potential where exploitation was not straightforward. These included specific code security issues. (I'm being intentionally vague, sorry)

The plan is to fully disclose our entire report at some point in the future, when the remainder of the Bitcoin clients have more fully implemented our recommendations.

Can you stop forward progress?

I already know you cannot because I did the work to prevent a malicious peer sending nonsense from doing that.

Reply on news.ycombinator.com