Bitslog

A month ago I presented my talk about Bitcoin and Mavepay at Ekoparty 2012. The second part of the talk was about Bitcoin vulnerabilities. I talked about the four Denial of Service vulnerabilities I found and “Avalanche”, the most deadly one, carefully hiding information not to let an attacker create an exploit. It was fun. The slides will be available in this blog soon.

Since its inception, Bitcoin had an Achilles’ heel: the possibility that a hidden vulnerability could lead to a block chain split, or a network collapse. It was not the cracking ECDSA that scared people with crypto knowledge. It was the fact that a just a small undetected bug could cause a catastrophic network split. Or the fact that a single malformed message that is spread from node to node could cause a total network collapse. Bigger projects costing billions of dollars have failed because a single buggy line of code. Why not Bitcoin? Starting from version 0.7.0, Bitcoin can now be considered a mature project. The security critical sections of the source code are updated less and less frequently and those parts have been reviewed by many computer security experts. Also Bitcoin has passed the test of being on-line for more than 3 years.

Denial of Service

When I first looked at Bitcoin source code back in 2010 I thought It was designed and programmed with good knowledge of computer security. But it was not programmed by an security company. A security organization would tackle the DoS problem by design. How can DoS attacks be avoided by design? Do what every browser since Chrome started doing: encapsulate each connection in a sandbox that can be closely monitored (CPU, bandwidth, behavior, etc.). Since Bitcoin does not have such encapsulation, it required many checks to prevent a peer from doing nasty things. There are 17 checks in total.  8 of them were added after I reported vulnerabilities CVE-2012-3789, CVE-2012-4682 and CVE-2012-4683.

CVE-2012-4683 a.k.a “Avalanche” is the only DoS critical vulnerability found. In a certain scenario It allows an attacker to flood the network with messages and force each and every node to store and forward them. Since nobody knows the real topology of the Bitcoin network, the impact and time for a total collapse due to resource exhaustion is unknown, but I suspect it’s around 4 hours. That’s approximately 15000 servers going down. The ideal job for an Ecology-hacktivism group!

In those 4 hours, every node prior 0.7.0 must upgrade. Not big deal but I wonder if the fear of the uninformed would take the coin price down.

Lessons Learned

This is a list of thing that would have prevented the vulnerabilities from being created. I’m not saying anything new, but it’s good to remember them!

The last one I learned while researching on a proposal from a respected bitcoin user to improve Bitcoin.

1. One thing is to repair a low-level vulnerability (e.g. buffer overflow) and a completely different thing is to repair a vulnerability that arises from a logic error. The later being quite more challenging.
2. Always include the vuln reported/researcher in the repair workflow. He probably has a deeper understanding of the bug.
3. Never disregard a security vulnerability as un-exploitable. Fix it! Sooner or later an attacker may exploit it in a different unanalyzed context.
4. Where a bug has being found, further bugs are probably present.
5. The (pseudo) anonymization property of Bitcoin is the easiest property to be lost while modifying the code, since the related code is not encapsulated in a certain class or file, but spread all over the code.