Author：Knownsec 404 Blockchain Security Research Team
Chinese version：https://paper.seebug.org/663/
1. Brief Introduction
The “Unemitted Transfer Event Issue”, “Unemitted Approval Event Issue”, “Fake Recharge” Vulnerability and “Writing Error of Constructed Function” are uniformly classified as “Ethereum smart contract specification problem” in “Knownsec Ethereum Contract Audit Checklist” which sorted out by the Knownsec 404 Blockchain Security Research Team.
“HaoTian” is an automation platform for monitoring, scanning, analysis and auditing blockchain smart contract. It is independently developed by the Knownsec 404 Blockchain Security Research Team. We use this platform to scan and analyze the smart contract code publicly posted across the web for the above-mentioned “Ethereum Smart Contract Specification”.
2. Vulnerability Details
ERC20 is a standard of the token for the smart contract on the Ethereum blockchain. ERC20 defines a general rule that must be enforced by Ethereum. Exchanges can be integrated to implement token trading if the token issued at Ethereum reaches the ERC20 standard.
ERC20 stipulates that the transfer function must trigger a transfer event and return a Boolean value. It should also throw an error instead of returning the error simply when making a balance judgment. And the approve function must trigger an approve event.
1) Unemitted Transfer Event
function transfer(address _to, uint256 _value) public returns (bool success) { require(balanceOf[msg.sender] >= _value); require(balanceOf[_to] + _value >= balanceOf[_to]); balanceOf[msg.sender] -= _value; balanceOf[_to] += _value; return true; }
The above code did not trigger the Transfer event when the transaction occurred. Failure to comply with the ERC20 standard makes it difficult for developers to monitor contract transactions.
2) Untriggered Approval Event
function approve(address _spender, uint256 _value) public returns (bool success) { allowance[msg.sender][_spender] = _value; return true; }
The above code did not trigger the Approve event when the transaction occurred. Failure to comply with the ERC20 standard makes it difficult for developers to monitor contract transactions.
3) Fake Recharge Vulnerability
function transfer(address _to, uint256 _amount) returns (bool success) { initialize(msg.sender); if (balances[msg.sender] >= _amount && _amount > 0) { initialize(_to); if (balances[_to] + _amount > balances[_to]) { balances[msg.sender] -= _amount; balances[_to] += _amount; Transfer(msg.sender, _to, _amount); return true; } else { return false; } } else { return false; } }
The above code uses the if statement to judge the balance. ERC20 stipulates the contract should throw an error to roll back the transaction, rather than returning the error simply when the balance is insufficient.
In this case, the transaction will still succeed even if there is no real transaction, which may affect the judgment of the trading platform and lead to false recharge.
On July 9, 2018, SlowMist Security Team issued a warning on the vulnerability of fake recharge.
On July 9, 2018, the Knownsec 404 Blockchain Security Research Team followed with the vulnerability and issued a vulnerability warning for the vulnerability. If the case of the constructor name doesn’t match the contract, this function will still be treated as a normal function and can be called by any user.
4) Writing Error of Constructed Function
The compiler required that the constructor name should be consistent with the contract name before the Solidity version 0.4.22 released.
Improper use of constructors is introduced in Solidity 0.4.22. The constructor adds a function definition incorrectly, which causes the constructor can be called by any user and lead to more serious harm, such as the Owner’s permission being stolen.
- Case Error
contract own(){
function Own() {
owner = msg.sender;
}
}
Capitalized constructor name incorrectly causes the constructor name doesn’t match the contract name. In this case, the function is set as a normal public function. Anyone can modify themselves to the owner of the contract by this function. That’s will lead to other serious results.
On June 22, 2018, the MorphToken contract token announced the update of an smart new contract, which fixed the constructor problem on case errors.
On June 22, 2018, the Knownsec 404 Blockchain Security Research Team followed with the emergency and released the “Ethereum smart contract constructor coding error leading to an illegal contract ownership transfer report.”
- Coding Error
function constructor() public { owner = msg.sender; }
Using function as a decorate word for constructor function is incorrectly in the above code. In this case, the function is set as a normal public function. Anyone can modify themselves to the owner of the contract by this function. That’s will lead to other serious consequences.
On July 14, 2018, Link Safe Technology released details in their Official Account about the constructor function’s writing errors.
On July 15, 2018, the Knownsec 404 Blockchain Security Research Team followed with the emergency and released the “Ethereum smart contract constructor writing error leading to an illegal contract ownership transfer report.”
3. The Scope within Vulnerability Impact
The smart contract audit function of the Haotian platform can scan for this type of the problem accurately.
转载请注明：IAMCOOL » "Ethereum Smart Contract Specification Issue" Impact Analysis