Penetration Test Report (Consensys): foam controller audit report 2018 08 24 master

FOAM Token Controller Audit
1 Summary
1.1 Audit Dashboard
1.2 Audit Goals
1.3 System Overview
1.4 Key Observations/Recommendations
2 Issue Overview
3 Issue Detail
3.1 When checking proof of use, an unconfirmed whitelisted pair is used.
3.2 Whitelisting mechanism allows immediate trading, without proof of use.
3.3 Blacklist feature is untested
3.4 Whitelisting logic should be simplified.
3.5 Token controller contract assumes behavior of other external contracts
3.6 Variable and function naming should be clearer.
3.7 Token holders must trust the token controller owner fully.
4 Tool based analysis
4.1 Mythril
4.2 Solhint
4.3 Surya
4.4 Odyssey
5 Test Coverage Measurement
Appendix 1 - File Hashes
Appendix 2 - Severity
A.2.1 - Minor
A.2.2 - Medium
A.2.3 - Major
A.2.4 - Critical
Appendix 3 - Disclosure
1 Summary
From August 24th, 2018 to August 31st, 2018, ConsenSys Diligence conducted a security audit on the FOAM token controller. The
findings and recommendations are presented here in this report.
1.1 Audit Dashboard
Audit Details
Project Name: FOAM Token Controller
Client Name: Token Foundry
Client Contact: Stuart Hunter
Auditors: Steve Marx, John Mardlin
GitHub : https://github.com/ConsenSys/foam-controller-audit-2018-08-24
Languages: Solidity
Date: 2018-08-24 to 2018-08-31
Number of issues per severity
3 2 2 0
0 0 0 0
1.2 Audit Goals
The focus of the audit was to verify that the smart contract system is secure, resilient and working according to its specifications. The
audit activities can be grouped in the following three categories:
Security: Identifying security related issues within each contract and within the system of contracts.
Sound Architecture: Evaluation of the architecture of this system through the lens of established smart contract best practices and
general software best practices.
Code Correctness and Quality: A full review of the contract source code. The primary areas of focus include:
Correctness
Readability
Sections of code with high complexity
Improving scalability
Quantity and quality of test coverage
1.3 System Overview
Documentation
The following documentation was available to the audit team:
The Foam Token Controller spec explains the goals and basic design of the contract.
Scope
The audit focus was on the FoamTokenController contract. The following graph shows how this contract interacts with the token sale
and FOAM registry contracts. Those contracts were considered out of scope for this audit.
Flow graph
Design
The token controller contract restricts the ability for FOAM token holders to transfer tokens. Specifically, it requires token holders to
complete "proof of use" before freely exchanging tokens.
1.4 Key Observations/Recommendations
The contract design is fairly straightforward and closely follows the behavior described in the spec.
Test coverage is incomplete: Any contract system that is used on the main net should have as a minimum requirement a 100% test
coverage.
Fix all issues: It is recommended to fix all the issues listed in the below chapters, at the very least the ones with severity Critical,
Major and Medium. All issues have also been created as issues in a separate audit repository.
Comment the code: There are a few places in the code where comments explaining the logic would make it easier to understand
the code.
2 Issue Overview
The following table contains all the issues discovered during the audit. The issues are ordered based on their severity. More detailed
description on the levels of severity can be found in Appendix 2. The table also contains the GitHub status of any discovered issue.
Chapter Issue Title Issue Status Severity
When checking proof of
3.1 use, an unconfirmed
whitelisted pair is used.
Whitelisting mechanism
3.2 allows immediate trading,
without proof of use.
Blacklist feature is
3.3
untested
Whitelisting logic should
3.4
be simplified.
Token controller contract
3.5 assumes behavior of other
external contracts
Variable and function
3.6
naming should be clearer.
Token holders must trust
3.7 the token controller
owner fully.
3 Issue Detail
3.1 When checking proof of use, an unconfirmed whitelisted pair is used.
Severity Status Link Remediation Comment
issues/25The issue is currently under review
Description
When a token holder is part of a whitelisted pair, its proof of use is the sum of both members of the pair. The following code is meant to
determine the other member of a whitelisted pair, but it fails to check that the pairing has been confirmed.
contracts/FoamTokenController.sol:L120
address secondAddress = whitelisted[_contributor];
An attacker can exploit this bug by calling setWhitelisted and passing the address of any non-contributor that has already completed
the proof of use requirements. This would instantly allow the attacker to make unrestricted token transfers.
Remediation
Any time a whitelisted pair is considered, it's critical that only confirmed pairings are considered. This can be accomplished after the
above code by checking that whitelisted[secondAddress] == _contributor.
3.2 Whitelisting mechanism allows immediate trading, without proof of use.
Severity Status Link Remediation Comment
issues/24The issue is currently under review
Description
The FOAM token controller places restrictions on how tokens can be transferred during the first year after the platform's launch. The
"whitelisted pairs" mechanism, which is intended to allow token holders to use their tokens from a secondary account, has the side effect
of allowing early token trades.
A token holder can sell some amount of their tokens to a buyer by whitelisting the buyer and making the transfer. The easiest way to
guarantee such a trade would be to make the buyer be a contract that transfers funds on receipt of the tokens.
More sophisticated schemes would involve whitelisting a contract that acts on the seller's behalf. With a little coordination, a new token
W-FOAM ("wrapped FOAM") could be created, where each W-FOAM can be traded for a FOAM token once tokens can be freely traded
(e.g. one year after launch). Token holders could lock up their FOAM in contracts that would grant them W-FOAM instead, and W-
FOAM could be freely traded on existing token exchanges.
Remediation
Removing the "whitelisting pairs" feature would mitigate this vulnerability, but it's important to note that no remediation will fully
disallow this sort of thing. Determined token holders can always make such financial deals outside of this and associated contracts.
3.3 Blacklist feature is untested
Severity Status Link Remediation Comment
issues/27The issue is currently under review
Description
Test coverage reveals that the blacklisting feature is not covered in any existing tests.
Remediation
Tests should be written that exercise the blacklist. Suggested tests: adding and removing addresses from the list, positive and negative
tests for transfers from blacklisted accounts.
3.4 Whitelisting logic should be simplified.
Severity Status Link Remediation Comment
issues/26The issue is currently under review
Description
The whitelisted pair mechanism contains subtle logic that makes it hard to use it correctly. Creating a whitelisted pair is a two-step
process:
1. First, an account that contributed to the token sale must call setWhitelisted(secondAccount).
2. Second, that other account must call confirmWhitelisted(firstAccount).
The whitelisted mapping serves double duty: whitelisted[a] == b by itself does not necessarily mean that a and b form a whitelisted
pair. Instead, it could be that a completed step 1 above, but the pairing was never confirmed.
This subtlety directly led to the major vulnerability https://github.com/ConsenSys/foam-controller-audit-2018-08-24/issues/25.
Remediation
Right now, all consumers of the whitelisted mapping must be careful to check both directions of a pairing to verify that it has been
confirmed. This could be simplified by splitting whitelisted's double duty into two different mappings as follows:
1. proposedPai