A days after the release of its mainnet, the security flaw in EOS increases interest in the currency

The world of cryptocurrencies does not stop growing, and every day new digital currencies that join the market keep appearing. Last year, one of these new crypts took a lot of attention, EOS. So much was the generated interest that came to be declared as the most profitable ICO of 2017. EOS arises from a project that aims to bring the technology of the block chain to all companies in the world.

Desafio-de-EOS-a-futuro.jpg

EOS is the token of Block.one, the company that aims to design free market systems to "make life, freedom and property safe by publishing open source software that everyone can use for free," as they point out on their site. Web.

The CTO of the startup is Daniel Larimer, a genius we can call "serial crypto creator", because, besides being co-founder of EOS, he is also the author of initiatives like Bitshares and its bitUSD currency, the first coin without trust linked to the dollar, and Steem Dollar (SBD), linked to the Steemit.com project.

The EOS incident

A few days ago, EOS was again the epicenter of attention in the crypt ecosystem, when a flaw in the coding of the software that supports the network was discovered.

Members of the 360 Vulcan team, of the important Chinese computer security company Qihoo 360, had detected a problem in the code of the platform, as reported by Jinse, a means of communication of the Asian country this May 29:

"Recently, the 360 Vulcan team discovered a number of high-risk security vulnerabilities on the EOS blockchain platform. It has been verified that arbitrary code can be remotely executed in the EOS node from these faults. The remote attacks would be able to directly control and take over all the nodes that run on EOS. "

Upon being warned about the incident, the EOS development team went to work, being able to isolate and resolve the security breach found by the people of Qihoo 360.

Qihoo 360 saves the day

Yuki Chen, from the 360 ​​Vulcan team and Zhiniang Peng, who belongs to 360 Security Central, both assigned to Qihoo, were the heroes of the day, as they were the ones who detected the anomalies in software security at EOS.

In Qihoo's blog, they describe the details of the find:

We found and successfully exploited a write vulnerability outside the buffer limits in EOS when analyzing a WASM file.

To use this vulnerability, the attacker could load a malicious intelligent contract to the node server, once the node server has analyzed the contract, the malicious load could run on the server and take control of it.

After taking control of the node server, the attacker could package the malicious contract into a new block and further control all the nodes in the EOS network.

WASM is the abbreviation of WebAssembly, a standard that seeks to implement a new format of portable binary code for the execution of Javascript code on the client side. WASM was initially created as a code compilation engine in C and C ++, although it was finally decided to support other languages, such as Rust, being able to create WASM scripts directly.

The WebAssembly standard is mainly characterized by having a highly optimized bytecode and being designed for syntactic processing, which significantly improves the speed of execution compared to conventional Javascript.

The failure identified by Chen and Peng would allow repackaging a harmful intelligent contract in a new block, causing all the nodes in the network to be remotely controlled, which for EOS, and any other network, would be equivalent to a catastrophe.

The security analysts, based on the exploitation of the exploit that they simulated in their laboratories, declared:

"Since the node system is completely controlled, the attacker can do whatever he wants, such as stealing the EOS supernode key, controlling the virtual currency transactions of the EOS network; and seize financial and privacy data contained in the EOS network ... ".

Desafio-de-EOS-a-futuro-2.jpg

The vulnerability, a "write off limit" failure in an EOS data structure was found on May 11, and laboratory tests, where the scope of the vulnerability was explored, compromising an EOS supernode, culminated on April 28. That same day the findings were reported directly to Larimer, who was contacted by Telegram messages and then by email.

By day 29 the fault had been taken care of in Github, although Yuki Chen later informed that the presented solution was not completely complete.

Impact on EOS

This type of news tends to have a negative effect on the projects in the first moments of its disclosure, but the transparency and agility with which it has been handled has left the reputation and the trust in EOS almost intact.

After all, in the ecosystem it is well known that the risks are latent, and that their performance depends, to a large extent, on the experience of the teams that support them.

Of course, EOS experienced a downturn on May 29, managing to recover almost immediately, as shown by the data provided by CoinMarketCap:

Grafica-EOS-310518.gif

The currency currently trades at US $ 12.46, presenting a volume of transactions of more than US $ 1,000 million, which seems to indicate that it has come out rather strengthened as a result of what happened.

The launch of the EOS mainnet is scheduled for June 2, and so far it is not expected to postpone it, although Larimer clearly expressed not giving the green light until the code is fully repaired.

Regarding the problems with the EOS code, the BM founder published related news in the group of developers on May 27. BM said that it will reward those who discover and send errors.

The main faults and / or attacks to be detected include: blocking of node systems through P2P add-ons or RPC interfaces; Smart contracts that fall into infinite loops or that demand a lot of memory (more than 64 MB); use smart contracts to block node systems and perform unauthorized transactions on accounts.

H2
H3
H4
3 columns
2 columns
1 column
Join the conversation now
Logo
Center