A security team based in China where EOS has gained some attention published details today of a remote code execution vulnerability in EOS which has sort of been fixed at the time of writing. The security team, 360, says:
“This vulnerability could be leveraged to achieve remote code execution in the nodeos process, by uploading malicious contracts to the victim node and letting the node parse the malicious contract. In a real attack, the attacker may publishes a malicious contract to the EOS main network.
The malicious contract is first parsed by the EOS super node, then the vulnerability was triggered and the attacker controls the EOS super node which parsed the contract.
The attacker can steal the private key of super nodes or control content of new blocks. What’s more, attackers can pack the malicious contract into a new block and publish it. As a result, all the full nodes in the entire network will be controlled by the attacker.”
The vulnerability concerns asserts, which tend to trip inexperienced developers because asserts work in debug mode, but not in a release build of a live network.
The EOS developers overlooked that fact, with the assert checking a certain parameter, but of course once it is live the assert would no longer work. So thus allowing one to remotely execute malicious code and take over the 21 super nodes and/or the entire network.
Dan Larimer, lead developer of EOS, has acknowledged this vulnerability with new code quickly pushed out. He says:
“If any of these asserts trigger in release it shouldn’t pass, but should throw. Allowing the code to continue running in release is a potential security vulnerability and will likely result in crashes elsewhere.”
The fix is basically renaming the assert so that it becomes a function which works in a live setting, rather than in just a debug mode, however some concerns have been raised that in a 32 bits process there might be an overflow bug which bypasses the check.
It is unclear whether the launch of EOS this weekend will now be delayed or otherwise. Bugs, of course, may sometimes occur, but this sort of bug appears to be far too basic to have made its way to the code and be urgently fixed just days before launch.
It suggests, if we may say, incompetence, because it is unlikely an experienced developer would have allowed this bug to go through.
An auditor worth his/her weight certainly would have not, suggesting this code has not been audited. The bug therefore might not be the last.
Smart contracts, of course, are very hard to code because one missing comma is enough to lose perhaps millions. Coding a Turing complete blockchain that executes such smart contracts is even harder.
But again this sort of assert bug isn’t a new class or something that even experts would have missed, it is rather an oversight or perhaps whoever coded it and/or peer reviewed it (if there was any) might have not even been aware that asserts work fine in debug mode but not in a release build.
So suggesting either incompetence or complete lack of care because this sort of bug should have not required an external team to find.
It is the same sort of bug that was found in Bitcoin Unlimited, but that was a grassroots client with ordinary individuals standing up to code it, thus they readily acknowledged at the time they didn’t quite have significant experience in bitcoin protocol coding.
You’d think Dan Larimer’s years of working in this space would have given him sufficient knowledge to mind the asserts, but then this might have not been coded by him or it may well explain why none of his projects have amounted to much so far.
Copyrights Trustnodes.com
