Mainnet attacked swiftly supplied

ETHNews reached out to Go Ethereum team leader Péter Szilágyi, who provided an inside look at what took place during an attack on the Ethereum Virtual Machine (EVM).

According to Szilágyi, the EVM is built so that every opcode comes with an associated cost. Some are fixed costs, and some are fixed but coupled with dynamic fees based on the data they manipulate; one example of this being SHA3. Potential vulnerabilities arise when an EVM does non-constant-time work or memory allocation for a fixed opcode.

So what happened?

"The attacker found an opcode combo around CREATE and JUMPDEST that entailed a fixed cost to invoke, but caused Geth to scan the entire contract for certain markers and store them into a map. With large enough attack contracts, this caused high memory usage and a significant processing overhead from Go's hashmap implementation," said Szilágyi.

He added, "As far as I know, it did make other implementations sweat too, prompting the other clients' teams to take a closer look and maybe add some polishes here and there.

“At current gas limits, the attack didn't pose an immediate threat to the network as an 8GB machine with a decent CPU crunched through the transactions with a bit of a delay, but it was an annoying nuisance nonetheless for lower end machines and miners who got stalled when processing these monster calls."

Szilágyi believes the reason the attack was detected was due to the community's vigilance. A reddit post indicated that a past attacker address was making seemingly pointless transactions, and Szilágyi noticed that the addresses were the same as other attacks previously perpetrated against the mainnet.

To fix the problem, Szilágyi said, "We’ve swapped out our internal data structure used to store the JUMP destinations in a contract from Go's hash map to a simple bitmap. This reduces memory requirements to 1/8th of the contract's length [base 64] and reduced processing overhead by replacing hash-based lookups with direct array access."

The team didn't take long to debate, determine, and execute a solution in around three hours. Something caused the attacker to pause after a few heavy transactions, but Szilágyi thinks that when developers opened the pull request fixing the issue,  the attacker figured it was "now or never," and "attempted to cause as much damage as possible" since it would take time to release the fix.

"Luckily," Szilágyi reveals, "since Devcon 2, we have streamlined all our build processes so doing a new release entails creating a single Git tag and everything else is automatically picked up and rolled out. This way we could respond to the attack immediately by doing the release already pending on GitHub."

Szilágyi said that without the amazing Ethereum community's invaluable help in noticing the attack before it even started, a solution wouldn't have been developed as fast.

 "These are the moments when as a developer you can feel that there are people who actually care for your work, not just build on top and forget."

Jeremy Nation is a writer living in Los Angeles with interests in technology, human rights, and cuisine. He is a full time staff writer for ETHNews and holds value in Ether.
ETHNews is commited to its Editorial Policy
Like what you read? Follow us on to receive the latest on Ethereum Go, Péter Szilágyi or other Ethereum ecosystem news.
   

Subscribe to our Newsletter

* indicates required
Email Address *
First Name
Last Name
Country
News Categories of Interest