Skip to content

Instantly share code, notes, and snippets.

@yuriy77k
Forked from gorbunovperm/ETH_AuditchainToken_report.md
Created February 28, 2019 11:59
Show Gist options
  • Save yuriy77k/3148010d397a86f57800b9d98ef83cee to your computer and use it in GitHub Desktop.
Save yuriy77k/3148010d397a86f57800b9d98ef83cee to your computer and use it in GitHub Desktop.
Auditchain Token security audit report

Auditchain Token security audit report

Summary

This is the report from a security audit performed on Auditchain Token by gorbunovperm.

https://auditchain.com/

In scope

  1. Locked.sol
  2. MigrationAgent.sol
  3. Migrations.sol
  4. Token.sol

Findings

In total, 5 issues were reported including:

  • 0 high severity issue.

  • 0 medium severity issues.

  • 5 low severity issues.

  • 0 minor observations.

Security issues

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

require( _to != address(this) );

2. Date related issues

Severity: low

Code snippet

Description

It is about

Issuing yearly 12,500,000 new tokens to governance contract

  1. In this contract, the year is determined by dividing the number of seconds since the beginning of the Unix Epoch by the number of seconds in a leap year. In this case 06.02.2019 11:59pm is 2018 year by returnYear() function. And 07.02.2019 12:00am is 2019 year.

  2. If the contract is deployed on Febrary 6 the owner will recieve 12'500'000 tokens. And the next day he can call mint() and get another 12'500'000 tokens because the contract will consider that the next year has come.

Recommendation

Just save the timestamp of first payment and add to it year value in seconds to figure out if next payment date is come. And then update the date of the last payment.

3. Locked user can transfer allowed tokens

Severity: low

Code snippet

Description

transferFrom function check from and to addresses for lock state but not check msg.sender state.

4. There is a possibility of losing funds during the migration process

Severity: low

Code snippet

Description

In the process of migration, all funds of the sender are burned, but only those that he specified as an argument are sent to new contract. The user may not have actual information of the his balance and accidentally burn part of his funds.

5. Owners privileges

Severity: low

Code snippet

Description

The owners privileges:

  • Ability to be migrated to new contract in the future
  • Ability to lock and unlock ERC20 functions of Token based on user address

Conclusion

There is no serious vulnerabilities were found in this contract.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment