Bitcoin Forum
December 05, 2016, 12:37:46 PM *
News: To be able to use the next phase of the beta forum software, please ensure that your email address is correct/functional.
 
   Home   Help Search Donate Login Register  
Pages: [1]
  Print  
Author Topic: Fun with Bitcoin, or how an exploit can hide in plain sight [seclists.org]  (Read 1492 times)
Andrew Bitcoiner
Sr. Member
****
Offline Offline

Activity: 397


Send correspondance to GPG key A372E7C6


View Profile WWW
February 01, 2012, 05:30:36 PM
 #1

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

MAKE MONEY! ADVERTISE FOR BITCOINS http://www.bitcoinadvertising.com
Bitcoin News Site http://coinbits.com
Bitcoin Blackjack http://bitjack21.com
Bitcoin, Darknet, IT consulting http://cryptophene.com
1480941466
Hero Member
*
Offline Offline

Posts: 1480941466

View Profile Personal Message (Offline)

Ignore
1480941466
Reply with quote  #2

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

Activity: 420


1ngldh


View Profile
February 01, 2012, 05:53:40 PM
 #2

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

Mining Rig Extraordinaire - the Trenton BPX6806 18-slot PCIe backplane [PICS] Dead project is dead, all hail the coming of the mighty ASIC!
piuk
Hero Member
*****
Offline Offline

Activity: 910



View Profile WWW
February 01, 2012, 05:59:04 PM
 #3

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

jimbobway
Legendary
*
Offline Offline

Activity: 1380



View Profile
February 01, 2012, 06:23:43 PM
 #4

Quote
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.

░░░░░░░░░██████░░░░░░░░░░░░▄▄▄
░░███░░██████░░░░░▄▄▄▄▄░░██
░░███░░█████████████
░░░░░░░░██████▀▀██████████
░░░░░░░░██████░░░░░██████████
░░░░░░▄▄▄▄▄▄░░░▄▄▄░░░░███████
░░░░░██████░░░███░░░░███████
░░░░░██████░░░███
░░░░░███████▄▄▄▄▄████████
░░░░░████████████████████
░░▄▄▄▄▄░░█████░░░░█████████
█████░░█████░░░░█████████
█████░░░░░░░░░░░░█████████
█████░░░░░░░░░░░░░█████████

START GETTING PAID FOR YOUR ATTENTION!
███████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████
JUSTICE IN THE WORLD OF ONLINE ADVERTISING!

BUY MASS COIN 】【 ICO PROSPECTUS
VISIT OUR WEBSITE
TWITTER 】【 FACEBOOK 】【 TELEGRAM

k
Sr. Member
****
Offline Offline

Activity: 452


View Profile
February 02, 2012, 12:24:09 AM
 #5

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

Quote
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
Legendary
*
Offline Offline

Activity: 1232


View Profile
February 02, 2012, 12:44:53 AM
 #6

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
Sr. Member
****
Offline Offline

Activity: 452


View Profile
February 02, 2012, 12:55:47 AM
 #7

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
Legendary
*
Offline Offline

Activity: 1904


Trusted Bitcoiner


View Profile WWW
February 02, 2012, 03:30:58 AM
 #8

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

Quote
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
Legendary
*
Offline Offline

Activity: 1302



View Profile
February 02, 2012, 05:46:17 PM
 #9

Quote
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.

p2pcoin: a USB/CD/PXE p2pool miner - 1N8ZXx2cuMzqBYSK72X4DAy1UdDbZQNPLf - todo
I routinely ignore posters with paid advertising in their sigs.  You should too.
vuce
Sr. Member
****
Offline Offline

Activity: 476


View Profile
February 02, 2012, 06:00:51 PM
 #10

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
Legendary
*
Offline Offline

Activity: 1302



View Profile
February 02, 2012, 07:04:32 PM
 #11

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.

p2pcoin: a USB/CD/PXE p2pool miner - 1N8ZXx2cuMzqBYSK72X4DAy1UdDbZQNPLf - todo
I routinely ignore posters with paid advertising in their sigs.  You should too.
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!