codymanix (OP)
Full Member
![*](https://bitcointalk.org/Themes/custom1/images/star.gif) ![*](https://bitcointalk.org/Themes/custom1/images/star.gif)
Offline
Activity: 203
Merit: 121
Gir: I'm gonna sing the Doom Song now..
|
![](https://bitcointalk.org/Themes/custom1/images/post/exclamation.gif) |
October 10, 2013, 03:41:25 PM |
|
Could it happen that an attacker injects malicious code into the satoshi client? For example that all money of the user's wallet is transferred to the attacker (If the wallet is encrypted, as soon as user enters the password). Then the infected client would have to made available for download on official site bitcoin.org. Even if the problem is noticed within a few hours, the attacker could have gained lots of money, so such an attack would be very attractive for a criminal hacker. Additional to the damage done to the users, this could do much damage to bitcoin itself, if not even destroying it.
I can think of a lot possible access points for the attacker:
- An attacker could break directly into the source control where the source code is stored and unnoticed injects his code which is then automatically include in the next version. But since bitcoin is open source, the attacker should hide its code in a file where people rarely look into or file which at first glance does not look important but are indeed source files
- An attacker could hack a computer of one of the bitcoin client developers (Either through direct physical access or through some trojan)
- The attacker could threaten one of the bitcoin developers and such force his to do what he wants
- An attacker could break into the website bitcoin.org and place his malicious client for download, or redirect bitcoin.org via some dns attack to his own (same looking) website With this attack, the checksum of the client won't be ok but how many users will (or even know how to) check that?
This are my greatest fears. Please tell me that these scenarios are almost impossible to happen. So the question is, could this be possible?
|
|
|
|
gmaxwell
Moderator
Legendary
Offline
Activity: 4242
Merit: 8654
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
October 10, 2013, 04:32:22 PM |
|
- An attacker could break directly into the source control where the source code is stored and unnoticed injects his code which is then automatically include in the next version. But since bitcoin is open source, the attacker should hide its code in a file where people rarely look into or file which at first glance does not look important but are indeed source files
This won't work. Everyone looks at diffs. Making the change in something that changes all the time would be a better strategy. In GIT it is not possible to make invisible changes either, and rewriting the history will make all git clients refuse to pull until forced. - An attacker could hack a computer of one of the bitcoin client developers (Either through direct physical access or through some trojan) - The attacker could threaten one of the bitcoin developers and such force his to do what he wants
If the system is vulnerable to this, then you can remove the third party "attacker" from the equation: One of the developers could just do this if it were possible. Hopefully, enough people are auditing all changes that this wouldn't be possible. - An attacker could break into the website bitcoin.org and place his malicious client for download, or redirect bitcoin.org via some dns attack to his own (same looking) website With this attack, the checksum of the client won't be ok but how many users will (or even know how to) check that?
About 1% check. But users update very slowly and we intentionally do not have a forced auto-update. And there are people running automated signature tests who would quickly notice a problem. This are my greatest fears. Please tell me that these scenarios are almost impossible to happen. So the question is, could this be possible?
Certainly it would be possible, few things are not possible. It's less clear that there would be a large amount of funds taken this way...
|
|
|
|
jl2012
Legendary
Offline
Activity: 1792
Merit: 1111
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
October 10, 2013, 05:12:01 PM |
|
What if the alert system key(s) is compromised? Any mechanism to revoke the old key and migrate to a new one?
|
Donation address: 374iXxS4BuqFHsEwwxUuH3nvJ69Y7Hqur3 (Bitcoin ONLY) LRDGENPLYrcTRssGoZrsCT1hngaH3BVkM4 (LTC) PGP: D3CC 1772 8600 5BB8 FF67 3294 C524 2A1A B393 6517
|
|
|
gmaxwell
Moderator
Legendary
Offline
Activity: 4242
Merit: 8654
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
October 10, 2013, 06:00:37 PM |
|
What if the alert system key(s) is compromised? Any mechanism to revoke the old key and migrate to a new one?
A maximum sequence alert can be sent which will override all other alerts and will display a static prefabricated message: "URGENT: Alert key compromised, upgrade required"
|
|
|
|
michagogo
Member
![*](https://bitcointalk.org/Themes/custom1/images/star.gif)
Offline
Activity: 80
Merit: 10
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
October 11, 2013, 11:52:26 AM |
|
What if the alert system key(s) is compromised? Any mechanism to revoke the old key and migrate to a new one?
A maximum sequence alert can be sent which will override all other alerts and will display a static prefabricated message: "URGENT: Alert key compromised, upgrade required" Maybe I'm missing something, but wouldn't the attacker in this case simply set the sequence number and priority to the maximum?
|
|
|
|
jl2012
Legendary
Offline
Activity: 1792
Merit: 1111
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
October 11, 2013, 01:08:44 PM |
|
What if the alert system key(s) is compromised? Any mechanism to revoke the old key and migrate to a new one?
A maximum sequence alert can be sent which will override all other alerts and will display a static prefabricated message: "URGENT: Alert key compromised, upgrade required" Maybe I'm missing something, but wouldn't the attacker in this case simply set the sequence number and priority to the maximum? I think sending a maximum sequence alert is equal to sending the "URGENT: Alert key compromised, upgrade required". It's equivalent to revoking the key.
|
Donation address: 374iXxS4BuqFHsEwwxUuH3nvJ69Y7Hqur3 (Bitcoin ONLY) LRDGENPLYrcTRssGoZrsCT1hngaH3BVkM4 (LTC) PGP: D3CC 1772 8600 5BB8 FF67 3294 C524 2A1A B393 6517
|
|
|
codymanix (OP)
Full Member
![*](https://bitcointalk.org/Themes/custom1/images/star.gif) ![*](https://bitcointalk.org/Themes/custom1/images/star.gif)
Offline
Activity: 203
Merit: 121
Gir: I'm gonna sing the Doom Song now..
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
October 11, 2013, 03:24:02 PM |
|
- An attacker could hack a computer of one of the bitcoin client developers (Either through direct physical access or through some trojan) - The attacker could threaten one of the bitcoin developers and such force his to do what he wants
If the system is vulnerable to this, then you can remove the third party "attacker" from the equation: One of the developers could just do this if it were possible. Hopefully, enough people are auditing all changes that this wouldn't be possible. If someone puts a manipulated client on bitcoin.org with his own source, that is without checking in anything? - An attacker could break into the website bitcoin.org and place his malicious client for download, or redirect bitcoin.org via some dns attack to his own (same looking) website With this attack, the checksum of the client won't be ok but how many users will (or even know how to) check that?
About 1% check. But users update very slowly and we intentionally do not have a forced auto-update. And there are people running automated signature tests who would quickly notice a problem. If done from a computer of a bitcoin developer, the executable could also be signed valid, so no one will notice the difference. It would be great some kind of multi key signing would be used, that is, multiple persons have to sign with their private keys to make the signature valid.
|
|
|
|
piotr_n
Legendary
Offline
Activity: 2053
Merit: 1356
aka tonikt
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
October 11, 2013, 04:07:00 PM Last edit: October 11, 2013, 04:29:38 PM by piotr_n |
|
This is exactly the reason why people shall be using cold wallets, to store their major BTC holdings.
It doesn't even need to be a bug or a backdoor in the actual bitcoin client - more likely it would be a virus/trojan/malware or just a bug/backdoor in the OS.
Keep your bitcoins offline and do not move any signed transaction from your cold storage without double checking whether it does exactly what you intended. Just use your imagination combined with the already available technology and the worst case scenario would not be a threat to you.
|
Check out gocoin - my original project of full bitcoin node & cold wallet written in Go.PGP fingerprint: AB9E A551 E262 A87A 13BB 9059 1BE7 B545 CDF3 FD0E
|
|
|
gmaxwell
Moderator
Legendary
Offline
Activity: 4242
Merit: 8654
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
October 11, 2013, 05:00:27 PM |
|
I think sending a maximum sequence alert is equal to sending the "URGENT: Alert key compromised, upgrade required". It's equivalent to revoking the key.
Correct. It would be great some kind of multi key signing would be used, that is, multiple persons have to sign with their private keys to make the signature valid.
We have that, thats what gitian is for.
|
|
|
|
Cryddit
Legendary
Offline
Activity: 924
Merit: 1132
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
October 12, 2013, 04:33:37 AM |
|
Actually, this could be done on a far simpler basis attacking individual users via a MITM attack. Here is your scenario:
1. Your ISP hires a dishonest worker. Let's call him "Mallory". (I say ISP, but this could happen upstream from the ISP, too, on the backbone).
2. Mallory prepares a hacked bitcoin client by downloading code anonymously from github, then adding his own special sauce and compiling.
3. Late at night, Mallory reroutes two cables in the server room, to put http requests through "Machine X" which is not on the ISP's logging system.
4. "Machine X" has URL rewriting code that watches for people trying to download the compiled bitcoin client, and redirects those requests to a server where Mallory's fiddled version is served.
5. A hundred or so users (or a few thousand depending on how big the ISP is, or maybe half of all the downloaders for a few weeks if Mallory is at a backbone site) send an HTTP request for the client, and get Mallory's version instead.
6. These phony clients have most of a year to log your wallet-decryption passwords while acting as legit clients, then on June 14 they send three-quarters of your coin to Mallory's client. Meanwhile they continue to display the amount you had, so that you won't notice until you try to spend down to less than 75% of your previous balance, unless you go to blockchain.org and look up individual keys.
7. Mallory turns around the coin to buy untraceable goods, leaving it in the hands of honest merchants.
8. It will be at least two or three months before most of the victims notice.
|
|
|
|
jl2012
Legendary
Offline
Activity: 1792
Merit: 1111
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
October 12, 2013, 05:22:11 AM |
|
This won't work because people use https, not http Actually, this could be done on a far simpler basis attacking individual users via a MITM attack. Here is your scenario:
1. Your ISP hires a dishonest worker. Let's call him "Mallory". (I say ISP, but this could happen upstream from the ISP, too, on the backbone).
2. Mallory prepares a hacked bitcoin client by downloading code anonymously from github, then adding his own special sauce and compiling.
3. Late at night, Mallory reroutes two cables in the server room, to put http requests through "Machine X" which is not on the ISP's logging system.
4. "Machine X" has URL rewriting code that watches for people trying to download the compiled bitcoin client, and redirects those requests to a server where Mallory's fiddled version is served.
5. A hundred or so users (or a few thousand depending on how big the ISP is, or maybe half of all the downloaders for a few weeks if Mallory is at a backbone site) send an HTTP request for the client, and get Mallory's version instead.
6. These phony clients have most of a year to log your wallet-decryption passwords while acting as legit clients, then on June 14 they send three-quarters of your coin to Mallory's client. Meanwhile they continue to display the amount you had, so that you won't notice until you try to spend down to less than 75% of your previous balance, unless you go to blockchain.org and look up individual keys.
7. Mallory turns around the coin to buy untraceable goods, leaving it in the hands of honest merchants.
8. It will be at least two or three months before most of the victims notice.
|
Donation address: 374iXxS4BuqFHsEwwxUuH3nvJ69Y7Hqur3 (Bitcoin ONLY) LRDGENPLYrcTRssGoZrsCT1hngaH3BVkM4 (LTC) PGP: D3CC 1772 8600 5BB8 FF67 3294 C524 2A1A B393 6517
|
|
|
Shallow
Sr. Member
![*](https://bitcointalk.org/Themes/custom1/images/star.gif) ![*](https://bitcointalk.org/Themes/custom1/images/star.gif) ![*](https://bitcointalk.org/Themes/custom1/images/star.gif)
Offline
Activity: 938
Merit: 255
SmartFi - EARN, LEND & TRADE
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
October 12, 2013, 06:02:41 AM |
|
This is very unlikely i would hope. Pretty sure the source code is thoroughly checked by many paranoid people upon an update.
|
|
|
|
michagogo
Member
![*](https://bitcointalk.org/Themes/custom1/images/star.gif)
Offline
Activity: 80
Merit: 10
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
October 12, 2013, 07:45:15 PM |
|
I think sending a maximum sequence alert is equal to sending the "URGENT: Alert key compromised, upgrade required". It's equivalent to revoking the key.
Correct. Sorry if I'm being slow... Are you saying that the "URGENT: Alert key compromised, upgrade required" message is hard-coded into the client to display when it sees a maximum-sequence alert?
|
|
|
|
jl2012
Legendary
Offline
Activity: 1792
Merit: 1111
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
October 12, 2013, 08:00:47 PM |
|
I think sending a maximum sequence alert is equal to sending the "URGENT: Alert key compromised, upgrade required". It's equivalent to revoking the key.
Correct. Sorry if I'm being slow... Are you saying that the "URGENT: Alert key compromised, upgrade required" message is hard-coded into the client to display when it sees a maximum-sequence alert? Yes.
|
Donation address: 374iXxS4BuqFHsEwwxUuH3nvJ69Y7Hqur3 (Bitcoin ONLY) LRDGENPLYrcTRssGoZrsCT1hngaH3BVkM4 (LTC) PGP: D3CC 1772 8600 5BB8 FF67 3294 C524 2A1A B393 6517
|
|
|
cowandtea
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
October 13, 2013, 02:29:00 PM |
|
Unlikely, it would happen long before when it is still vulnerable. Right now seems like it has all patched up.
|
|
|
|
juhakall
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
October 13, 2013, 02:41:50 PM |
|
This won't work because people use https, not http Actually, this could be done on a far simpler basis attacking individual users via a MITM attack. Here is your scenario:
1. Your ISP hires a dishonest worker. Let's call him "Mallory". (I say ISP, but this could happen upstream from the ISP, too, on the backbone).
2. Mallory prepares a hacked bitcoin client by downloading code anonymously from github, then adding his own special sauce and compiling.
3. Late at night, Mallory reroutes two cables in the server room, to put http requests through "Machine X" which is not on the ISP's logging system.
4. "Machine X" has URL rewriting code that watches for people trying to download the compiled bitcoin client, and redirects those requests to a server where Mallory's fiddled version is served.
5. A hundred or so users (or a few thousand depending on how big the ISP is, or maybe half of all the downloaders for a few weeks if Mallory is at a backbone site) send an HTTP request for the client, and get Mallory's version instead.
6. These phony clients have most of a year to log your wallet-decryption passwords while acting as legit clients, then on June 14 they send three-quarters of your coin to Mallory's client. Meanwhile they continue to display the amount you had, so that you won't notice until you try to spend down to less than 75% of your previous balance, unless you go to blockchain.org and look up individual keys.
7. Mallory turns around the coin to buy untraceable goods, leaving it in the hands of honest merchants.
8. It will be at least two or three months before most of the victims notice.
http://kent.dl.sourceforge.net/project/bitcoin/Bitcoin/bitcoin-0.8.5/bitcoin-0.8.5-win32-setup.exeThis is what I'm offered to download when clicking through bitcoin.org. No HTTPS there.
|
|
|
|
jl2012
Legendary
Offline
Activity: 1792
Merit: 1111
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
October 13, 2013, 02:48:43 PM |
|
This won't work because people use https, not http Actually, this could be done on a far simpler basis attacking individual users via a MITM attack. Here is your scenario:
1. Your ISP hires a dishonest worker. Let's call him "Mallory". (I say ISP, but this could happen upstream from the ISP, too, on the backbone).
2. Mallory prepares a hacked bitcoin client by downloading code anonymously from github, then adding his own special sauce and compiling.
3. Late at night, Mallory reroutes two cables in the server room, to put http requests through "Machine X" which is not on the ISP's logging system.
4. "Machine X" has URL rewriting code that watches for people trying to download the compiled bitcoin client, and redirects those requests to a server where Mallory's fiddled version is served.
5. A hundred or so users (or a few thousand depending on how big the ISP is, or maybe half of all the downloaders for a few weeks if Mallory is at a backbone site) send an HTTP request for the client, and get Mallory's version instead.
6. These phony clients have most of a year to log your wallet-decryption passwords while acting as legit clients, then on June 14 they send three-quarters of your coin to Mallory's client. Meanwhile they continue to display the amount you had, so that you won't notice until you try to spend down to less than 75% of your previous balance, unless you go to blockchain.org and look up individual keys.
7. Mallory turns around the coin to buy untraceable goods, leaving it in the hands of honest merchants.
8. It will be at least two or three months before most of the victims notice.
http://kent.dl.sourceforge.net/project/bitcoin/Bitcoin/bitcoin-0.8.5/bitcoin-0.8.5-win32-setup.exeThis is what I'm offered to download when clicking through bitcoin.org. No HTTPS there. Oh, that's really bad. Even bitcoin.org is not https enabled. (but at least the package is signed by bitcoin foundation)
|
Donation address: 374iXxS4BuqFHsEwwxUuH3nvJ69Y7Hqur3 (Bitcoin ONLY) LRDGENPLYrcTRssGoZrsCT1hngaH3BVkM4 (LTC) PGP: D3CC 1772 8600 5BB8 FF67 3294 C524 2A1A B393 6517
|
|
|
Cryddit
Legendary
Offline
Activity: 924
Merit: 1132
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
October 13, 2013, 06:17:22 PM |
|
Well.... yeah, it really is that bad.
Maybe we should ask sourceforge/github/ any others we can influence, never to serve executable (or, really, even source) using http rather than https?
https isn't all that secure, for that matter, but it is better than nothing.
Anybody got a better idea?
|
|
|
|
gmaxwell
Moderator
Legendary
Offline
Activity: 4242
Merit: 8654
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
October 13, 2013, 07:13:57 PM |
|
https isn't all that secure, for that matter, but it is better than nothing. Anybody got a better idea?
HTTPS is not that secure. Fortunately we have _two_ different signature systems which are better than HTTPS which are in use. GPG signatures by Gavin's signing key, and gitian signatures.
|
|
|
|
jl2012
Legendary
Offline
Activity: 1792
Merit: 1111
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
October 13, 2013, 07:35:52 PM |
|
https isn't all that secure, for that matter, but it is better than nothing. Anybody got a better idea?
HTTPS is not that secure. Fortunately we have _two_ different signature systems which are better than HTTPS which are in use. GPG signatures by Gavin's signing key, and gitian signatures. I opened a discussion here: https://bitcointalk.org/index.php?topic=310161.0So what is your comments for the use of PKI in payment protocol? For Gavin's key, how do I verify if I do not know him and do not have a web-of-trust?
|
Donation address: 374iXxS4BuqFHsEwwxUuH3nvJ69Y7Hqur3 (Bitcoin ONLY) LRDGENPLYrcTRssGoZrsCT1hngaH3BVkM4 (LTC) PGP: D3CC 1772 8600 5BB8 FF67 3294 C524 2A1A B393 6517
|
|
|
|