Published on: 2012-08-22T08:10:29+00:00
After a responsible disclosure of a vulnerability, Gavin made a commit to update the code with more information. However, the commit only mentions a denial-of-service (DoS) attack without providing further details. It is important to note the vulnerability of the Merkle hash function within the code as well.The vulnerability in unpatched Bitcoin installations allows for a permanent wedge at the current highest block. This is achieved by caching orphan blocks in a disk-backed database. Attackers can exploit this vulnerability by sending a valid block that eventually makes it into the blockchain and then making it invalid by duplicating one of the transactions while preserving the Merkle root. The attacker does not need to mine their own block but can mutate an existing block and pass it on to peers after listening for one.In addition, the vulnerability also enables attackers to hijack large miners and exchanges, resulting in double-spend attacks until miners realize they have been forked and fix their bitcoind. Attackers can target specific blocks they want orphaned by performing this attack on a majority of miners using the "tip" block they want to be orphaned. To mitigate this risk, Eloipool has attempted to produce blocks with transaction counts that are powers of two, as such blocks cannot be used for an attack against vulnerable clients.Furthermore, a flaw has been discovered in the Merkle hash implementation used by Bitcoin to calculate the Merkle root in a block header. This flaw allows an attacker to construct multiple lists of hashes that map to the same Merkle root. Consequently, two blocks can be created with the same block hash, but one will be valid while the other is invalid. This attack can be executed on unpatched Bitcoin installations, leading to a permanent wedge at the current highest block due to the caching of orphan blocks in the disk-backed database.When a victim receives the invalid block, it will be cached on disk, processed, and subsequently rejected as invalid. Re-requesting the block will not even be attempted because Bitcoin believes it already has the block, considering it has one with the same hash. To address this issue, Gavin Andresen implemented a rejection of blocks with duplicate transactions in CheckBlock, preventing them from being cached at all.
Updated on: 2023-08-01T03:53:19.357020+00:00