ETH_OmiseGOToken_audit_report.md

OmiseGO (OMG) Token audit report.

1. Summary

This document is a security audit report performed by danbogd, where OmiseGO (OMG) Token has been reviewed.

2. In scope

Сommit hash .

• OMGToken.sol.

3. Findings

In total, 7 issues were reported including:

• 1 medium severity issues.
• 3 low severity issues.
• 3 minor observation.

No critical security issues were found.

3.1. Allowance Approval

Severity: medium

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.2. 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.3. Known vulnerabilities of ERC-20 token

Severity: low

Description

1. It is possible to double withdrawal attack. More details here.

2. 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 into a function transfer(address _to, ... ) following code:

require( _to != address(this) );

3.4. Owner Privileges

Severity: Low

Description

The contract owner allow himself to pause functions of contract (transfer, transferFrom), mint any value of tokens. The contract is managed manually by the owner which is not good for investors.

3.5. Discrepancy with the ERC20 standard

Severity: minor observation

Description

In OMGToken.sol, according to the ERC20 standard, the variable decimals should be declared as uint8.

Code snippet

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

3.6. It is required to limit the maximum of _releaseTime argument.

Severity: minor observation

Description

For various reasons (accident, vulnerability on the caller smart contract), _releaseTime variable may have a large value which can lead to overflow and that is more critical to blocking tokens for many many years. We can not rely on the correct input data and should check it in this contract.

Code snippet

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

3.7. Consider using latest version of solidity.

Severity: minor observation

Description

The contracts use solidity version 0.4.11. It is suggested to use the latest version and fix all compiler warnings that arise. Compiler version should be fixed to avoid any potential discrepancies in smart contract behavior caused by different versions of compiler.

4. Conclusion

The review did not show any critical issues, some of medium and low severity issues were found.