Penetration Test Report (TrailOfBits): CREAMSummary

CREAM
Summary Report
January 2 8th, 2 021
Prepared For:
Leo Cheng | C REAM Finance
leo@machix.com
Jeremy Yang | C REAM Finance
jeremy@cream.finance
Eason Wu | C REAM Finance
eason@cream.finance
Prepared By:
Michael Colburn | T rail of Bits
michael.colburn@trailofbits.com
Maximilian Krüger | T rail of Bits
max.kruger@trailofbits.com
Review Summary
Code Maturity Evaluation
Project Dashboard
Appendix A. Code Maturity Classifications
Appendix B. Token Integration Checklist
General Security Considerations
ERC Conformity
Contract Composition
Owner privileges
Token Scarcity
Appendix C. Handling Key Material
Review Summary
From January 25 to January 27, 2021, Trail of Bits performed an assessment of the CREAM
smart contracts with two engineers, working from commit 2 e83fc3 from
CreamFi/compound-protocol as well as commit 8 c44071 from the c ream-v2 branch of the
same repository. CREAM is a fork of the Compound lending protocol with additional
features. Due to the short length of the engagement, we focused our review on changes
introduced by the fork.
Throughout this assessment, we sought to answer various questions about the security of
CREAM. We focused on flaws that would allow an attacker to:
● Manipulate asset prices returned by the price oracles.
● Subvert the imposed caps on borrowing or supplying.
● Bypass access controls to modify contract state.
This review resulted in three findings ranging from medium to informational in severity.
The medium-severity issue describes how the price oracle acts as a single point of failure
for the system. The remaining informational issues highlight the lack of documentation
accompanying the system as well as the use of A BIEncoderV2 in some of the contracts.
Additionally, we reported several code quality suggestions.
On the following page, we review the maturity of the codebase and the likelihood of future
issues. In each area of control, we rate the maturity from strong to weak, or missing, and
give a brief explanation of our reasoning. A ppendix B provides a list of recommendations
to consult when considering adding support for new assets. A ppendix C includes guidance
on handling sensitive key material.
Additionally, CREAM Finance should consider these steps to improve their security
maturity:
● Improve the documentation of the system, especially the differences from the
original Compound protocol.
● Integrate f uzzing or s ymbolic execution to test the correctness of contract
functionality.
● Follow best practices for privileged accounts, e.g., use a multisig wallet for the
owner, and consider the use of an HSM (see o ur HSM recommendations) .
● Follow best practices when u sing price oracles.
● Conduct further in-depth review focused on the off-chain price oracle infrastructure.
Code Maturity Evaluation
Category Name Description
Access Controls Satisfactory. Adequate access controls were in place for all
privileged operations.
Arithmetic Satisfactory. All relevant arithmetic was checked for errors using
the custom CarefulMath library.
Assembly Use Satisfactory. The usage of assembly was minimal and limited to
areas where it was necessary.
Centralization Weak. An oracle operated by CREAM finance was used as a fallback
for certain assets. Additionally, the Comptroller admin address had
the authority to replace the oracle at any time.
Contract Satisfactory. The system used the delegatecall proxy pattern for
Upgradeability upgradeability and no issues were identified.
Function Satisfactory. Functions were organized and scoped appropriately.
Composition Code that was added or modified appeared to be consistent with the
existing code style.
Front-Running Satisfactory. We did not identify any issues related to front-running.
Monitoring Satisfactory. All functions that made important state modifications
emitted events.
Specification Missing. Official documentation was very minimal. As the project
was a fork of Compound, much of the relevant documentation
already existed. However, the specific differences from Compound
were not documented clearly.
Testing & Satisfactory. The repository included tests for a variety of scenarios.
Verification
Appendix A. Code Maturity Classifications
Code Maturity Classes
Category Name Description
Access Controls Related to the authentication and authorization of components.
Arithmetic Related to the proper use of mathematical operations and
semantics.
Assembly Use Related to the use of inline assembly.
Centralization Related to the existence of a single point of failure.
Upgradeability Related to contract upgradeability.
Function Related to separation of the logic into functions with clear purpose.
Composition
Front-Running Related to resilience against front-running.
Key Management Related to the existence of proper procedures for key generation,
distribution, and access.
Monitoring Related to use of events and monitoring procedures.
Specification Related to the expected codebase documentation.
Testing & Related to the use of testing techniques (unit tests, fuzzing, symbolic
Verification execution, etc.).
Rating Criteria
Rating Description
Strong The component was reviewed and no concerns were found.
Satisfactory The component had only minor issues.
Moderate The component had some issues.
Weak The component led to multiple issues; more issues might be present.
Missing The component was missing.
Not Applicable The component is not applicable.
Not Considered The component was not reviewed.
Further The component requires further investigation.
Investigation
Required
Appendix B. Token Integration Checklist
The following checklist provides recommendations when interacting with arbitrary tokens.
Every unchecked item should be justified and its associated risks understood. An up to
date version of the checklist can be found in c rytic/building-secure-contracts.
For convenience, all S lither utilities can be run directly on a token address, such as:
slither-check-erc 0xdac17f958d2ee523a[PII_REDACTED]597c13d831ec7 TetherToken
To follow this checklist, you will want to have this output from Slither for the token:
- slither-check-erc [target] [contractName] [optional: --erc ERC_NUMBER]
- slither [target] --print human-summary
- slither [target] --print contract-summary
- slither-prop . --contract ContractName # requires configuration, and use of
Echidna and Manticore
General Security Considerations
❏
The contract has a security review. Avoid interacting with contracts that lack a
security review. Check the length of the assessment (aka “level of effort”), the
reputation of the security firm, and the number and severity of the findings.
❏
You have contacted the developers. You may need to alert their team to an
incident. Look for appropriate contacts on b lockchain-security-contacts.
❏
They have a security mailing list for critical announcements. Their team should
advise users (like you!) when critical issues are found or when upgrades occur.
ERC Conformity
Slither includes a utility, s lither-check-erc, that reviews the conformance of a token to
many related ERC standards. Use slither-check-erc to review that:
❏ Transfer and t ransferFrom return a boolean. Several tokens do not return a
boolean on these functions. As a result, their calls in the contract might fail.
❏ The name, d ecimals, and s ymbol functions are present if used. T hese functions
are optional in the ERC20 standard and might not be present.
❏ Decimals returns a u int8. S everal tokens incorrectly return a u int256. If this is the
case, ensure the value returned is below 255.
❏
The token mitigates the k nown ERC20 race condition. T he ERC20 standard has a
known ERC20 race condition that must be mitigated to prevent attackers from
stealing tokens.
❏ The token is not an ERC777 token and has no external function call in t ransfer
and t ransferFrom. External calls in the transfer functions can lead to reentrancies.
Slither includes a utility, s lither-prop, that generates unit tests and security properties
that can discover many common E