Skip to content

Instantly share code, notes, and snippets.

@gorbunovperm gorbunovperm/ETH_McAfeeDex_report.md Secret
Last active Oct 23, 2019

Embed
What would you like to do?
McAfeeDex security audit report

McAfeeDex security audit report

1. Summary

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

McAfeeDex is intended to serve as a truly decentralized exchange with multiple UI implementations provided by different parties independently.

2. In scope

Commit hash: 5db8389ce23ce11fb273c9573772287aa75ce43b

  1. contract.sol

3. Findings

In total, 7 issues were reported including:

  • 0 critical severity issue.

  • 0 high severity issue.

  • 1 medium severity issues.

  • 5 low severity issues.

  • 1 owner privileges

  • 0 minor observations.

Security issues

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

require( _to != address(this) );

3.2. Checking input addresses

Severity: low

Code snippet

Description

Incoming addresses should be checked for an empty value(0x0 address) to avoid loss of funds or blocking some functionality.

3.3. Owner Privileges

Severity: owner previliges

Code snippet

Description

The owner can mint any amount of tokens that he wants. Moreover, there is no event call and users will not see this action in the explorer.

3.4. ERC20 Compliance — event missing

Severity: low

Code snippet

Description

According to ERC20 standard when coins are minted(or burned) a Transfer event should be emitted.

3.5. ERC20 Compliance — transfer should throw

Severity: medium

Code snippet

Description

From ERC-20 specification:

The function SHOULD throw if the _from account balance does not have enough tokens to spend.

But in this implementation it just returns false. This can lead to serious consequences. Because checking the return value of this function is rare. For example, external contract may use this token contract as:

ReserveToken.transferFrom(recipient, this, value);
points[recipient] += value;

In this case recipient can get any value of points, but he may not have enough money and the code will succeed.

3.6. Unused variable

Severity: low

Code snippet

Description

  1. accountLevelsAddr is not used anywhere at SwitchDex contract. And functionality of AccountLevels contract is also not used.

  2. feeRebate variable is also not used properly.

3.7. Reentrancy is possible

Severity: low

Code snippet

Description

call method has no gas limit and it is possible to make reentrancy from another contract. In this implementation, no danger was detected in this case, but this poses a certain potential threat.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.