OmiseGo (OMG) Security Audit Report

September 21, 2019 Tonton

Here is the report of the OmiseGO Token (OMG) security audit performed by the Callisto Network security department in March 2019.

About Callisto Network and the security department:

Utilizing Callisto Network capabilities, we have established a free-for-all system of smart-contracts auditing, to this end, Callisto Network has founded the Callisto security department and deploys treasury funds to pay security auditors for auditing smart-contracts, to reduce risk/flaw in smart-contracts and improve the adoption of programmable blockchains for the whole crypto industry.

Specificities :

Deployed at :

https://etherscan.io/address/0xd26114cd6EE289AccF82350c8d8487fedB8A0C07#code

Source Code:

https://gist.github.com/yuriy77k/d52b7674ca7cf9b221a819db168fb645

Platform: ETH

Number of lines: 185

Security Audit Report:

1. Summary

OmiseGO (OMG) Token smart contract security audit report performed by Callisto Security Audit Department

2. In scope

OMGToken.sol.

3. Findings

In total, 9 issues were reported including:

6 low severity issues.
3 minor observation.

No critical security issues were found.

3.1. Known vulnerabilities of ERC-20 token

Severity: low

Description

It is possible to double withdrawal attack. More details here.
Lack of transaction handling mechanism issue. WARNING! This is a very common issue and it already caused millions of dollars losses for lots of token users! More details here.

Recommendation

Add the following code to the transfer(_to address, ...) function:

require( _to != address(this) );

3.2. Allowance Approval

Severity: low

Description

Following ERC-20 final description:

“NOTE: To prevent attack vectors like the one described here and discussed here, clients SHOULD make sure to create user interfaces in such a way that they set the allowance first to 0 before setting it to another value for the same spender. THOUGH The contract itself shouldn’t enforce it, to allow backwards compatibility with contracts deployed before.

The implemented approve function:

Do not preserve backwards compatibility since it enforces the allowance values to be set.

Do not throw in case if the following condition is true if (_value != 0 && allowed[msg.sender][_spender] != 0) and return false, users might not notice that the changes didn't occur, and external contract calls to this function will highlight many other issues.

Code snippet

https://gist.github.com/yuriy77k/d52b7674ca7cf9b221a819db168fb645#file-omgtoken-sol-L164

Recommendation

Do not try to mitigate the issue and implement increaseApproval and decreaseApproval functions instead.

3.3. No checking for zero address.

Severity: low

Description

Transfer, transferFrom, mint, TokenTimelock functions do not prevent from sending tokens to address 0x0.

Recommendation

Add zero address checking

solidity
require(to != address(0));

3.4. Poor workaround of Short Address Attack

Severity: low

Description

onlyPayloadSize modifier is workaround to avoid the Short Address Attack. But it doesn’t work properly.

This method failed to execute when it was called from Parity multisignature wallet. The EVM pads call from this multisignature wallet, making the total 96 bytes instead of the expected 68.
If transfer and transferFrom are used by a subcontract function with fewer arguments, the onlyPayloadSize check will fail. It is not possible to adapt the workaround to prevent this issue.

More details here.

Code snippet

https://gist.github.com/yuriy77k/d52b7674ca7cf9b221a819db168fb645#file-omgtoken-sol-L81-L86

Recommendation

Remove this workaround.

3.5. Owner Privileges

Severity: low

https://gist.github.com/yuriy77k/5f84f69befd3f6681f8b5445e24bdb53

https://gist.github.com/yuriy77k/960e5a709d35522a5deb3f35c4ba15b3

https://gist.github.com/yuriy77k/9d28025ce4468a986c8c469a33f34172

Topics:

How to Stake CLO