An upgrade to Bitcoin-qt was released today and consists of several security and bug fixes bundled for release as version 0.8.4. It is recommended that all users upgrade immediately, since the release of these fixes makes finding the vulnerabilities in older code trivial. Included in this release are three security updates as well as several small bug fixes that were causing the application to crash or databases to become corrupted.
Denial of Service Fix
Bitcoin-qt 0.8.0 introduced Bloom Filters which allow for more flexibility with respect to how much of the block chain must be downloaded. Bloom Filters are a compact data structure that allows for some false-positives but no false-negatives, which implies you can be certain all of your data will be included in a query, but there may be some results included that are not related.
Bloom Filters allowed for the implementation of simplified payment verification (SPV) clients – which only download block headers and do not need to store all transactions in the block chain locally. These clients query nodes instead. For example, a client could query a node with an address to retrieve all relevant transactions and verify them with the block header information.
There were several security vulnerabilities discovered in the 0.8.0 Bloom Filter implementation which allowed an attacker to perform a denial-of-service attack. One version quickly overwhelmed the disk read/write ability of nodes causing them to lag several blocks behind consensus, while another was able to send messages to Bitcoin-qt clients causing them to crash.
In previous versions of bitcoin-qt RPC (remote procedure call) commonly used for servers, the password was verified by comparing the entered password to the stored password byte-by-byte. Effectively, the client would loop through the password letter by letter until there was a missmatch and return a failure. The closer a password was to being correct the longer it would take to return the failure. For example if the correct password was “andresen123”, it would take longer to verify “apple” than “bitcoin” or “chain,” so the attacker could feel comfortable that the start of apple was correct character. Similarly, “animal” would take longer than “apple” (since the “an” matches) and the attacker could continue to iterate through passwords until the correct one is brute forced.
It is worth noting that the attacker would have to have extremely precise measurements in order attempt a successful attack. Most internet connections would have too much variability in response time to make this viable, so in most instances the attacker would have to be on the same local network as the victim’s computer. To solve this vulnerability bitcoin-qt implemented a constant-time algorithm for password attempts. This means that regardless of how close a password guess is to the true answer it will always take the same amount of time to reply whether the guess was successful.
Orphan Transaction Security Fix
Bitcoin-qt 0.8.3 introduced a solution to a memory-exhaustion attack that required truncating transaction messages. Prior to this implementation, a malicious attacker could send non-truncated transactions causing bitcoin nodes to crash as their memory was overwhelmed. Unfortunately, the method used to truncate transactions introduced additional vulnerabilities as identified by bitslog in July.
These vulnerabilities are related to the fact that transactions are stored deserialized and truncated using descriptive parameters (related to resizing) which could potentially conflict with the transaction when it is serialized again. The effect of this is that a malicious party could exploit these parameters to create transactions that initially appear valid, but when combined with truncating parameters are in-fact invalid.
There are two potential transaction attacks that were resolved in the latest fix. The first vulnerability is related to any nodes that accept zero-confirmation transactions. An attacker would have been able to double-spend bitcoins by transmitting an invalid transaction directly to a victim’s node, and then transmitting a separate valid transaction to the rest of the network. The victim would accept the transaction but it would then be rejected when a miner tries to add it to a block.
The second attack exploits the difference in 0.8.3 and bitcoinj clients. An attacker could spread malicious transactions through the network that would go unnoticed by older clients. When 0.8.3 clients truncate these invalid transactions it will force all bitcoinj clients to disconnect from 0.8.3, harming all 0.8.3 and bitcoinj nodes that now lost connections to their peers.
Users wishing to upgrade do not need to redownload the entire block chain. Download the appropriate file for your operating system (or compile it yourself) and follow the related steps:
Users upgrading from versions prior to 0.8.0 are not properly indexed for Bloom Filtering and require re-indexing the block chain. While this is takes less time than redownloading the entire block chain, it is not insignificant. Be sure to back up your wallet file incase there are any issues during the installation.
The following developers contributed to the 0.8.4 update:
Sergio Demian Lerner