Fun with Bitcoin, or how an exploit can hide in plain sight [seclists.org]

[Andrew Bitcoiner]

http://coinbits.com/2012/02/01/fun-with-bitcoin-or-how-an-exploit-can-hide-in-plain-sight-seclists-org/

[1713961305]

1713961305

[1713961305]

1713961305

[rjk]

http://coinbits.com/2012/02/01/fun-with-bitcoin-or-how-an-exploit-can-hide-in-plain-sight-seclists-org/

A security vulnerability that is only exploitable with >51%, and which is fixed in recent versions of the bitcoin client. *Yawn...*

[piuk]

It comforting to know security experts are reviewing the code and this is the best exploit they can come up with.

[jimbobway]

It's a very expensive attack but far from impossible.

Lol.  Pretty much anything can be far from impossible.

I can levitate if all the air molecules around me randomly decide to lift me up which is far from impossible.

1 or 1 gaziillion is so far away from infinity.

[k]

From the article. (Bolding is mine)
http://seclists.org/fulldisclosure/2012/Feb/0

By full-disclosure standards this is actually old news; I disclosed it
semi-publicly to the Bitcoin developers about a month ago and they
committed a fix back then, and there's even been a Bitcoin release
0.5.2 since then which includes the fix (though only because one of
the other developers stubbornly insisted on creating a bugfix release
for other reasons - the head developer was strongly against it). All
previous 0.5.x releases were vulnerable and 0.6 hasn't been released
yet. I only just got around to looking into how the vulnerability got
in originally though and it doesn't appear anyone's really talked
about it.

This isn't a formal advisory either, more an example of how a
vulnerability can easily be introduced by a seemingly innocuous commit
and why the Bitcoin code needs more scrutiny.

More important than the flaw itself, is that it perhaps suggests that code changes are being made without proper review. I'd prefer to see a more conservative approach even if it meant a much slower development cycle.

[genjix]

More important than the flaw itself, is that it perhaps suggests that code changes are being made without proper review. I'd prefer to see a more conservative approach even if it meant a much slower development cycle.

Actually there is. I pointed this out to Gavin months ago in private chat but he disagreed with me. I still don't think the change was a good one. You don't comment out 2 lines of code because it produces a 6 hour speedup. The proper way is to restructure the code nicely but that takes more effort.

[k]

More important than the flaw itself, is that it perhaps suggests that code changes are being made without proper review. I'd prefer to see a more conservative approach even if it meant a much slower development cycle.

Actually there is. I pointed this out to Gavin months ago in private chat but he disagreed with me. I still don't think the change was a good one. You don't comment out 2 lines of code because it produces a 6 hour speedup. The proper way is to restructure the code nicely but that takes more effort.

yet the vulnerability still slipped in and had to be fixed later - if there were any question marks over any changes should there not be a much more thorough review before accepting the change?

[adamstgBit]

From the article. (Bolding is mine)
http://seclists.org/fulldisclosure/2012/Feb/0

By full-disclosure standards this is actually old news; I disclosed it
semi-publicly to the Bitcoin developers about a month ago and they
committed a fix back then, and there's even been a Bitcoin release
0.5.2 since then which includes the fix (though only because one of
the other developers stubbornly insisted on creating a bugfix release
for other reasons - the head developer was strongly against it). All
previous 0.5.x releases were vulnerable and 0.6 hasn't been released
yet. I only just got around to looking into how the vulnerability got
in originally though and it doesn't appear anyone's really talked
about it.

This isn't a formal advisory either, more an example of how a
vulnerability can easily be introduced by a seemingly innocuous commit
and why the Bitcoin code needs more scrutiny.

More important than the flaw itself, is that it perhaps suggests that code changes are being made without proper review. I'd prefer to see a more conservative approach even if it meant a much slower development cycle.

just do like me and wait some time b4 upgrading to the latest versions

[kjj]

A powerful attacker could definitely exploit this; timestamps in the
future are rejected and Bitcoin won't generally accept a version of
history in which time goes backwards, but otherwise a 51% attacker can
choose whatever timestamps they like and can delay releasing their
version of the chain to meet the "less than 10 seconds" requirement.
It's a very expensive attack but far from impossible.

Yeah.  Like this wouldn't be a huge arrow pointing directly at the attacker.  No one is going to notice a 144+ block reversion of the chain.  Right.

Still, looks like another case where my exponential difficulty requirement for blockchain reorganization idea would come in handy.  It would kill any and all offline mining attacks.

[vuce]

Still, looks like another case where my exponential difficulty requirement for blockchain reorganization idea would come in handy.  It would kill any and all offline mining attacks.

is there any reason why this wouldn't be implemented?

[kjj]

Still, looks like another case where my exponential difficulty requirement for blockchain reorganization idea would come in handy.  It would kill any and all offline mining attacks.

is there any reason why this wouldn't be implemented?

Ahh.  The fine print...

Turns out that no one is exactly sure what would happen in a few cases.  I have a rough understanding of what would happen most of the time, but nothing formal.  It is possible for sections of the network to become permanently diverged from the rest of the world, but the amount of time needed for that to happen depends very much on the size of the section that gets disconnected.  For example, if the network was split into two halves (by mining power) they could become irreconcilable in a relatively short time, like a few hours.  But who wouldn't notice the hashing power dropping by 50%?  A smaller split is less likely to be noticed, but will take longer to get screwed.  A solo miner that finds a block every month would need a year or more to get hopelessly wedged, and if he doesn't notice that he is really solo for that long, it is his problem.  (The exact times depend on the parameters of the exponential system.)

And it would complicate things if we ever needed to fix a bug like the signed/unsigned thing from a while back.  Right now, if a major bug is found, and it takes a day or two to get a fix made, as long as most of the mining pools get together, they can overtake the buggy chain and restore order to the entire network.  Under the exponential plan, each node would require human intervention unless the fix was found rather quickly.  I think that this will gradually become less of an argument as alternate clients gain popularity.  Once the monoculture gives way to the ecosystem, it simply won't be possible to do fixes in that way anyway.

Oh, and then there is the issue of starting up.  An attacker that can control which blocks a new node gets during the download can prevent it from ever meeting up with the rest of the network.  But there is no reason for a new node to be using the exponential system during the initial download anyway, so that isn't much of an issue in reality.