Ethereum users beware: yesterday, Marcin Noga, a security researcher at Cisco’s Talos security team, disclosed several serious vulnerabilities in several popular implementations of the Ethereum Client, several of which are serious enough to disrupt the entire Ethereum network.
A Multitude of JSON-RPC Problems
The CVEs in question deal mainly with the JSON-RPC implementations of each Client. Parity, seems to have the most vulnerable configuration of the three.
Parity’s whitelist for CORS, a standard that allows non-native resources and third party cross-domain requests, is set to a wildcard, allowing any third party program to access data via its JSON-RPC interface.
An attacker can use a simple script on a malicious website to steal a wealth of information about the target’s Parity client and the accounts associated with it, and potentially manipulate that information. The Parity client ships with the wildcard in this whitelist by default, putting every user at risk until they either change it themselves or Parity patches this default out.
CPP-Ethereum also has interface problems, including a bug that allows attackers to hijack certain client admin functionality (like mining and account management) without authenticating. This is due to an off-spec bind location that allows outside parties to execute arbitrary commands should they gain access.
In addition, an attacker can send altered JSON packages that crash or lock up the node. Only the Go implementation seems to have a sane JSON-RPC interface at the moment.
Constantinople’s EVM Is Easy to Crash
The new build of CPP-Ethereum, based on the Constantinople fork of the project, has several new commands and functions. One of these new functions lets a user create a new contract in an automated manner, but in doing so lets a user assign arbitrary memory to that new contract by misusing a few of its parameters.
In effect, an attacker could crash most of the Ethereum network by sending an opcode that assigns more memory than the majority of nodes can handle, or map out arbitrary memory in a contract/victim’s EVM by repeatedly assigning known sections of memory to the new contract and reading them.
Patches and Mitigations
The good news is that the majority of these CVEs were found weeks or months ago by Noga, giving each implementation’s developers time to patch out the vulnerabilities disclosed therein. Whether each team has taken steps to do so is another matter, but the responsible disclosure should hopefully be enough, especially given Parity’s spotty security track record in the past.
Now that they’re out in the open, we’ll either see lots of exploitation or timely patches from the devs of each project.
Do you use any of these wallets? What’s your take on the latest findings? Let us know in the comments.
Images courtesy Pixabay