ETH_Humanity_report.md

Humanity Audit Report.

1. Summary

This document is a security audit report performed by RideSolo, where Humanity has been reviewed.

2. In scope

• Faucet.sol github commit hash f58f173b13eda2fa952a5d0fd849942ba5653c7c.
• Governance.sol github commit hash f58f173b13eda2fa952a5d0fd849942ba5653c7c.
• Humanity.sol github commit hash f58f173b13eda2fa952a5d0fd849942ba5653c7c.
• HumanityApplicant.sol github commit hash f58f173b13eda2fa952a5d0fd849942ba5653c7c.
• HumanityGovernance.sol github commit hash f58f173b13eda2fa952a5d0fd849942ba5653c7c.
• HumanityRegistry.sol github commit hash f58f173b13eda2fa952a5d0fd849942ba5653c7c.
• PayableHumanityApplicant.sol github commit hash f58f173b13eda2fa952a5d0fd849942ba5653c7c.
• TwitterHumanityApplicant.sol github commit hash f58f173b13eda2fa952a5d0fd849942ba5653c7c.
• UniversalBasicIncome.sol github commit hash f58f173b13eda2fa952a5d0fd849942ba5653c7c.
• Void.sol github commit hash f58f173b13eda2fa952a5d0fd849942ba5653c7c.
• IGovernance.sol github commit hash f58f173b13eda2fa952a5d0fd849942ba5653c7c.
• IHumanity.sol github commit hash f58f173b13eda2fa952a5d0fd849942ba5653c7c.
• IRegistry.sol github commit hash f58f173b13eda2fa952a5d0fd849942ba5653c7c.
• IUniswapExchange.sol github commit hash f58f173b13eda2fa952a5d0fd849942ba5653c7c.
• MockERC20.sol github commit hash f58f173b13eda2fa952a5d0fd849942ba5653c7c.
• MockHumanityGovernance.sol github commit hash f58f173b13eda2fa952a5d0fd849942ba5653c7c.
• MockHumanityRegistry.sol github commit hash f58f173b13eda2fa952a5d0fd849942ba5653c7c.
• MockTarget.sol github commit hash f58f173b13eda2fa952a5d0fd849942ba5653c7c.
• MockUniswap.sol github commit hash f58f173b13eda2fa952a5d0fd849942ba5653c7c.

3. Findings

3 issues was reported:

• 2 medium severity issues.
• 1 low severity issue.

3.1. Fallback

Severity: medium

Description

The fallback function defined in PayableHumanityApplicant for the contract to receive ether is not safe for users, any ether sent through the fallback function will be taken by the next user or attacker that calls applyWithEtherFor since uniswap function ethToTokenSwapOutput uses only msg.value and not the contract balance to make the external call. (please note that any remaining ether in the contract is sent back to the msg.sender including the eth received through the fallback function).

Code snippet

https://github.com/marbleprotocol/humanity/blob/master/contracts/PayableHumanityApplicant.sol#L28#L41

3.2. Proposal fee deposit

Severity: medium

Description

To apply for a new proposal using applyFor function member of HumanityApplicant contract, a token fee should be tranfered to the contract prior to the function call.

If the required fee to open a proposal is higher than the balance of contract the tokens are taken from the msg.sender wallet using transferFrom (assuming that the user preapproved the tokens transfer). Since the function applyFor uses the balance of the contract first then any one can exploit this logic by checking for direct proposal fees deposit using transfer to the contract and setting a front running attack to pass his proposal without paying the fees.

Code snippet

https://github.com/marbleprotocol/humanity/blob/master/contracts/HumanityApplicant.sol#L29#L37

Recommendation

• transferFrom should be used in both cases, meaning that no condition must be checked to allow the transferFrom.
• Add a function to withdraw any possible token that is deposited to the contract to send it back to the users.

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

Conclusion

The audited contracts are safe.