Editor's note: This article is from Digital Comet Technology and is published with permission.
In response to the EOS vulnerability issue some time ago, this article will review the overall details. I hope everyone will raise security awareness, but don't panic too much, and take a correct view of security issues.
1. Event overview
In the early hours of June 22, the EOS official community released a message saying that an EOS vulnerability was discovered, and the tokens that users pledged to vote could not be redeemed until the vulnerability was fixed. Then we verified the vulnerability according to the relevant information and confirmed that the vulnerability does exist, and before the vulnerability was fixed, through a carefully constructed attack, specific user assets were mortgaged indefinitely and could not be redeemed.
We know that EOS adopts the DPoS consensus mechanism, which maintains the EOS network by electing 21 super nodes through community voting, and provides computing power, bandwidth and storage support for the EOS network. Users do not need to consume EOS to vote, but EOS will be locked. Users can apply for redemption of mortgaged EOS at any time, and the credit will arrive 72 hours after the application for redemption. At the same time, votes will be deducted.
This vulnerability occurred during the redemption process of EOS. If other users mortgage EOS to the redeeming user, the system will first re-mortgage the EOS in the redemption process of the redeeming user. We already know that it takes 72 hours for the EOS that is applied for redemption to arrive in the account. As mentioned above, the carefully constructed attack theoretically makes the assets of designated users be mortgaged indefinitely, causing serious harm to users.
2. Vulnerability attack process
1. Assume that the attacked user owns 0.0005 EOS and is in the process of redemption.
2. At this time, the attacker mortgages 0.0001 EOS to the redeeming user.
3. After the transaction takes effect, we see that the balance of the attacker has not changed, and the 0.0001 EOS that the redeeming user is on the way to redeem is forced to mortgage again.
3. Analysis of Vulnerability Principles
The attack commands in the attack flowchart are as follows:
cleos --wallet-url http://localhost:6666 --url http://mainnet.genereos.io:80 system delegatebw (attacker) (victim) "0.0001 EOS" "0.0000 EOS" --transfer
Since the attacker added the --transfer parameter when calling the command, the changbw function will be called when the mortgage function delegatebw is called, and transfer is true at this time
When the transfer variable is true, the from address becomes the address of the attacked object,
Next, the data of the attacked object is modified, and EOS is mortgaged again.
4. Vulnerability mitigation plan
Based on the above analysis, this paper recommends modifying some business logic to alleviate and repair the mortgage vulnerability.
1. Regardless of whether the transfer parameter is true or not, it should be directly deducted from the balance of the mortgage initiator (the redemption process is not subject to this restriction);
2. Sort out the relevant business logic and check whether there are similar loopholes.
V. Vulnerability Analysis Summary
Through the above analysis, carefully constructed attacks make specific user assets mortgaged indefinitely and cannot be redeemed. Patching code with mitigation measures can effectively mitigate and fix this vulnerability.
