Bitcoin Forum
December 11, 2016, 12:44:59 AM *
News: Latest stable version of Bitcoin Core: 0.13.1  [Torrent].
 
   Home   Help Search Donate Login Register  
Pages: [1]
  Print  
Author Topic: DoS countermeasures may facilitate network fragmentation attacks  (Read 1167 times)
ByteCoin
Sr. Member
****
expert
Offline Offline

Activity: 416


View Profile
September 21, 2011, 03:18:32 AM
 #1

An attacker concocts two different sequences of blocks and/or transactions and/or other messages and injects them into the network at two points. Clients readily adopt and incorporate either one of the two sequences but, having adopted one they reject the other. Moreover,  the sequences are engineered so that the clients in possession of one sequence think that clients in possession of the other sequence are DoS attacking them. The DoS countermeasures then ensure that the two client groups ban each other. The situation is now ripe for a double-spend attack.

This conceptual attack is possible on the current network if a sequence could be found which would prevent the adoption of received valid blocks. It seems difficult to prove that no such sequences can exist. The DoS countermeasures might make an attack easier because clients will not accept valid blocks from a banned peer.

I therefore suggest that new block headers should always be accepted even from banned peers. If the hash is correct and of the required difficulty then the block should also be obtained from the peer.

A DoS attack which requires spamming targets with hashes of high difficulty would be ridiculously costly and if a client received such a stream then it could probably take it as a hint that it was on a small network fragment which had just reconnected or that SHA256 had been broken etc... Some action would be required other than just banning the peer and carrying on as normal.

Also, code which detects a substantial apparent loss of hashing power and prevents transactions from going confirmed should be developed and deployed in tandem with the DoS countermeasures code.

ByteCoin
1481417099
Hero Member
*
Offline Offline

Posts: 1481417099

View Profile Personal Message (Offline)

Ignore
1481417099
Reply with quote  #2

1481417099
Report to moderator
1481417099
Hero Member
*
Offline Offline

Posts: 1481417099

View Profile Personal Message (Offline)

Ignore
1481417099
Reply with quote  #2

1481417099
Report to moderator
1481417099
Hero Member
*
Offline Offline

Posts: 1481417099

View Profile Personal Message (Offline)

Ignore
1481417099
Reply with quote  #2

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

Posts: 1481417099

View Profile Personal Message (Offline)

Ignore
1481417099
Reply with quote  #2

1481417099
Report to moderator
1481417099
Hero Member
*
Offline Offline

Posts: 1481417099

View Profile Personal Message (Offline)

Ignore
1481417099
Reply with quote  #2

1481417099
Report to moderator
1481417099
Hero Member
*
Offline Offline

Posts: 1481417099

View Profile Personal Message (Offline)

Ignore
1481417099
Reply with quote  #2

1481417099
Report to moderator
etotheipi
Legendary
*
expert
Offline Offline

Activity: 1428


Core Armory Developer


View Profile WWW
September 21, 2011, 03:51:56 AM
 #2

Btw, you get a very similar vulnerability through timejacking (aka "forcing clock drift").  It's in the highest class of vulnerability according to the Bitcoin weaknesses page.  It does almost exactly what you propose, by forcing the node's clock to be more then 2 hours out of sync, it will reject a perfectly valid block while the rest of the network continues normally.  Since the rest of the network is building off that block, the victim node will not see any new blocks except for "poisoned blocks" sent by the attacker (who needs a bit of computing power to produce them, but nowhere near 50%).

I agree, nodes should "respect" block headers with the correct proof-of-work regardless of who sent them.  Although, this wouldn't benefit a victim of timejacking, I can't think of why it would be bad to accept them.

As for your last point, how does a node actually determine network speed?  Is it averaged over a certain number of previous block timestamps?  If it can measure this reliably and without too much latency, then this could be a very reliable indicator of something abnormal occurring.  In addition to targeted attacks like you suggest, if someone tried to DoS the main mining pools in an effort to boost their own computing power past 50%, there would be a similar drop in global computation speed and the client would go into some sort of safe-mode.

Founder and CEO of Armory Technologies, Inc.
Armory Bitcoin Wallet: Bringing cold storage to the average user!
Only use Armory software signed by the Armory Offline Signing Key (0x98832223)

Please donate to the Armory project by clicking here!    (or donate directly via 1QBDLYTDFHHZAABYSKGKPWKLSXZWCCJQBX -- yes, it's a real address!)
ByteCoin
Sr. Member
****
expert
Offline Offline

Activity: 416


View Profile
September 21, 2011, 04:09:16 AM
 #3

You get a very similar vulnerability through timejacking (aka "forcing clock drift")

Thanks for that!

My first thought for timejacking is that non-miners have no business having an opinion on what time it is. They should just follow the longest chain. If they choose to start rejecting blocks because they disagree with the time, they should then notice that the apparent hashrate has fallen and freeze. This limits the damage.
With miners, the decision to reject a block based on time is similar to the decision to reject a block because it doesn't clear up enough outstanding transactions, cartel enforcement etc..

ByteCoin
Gavin Andresen
Legendary
*
qt
Offline Offline

Activity: 1652


Chief Scientist


View Profile WWW
September 21, 2011, 12:44:29 PM
 #4

I like the idea of trying to prove that the DoS code doesn't increase the chance of network fragmentation.

The DoS countermeasures should be careful not to penalize or ban peers for any messages that the client will (or might, in another situation) relay.

For example, double-spent transactions don't trigger the DoS countermeasure code.

That should be sufficient to prevent split-the-network attacks; if an attacker wants to try to split the network, the only way the attacker would be successful is if it could somehow send messages to peers that ARE relayed and trigger disconnections elsewhere in the network.

Looking through the patch:
  https://github.com/bitcoin/bitcoin/pull/517/files

... I see a couple of cases where relayed messages are penalized (block times too far off, and hitting the free transaction relay limit).  To be safe, I'll remove them.

As for relaying block headers for banned peers:  "banned" means "if you try to connect to me I'll simply drop the connection attempt." I feel strongly that is the correct behavior; the motivation for the DoS prevention code is to "whitelist" peer behavior, and try to prevent possible 0-day attacks like "if I send you THIS invalid transactions followed by THAT sequence of weird bytes followed by THIS corrupted block header THEN I trigger an obscure bug in the version of OpenSSL that you're running and compromise your machine...."


How often do you get the chance to work on a potentially world-changing project?
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!