Can a potential bug in the ethereum VM be used to deploy a trojan on every node in the ethereum network?

Question

This has been on the back of my mind for a long time but has resurfaced with the recent dos attacks.

The constructor of a smart contract is executed by all nodes at the time of contract deployment.

So, if the ethereum virtual machine had a bug that allowed for arbitrary code execution on the host node, it would be possible to deploy a virus/trojan instantly on the whole network by inserting a malicious contract on the blockchain.

It's very likely this has been thought through and discussed elsewhere but I cant find any information on it.

So, is an attack like that possible? What are countermeasures?

Answer 1

Assuming the EVM itself does not specify some behaviour that would enable arbitrary code execution (a bug in the specification), an attack where the EVM could be escaped to enable arbitrary code execution is certainly theoretically possible. There's no reason to believe that blue pill, various attacks against VMWare virtualization solutions, and attacks against the Java VM are isolated and that the EVM is safe.

There are many implementations of the EVM (such as the ones in Parity and geth). This is both a strength (a vulnerability in one piece of software doesn't bring the whole network down) and a weakness (larger overall codebase leads to larger attack surface). Since there are multiple implementations of the EVM floating around, including some that run in other VMs (such as Pyethereum in the Python VM and EthereumJ in the Java VM), and all running on different operating systems, it is unlikely that a single trojan would be able to simultaneously pwn the whole network.

Countermeasures at a node level include physical isolation such as running on dedicated hardware and logical isolation (using virtualization). One could also air gap a node and bring blockchain fragments over using a read-only medium. Obviously, not useful for applications that require constant connectivity to the network.

Also, depending on the threat model, other precautions can be taken. If one is worried about theft of private keys, the node running the EVM does not need to store the keys: transaction signing can be done on a separate air gapped machined. If the worry is the hijacking of resources (such as joining a botnet), the node can be made less attractive by not including discrete graphics cards (which might be used for mining), using less-powerful hardware, and using an external firewall to make it harder for the node to do useful work for the botnet owner. Data modification such as seen in ransomware can be mitigated through the use of rolling backups.

Answer 2

Sort answer: It is not possible.

To put a trojan horse in every node connected to Ethereum you need to exploit a buffer overflow vulnerability. (https://en.wikipedia.org/wiki/Buffer_overflow) This is only possible in C/C++ languages, provided that the programmers do not properly audit their code. geth is written in golang and Go protects against buffer overflow at language level. Parity is written in Rust, which also protects against buffer overflows.

It would be only possible to deploy a trojan on a node that runs Ethereum C++, but a buffer overflow vulnerability must exist. Not all C code has buffer overflows, it dependes on the developer who writes it, for example, qmail has been never hacked, despite many contests.

It could be , however that golang and Rust have a vulnerability in protecting against buffer overflows, and somehow, under some conditions, golang or Rust fail on this, and then , probably, you could exploit this. But the probability of this event is almost nil.

Also, why would you want to hack an Ethereum node ? Nobody nowadays have their private keys on the net. All transactions are submitted in raw format , already signed by cold wallet or some computer that only connects to the network when it needs to send something.