Global Network vs Hacking
-
Hi Pierre,
Thanks for taking the time to reach out to us. I am interested in hearing more on what you have in mind.
Looking forward to your post in the Tech Dev forum.Thanks
-
Companies have been caught using people’s video cards to mine. This is not a new thing. Always download clients from the original site or a trusted repository.
-
One problem with running all the same clients is that we have a relatively homogeneous network. Such a network being all interconnected is more vulnerable to massive network exploitation.
It is not easy to diversify the network, but it is a concern others have shared before.
One example is to have other, re-written from scratch, clients and servers.
-
[quote name=“robep00” post=“42876” timestamp=“1386744003”]
One problem with running all the same clients is that we have a relatively homogeneous network. Such a network being all interconnected is more vulnerable to massive network exploitation.It is not easy to diversify the network, but it is a concern others have shared before.
One example is to have other, re-written from scratch, clients and servers.
[/quote]Very good point.
-
[quote name=“robep00” post=“42876” timestamp=“1386744003”]
One problem with running all the same clients is that we have a relatively homogeneous network. Such a network being all interconnected is more vulnerable to massive network exploitation.It is not easy to diversify the network, but it is a concern others have shared before.
One example is to have other, re-written from scratch, clients and servers.
[/quote]He’s absolutely right on all points, as tragic as it may sound. The fact that we are homogenized around the QT client is a huge weakness for the network, especially considering that there’s no good reason for this other than a lack of better solution. This it what Mike Hearn set out to change with BitcoinJ, and did a fantastic job of it.
[quote]
Many will argue that it is not possible to develop such a computer worm that would spread across the nodes because of the heterogeneity of the configurations out there.
[/quote]I wouldn’t accept that argument, and I’d fire the first engineer who suggested it. As far as I’m concerned, this is a real and present threat, albeit technically very challenging. Any exploit to the QT client would undoubtedly impact more than 50% of the network, which is Game Over for the coin. If that exploit had an attack vector of the blockchain itself, success would be virtually guaranteed.
-
[quote name=“Kevlar” post=“43177” timestamp=“1386796477”]
[quote author=robep00 link=topic=5810.msg42876#msg42876 date=1386744003]
One problem with running all the same clients is that we have a relatively homogeneous network. Such a network being all interconnected is more vulnerable to massive network exploitation.It is not easy to diversify the network, but it is a concern others have shared before.
One example is to have other, re-written from scratch, clients and servers.
[/quote]He’s absolutely right on all points, as tragic as it may sound. The fact that we are homogenized around the QT client is a huge weakness for the network, especially considering that there’s no good reason for this other than a lack of better solution. This it what Mike Hearn set out to change with BitcoinJ, and did a fantastic job of it.
[quote]
Many will argue that it is not possible to develop such a computer worm that would spread across the nodes because of the heterogeneity of the configurations out there.
[/quote]I wouldn’t accept that argument, and I’d fire the first engineer who suggested it. As far as I’m concerned, this is a real and present threat, albeit technically very challenging. Any exploit to the QT client would undoubtedly impact more than 50% of the network, which is Game Over for the coin. If that exploit had an attack vector of the blockchain itself, success would be virtually guaranteed.
[/quote]I’m gonna build my nodejs thing from FLUX up. That way when it becomes a client it has a completely different development path.
-
I’m not worried because I have Norton Antivirus and the latest service packs for Windows Vista.*
I’ll definitely be monitoring this thread and the one you’re starting over in Tech Dev.
(*To be clear, this is a joke. I was going to post it as is, but realized that my sarcasm doesn’t always translate well in text)
-
[quote name=“zerodrama” post=“43179” timestamp=“1386796899”]
I’m gonna build my nodejs thing from FLUX up. That way when it becomes a client it has a completely different development path.
[/quote]BitcoinJS ala NodeJS is another great example of a re-implementation of the protocol on a different stack… not to mention it’s a whole lot less likely to encounter a really nasty buffer overflow exploit, since you can’t actually smash the stack for fun and profit as easily as you can in C++.
There’s an old hacker joke about shooting yourself in the foot in different languages. It probablly needs to be updated for NodeJS. Let’s see…
In C, you shoot yourself in the foot.
In C++, you accidentally create a dozen clones of yourself and shoot them all in the foot. Providing emergency medical assistance is impossible since you can’t tell which are bitwise copies and which are just pointing at others and saying, “That’s me, over there.â€
In NodeJS, you require “foot”, and schedule it to be shot, but your program mysteriously exits before the bullet hits because shooting is an asynchronous operation and you didn’t provide a callback.NodeJS FTW!
-
[quote name=“Kevlar” post=“43186” timestamp=“1386797530”]
[quote author=zerodrama link=topic=5810.msg43179#msg43179 date=1386796899]
I’m gonna build my nodejs thing from FLUX up. That way when it becomes a client it has a completely different development path.
[/quote]BitcoinJS ala NodeJS is another great example of a re-implementation of the protocol on a different stack… not to mention it’s a whole lot less likely to encounter a really nasty buffer overflow exploit, since you can’t actually smash the stack for fun and profit as easily as you can in C++.
There’s an old hacker joke about shooting yourself in the foot in different languages. It probablly needs to be updated for NodeJS. Let’s see…
In C, you shoot yourself in the foot.
In C++, you accidentally create a dozen clones of yourself and shoot them all in the foot. Providing emergency medical assistance is impossible since you can’t tell which are bitwise copies and which are just pointing at others and saying, “That’s me, over there.â€
In NodeJS, you require “foot”, and schedule it to be shot, but your program mysteriously exits before the bullet hits because shooting is an asynchronous operation and you didn’t provide a callback.NodeJS FTW!
[/quote]I’m gonna need KarmaCoin for this. 24 hours is:
[img]http://cdn.memegenerator.net/instances/400x/21426199.jpg[/img] -
[quote name=“zerodrama” post=“43188” timestamp=“1386797785”]
I’m gonna need KarmaCoin for this.
[/quote]+1 rep in place of KarmaCoin
-
The nodes running BitcoinJS are typically running the lightweight version of the protocol only. But it is a step in the good direction and maybe we should push to have full nodes running on it.
As to exploit JS nodes, it would come down to similar Javascript exploitation targeting the underlying JS engine, which is often written in C++
Sometimes harder, but sometimes the JS is very powerful, assuming you can inject JS code. -
[quote name=“robep00” post=“43231” timestamp=“1386807173”]
The nodes running BitcoinJS are typically running the lightweight version of the protocol only. But it is a step in the good direction and maybe we should push to have full nodes running on it.
[/quote]Both BitcoinJ and NodeJS do not support the getBlock protocol. BitcoinJ also doesn’t support transaction relaying. Other than that, they implement every other aspect of it, including block verification and transaction receiving/generation/sending.
[quote]
As to exploit JS nodes, it would come down to similar Javascript exploitation targeting the underlying JS engine, which is often written in C++
Sometimes harder, but sometimes the JS is very powerful, assuming you can inject JS code.
[/quote]That’s a pretty big assumption that usually starts with the keyword ‘eval’ somewhere in the code. But even then, you’re going to be hard pressed to pull off a stack-smack given how it lays out it’s memory, and the nature of the scheduler. I suppose anything is possible, but in an OS-level exploit race between a program written in C, and one written in Javascript, my money is going to be on the C code every time.
When I was designing Link, the blockchain filesharing protocol, this was something I was hyper aware of when dealing with encoding of strings which are necessarily length-prefixed. Eventually the assumption had to be made that it would be safe to allocate 65,535 bytes for a single string, and the client would need to handle the case where the string size is less than the encoded length by detecting the invalid op-code that would follow and declare the stream corrupt, or it simply ran out of memory due to excessive allocation. Doing this in Javascript made this trivial, where as doing it in C++ would have been error prone and potentially dangerous if bad assumptions were made.
-
[quote]
[quote]
As to exploit JS nodes, it would come down to similar Javascript exploitation targeting the underlying JS engine, which is often written in C++
Sometimes harder, but sometimes the JS is very powerful, assuming you can inject JS code.
[/quote]That’s a pretty big assumption that usually starts with the keyword ‘eval’ somewhere in the code. But even then, you’re going to be hard pressed to pull off a stack-smack given how it lays out it’s memory, and the nature of the scheduler. I suppose anything is possible, but in an OS-level exploit race between a program written in C, and one written in Javascript, my money is going to be on the C code every time.
When I was designing Link, the blockchain filesharing protocol, this was something I was hyper aware of when dealing with encoding of strings which are necessarily length-prefixed. Eventually the assumption had to be made that it would be safe to allocate 65,535 bytes for a single string, and the client would need to handle the case where the string size is less than the encoded length by detecting the invalid op-code that would follow and declare the stream corrupt, or it simply ran out of memory due to excessive allocation. Doing this in Javascript made this trivial, where as doing it in C++ would have been error prone and potentially dangerous if bad assumptions were made.
[/quote]I agree with you, no doubt.
