Penetration Test Report (TrailOfBits): BalancerCore

Balancer Core
Security Assessment
March 5 , 2 020
Prepared For:
Mike McDonald | B alancer Labs
mike@balancer.finance
Fernando Martinelli | B alancer Labs
fernando@balancer.finance
Prepared By:
Josselin Feist | T rail of Bits
josselin.feist@trailofbits.com
Gustavo Grieco | T rail of Bits
gustavo.grieco@trailofbits.com
Changelog:
February 21, 2020: Initial report delivered
March 5, 2020: Reviewed and updated content
/
Executive Summary
Project Dashboard
Engagement Goals
Coverage
Automated Testing and Verification
Automated Testing with Echidna
General Properties
Unit–test-based Properties
Code Verification with Manticore
Recommendations Summary
Short Term
Long Term
Findings Summary
1. Single-asset liquidity functions allow stealing of assets
2. Lack of events in setBLabs is error-prone
3. Parameters’ order of single-asset functions is confusing
4. Assets will be lost in case of token migration
5. Users can silently burn tokens with transfers to 0x0
6. Privileged addresses can be transferred without confirmation even to invalid values
7. Users can join and exit pools even where there are no tokens
8. Single-asset exit functions allow withdrawing of a negligible amount of assets for
free
9. Assets with low decimals or low liquidity lead to withdraw a negligible amount of
assets for free
10. Rounding issues in joinPool/exitPool allow for a negligible amount of free pool
tokens
11. Attacker with large funds can steal the pool's assets
12. The normalized sum of the weight is not always equal to 1
13. Pools with a large total supply cause SWAP functions to always revert
14. Token balance limits are declared but not enforced
15. The swap-in and swap-out ratios are not correctly enforced
A. Vulnerability Classifications
B. Fix Log
Detailed Fix Log
© 2020 Trail of Bits Balancer Core Assessment | 1
/
Executive Summary
From January 13 through January 24, 2020, Balancer Labs engaged Trail of Bits to review
the security of Balance Core. Trail of Bits conducted this assessment over the course of
four person-weeks with two engineers working from 9 42a51e2 from the balance-core
repository.
We focused on identifying important system properties to test using fuzzing (E chidna) and
to verify with symbolic execution (M anticore) . Specifically, we spent most of our time
reviewing and testing arithmetic properties within the source code.
In total, Trail of Bits identified fifteen issues ranging from informational- to high-severity.
One large category of findings allowed an attacker to obtain free tokens from pools. These
issues were caused either by missing input validation during the pool creation or rounding
issues during computation of the amount of tokens required to join, exit, or swap in pools.
The issues of lowest severity were caused by lack of documentation for the use of tokens
and their limitations when binding into a pool.
Overall, the code follows a high-quality software development standard and best practices.
It has suitable architecture and is properly documented. The interactions between
components are well-defined. The functions are small, with a clear purpose.
However, due to time constraints, only manual verification of essential properties related
to token swapping was performed. Trail of Bits recommends performing further testing
with fuzzers and symbolic executors to test extended safety and correctness properties of
that important feature.
© 2020 Trail of Bits Balancer Core Assessment | 2
/
Project Dashboard
Application Summary
Name Balancer Core
Version 942a51e202cc5bf9158bad77162bc72aa0a8afaf
Type Smart Contracts
Platforms Solidity
Engagement Summary
Dates January 13 to January 24, 2020
Method Whitebox
Consultants Engaged 2
Level of Effort 4 person-weeks
Vulnerability Summary
◼◼
Total High-Severity Issues 2
◼◼◼
Total Medium-Severity Issues 3
◼◼◼◼
Total Low-Severity Issues 4
Total Informational-Severity Issues 4 ◼◼◼◼
Total Undetermined-Severity Issues 2 ◼◼
Total 15
Category Breakdown
◼◼◼◼◼◼◼
Data Validation 7
◼
Access Controls 1
◼
Auditing and Logging 1
◼◼◼◼◼
Undefined Behavior 5
◼
Patching 1
Total 15
© 2020 Trail of Bits Balancer Core Assessment | 3
/
Engagement Goals
The engagement was scoped to provide a security assessment of Balance Core protocol
smart contracts in the b alancer-core repository.
Specifically, we sought to answer the following questions:
● Are appropriate access controls set for the user/controller roles?
● Does arithmetic regarding pool operations hold?
● Is there any arithmetic overflow or underflow affecting the code?
● Can participants manipulate or block pool operations?
● Is it possible to manipulate the pools by front-running transactions?
● Is it possible for participants to steal or lose tokens?
● Can participants perform denial-of-service or phishing attacks against any of the
pools?
© 2020 Trail of Bits Balancer Core Assessment | 4
/
Coverage
The engagement was focused on the following components:
● BPool and its libraries: Pools contains the main business logic within the Balancer
protocol. They allow users to bind any proper ERC20 token. We reviewed the
contract's interactions with these external, untrusted token contracts, to ensure
proper behavior. Once a pool is finalized or made public, we review the use of all its
operations to join, exit or swap tokens.
● BFactory: P ools are created in a special factory contract. We reviewed the access
control of this contract as well as the interaction with the pools once they are
deployed.
● BToken: P ools mints or burns their own share tokens every time a user joins or
exits the pool with tokens. This contract implements a standard ERC20 token. We
verified that all the expected properties are correctly implemented.
● Whitepaper: t he Balancer components are detailed in its w hitepaper. We reviewed
the document to make sure it is consistent and it does not leave any important
detail unspecified.
● Access controls. Many parts of the system expose privileged functionality, such as
setting protocol parameters or managing pools. We reviewed these functions to
ensure they can only be triggered by the intended actors and that they do not
contain unnecessary privileges that may be abused.
● Arithmetic. We reviewed calculations for logical consistency, as well as rounding
issues and scenarios where reverts due to overflow may negatively impact use of
the protocol.
It is worth noting that due to time constraints, some properties related to token swapping
were not covered. This includes the proper usage of s wapExactAmountIn and
swapExactAmountOut, as well as the interaction with the other functions.
Off-chain code components were outside the scope of this assessment.
© 2020 Trail of Bits Balancer Core Assessment | 5
/
Automated Testing and Verification
Trail of Bits used automated testing techniques to enhance coverage of certain areas of the
contracts, including:
● Slither, a Solidity static analysis framework. Slither can statically verify algebraic
relationships between Solidity variables. We used Slither to detect invalid or
inconsistent usage of the contracts' APIs across the entire codebase.
● Echidna, a smart contract fuzzer. Echidna can rapidly test security properties via
malicious, coverage-guided test case generation. We used Echidna to test the
expected system properties of the pool contract and its dependencies.
● Manticore, a symbolic execution framework. Manticore can exhaustively test
security properties via symbolic execution.
Automated testing techniques augment our manual security review but do not replace it.
Each technique has limitations: Slither may identify security properties that fail to hold
when Solidity is compiled to EVM bytecode; Echidna may not randomly generate an edge
case that violates a property; and Manticore may fail to complete its analysis. To mitigate
these risks, we generate 50,000 test cases per property with Echidna, run Manticore for a
minimum of one hour, and then manually review all results.
Automated Testing with Echidna
Echidna pro