
Security audit finds vulnerabilities across Bitcoin forks - galapago
https://bitcoinsv.io/2019/03/01/bitcoin-sv-security-audit-helps-resolve-multiple-vulnerabilities-across-different-bitcoin-blockchains/
======
Erlich_Bachman
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.

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

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

~~~
nullc
That isn't the case here.

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

~~~
eridius
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".

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

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

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

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

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

~~~
Erlich_Bachman
> 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?)

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

