Penetration Test Report (TrailOfBits): Liquity

Liquity
Security Assessment
January 1 3, 2 021
Prepared For:
Robert Lauko | L iquity
robert@liquity.org
Rick Pardoe | L iquity
rick@liquity.org
Prepared By:
Alexander Remie | T rail of Bits
alexander.remie@trailofbits.com
Gustavo Grieco | T rail of Bits
gustavo.grieco@trailofbits.com
Maximilian Krüger | T rail of Bits
max.kruger@trailofbits.com
Michael Colburn | T rail of Bits
michael.colburn@trailofbits.com
Changelog:
December 18, 2020: Initial report delivered
January 13, 2021: Added Appendix G. Fix Log
Executive Summary
Project Dashboard
Code Maturity Evaluation
Engagement Goals
Coverage
Automated Testing and Verification
Automated Testing with Echidna
General Properties
ERC20 Properties
Recommendations Summary
Short term
Long term
Findings Summary
1. ERC20 transfer restriction can disturb 3rd-party interactions
3. No restrictions on minting to invalid recipients
4. Insufficient enforcement of immutability of system logic variables through the
Solidity compiler
5. Unclear if the gas pool account is controlled by someone
6. Reentrancy could lead to incorrect order of emitted events
7. Missing address validation when configuring contracts
8. Permit opens the door for griefing contracts that interact with the Liquity Protocol
9. Closing troves requires owners to hold the full amount of LUSD minted
10. Failed lockup error is never thrown
11. Duplicated functions pose future risk of diverging
12. Total system collateral and debt calculations are repeated multiple times risking
divergence and decreasing readability
13. Troves can be improperly removed under certain circumstances which results in
unexpected reverts
14. Initial redeem can unexpectedly revert if no redeemable troves
15. Redeem without redemptions might still return success
A. Vulnerability Classifications
B. Code Maturity Classifications
C. Code Quality
D. Known Issues
© 2021 Trail of Bits Liquity Assessment | 1
LQT-D01. Loss evasion by Stability Pool depositors front-running liquidations:
LQT-D02: Making profiting front-running other transactions
LQT-D03: Explore possible issue with ecrecover
E. Check operations on integers smaller uint256 with Slither
F. Check receiving and sending of Ether with Slither
G. Fix Log
Detailed Fix Log
© 2021 Trail of Bits Liquity Assessment | 2
Executive Summary
From November 31 through December 18 2020, Liquity engaged Trail of Bits to review the
security of their LUSD stablecoin. Trail of Bits conducted this assessment over the course of
8 person-weeks with 4 engineers working from commit f 0df3ef of the l iquity/dev
repository.
During the first week, we focused on gaining an understanding of the codebase and started
to review the two ERC20 tokens (LUSD and LQTY) and the trove and borrower operations
against the most common Solidity flaws. During the second week, we focused on reviewing
the smart contracts that perform trove and borrower operations to look for flaws that
would allow an attacker to bypass access controls, disrupt or abuse the contracts in
unexpected ways. The final week was dedicated to the review of the system properties as
well as the more complex interactions between the troves and the pools.
Our review resulted in 14 findings ranging from high to informational in severity, with two
important sources of issues. The most important category was missing or incorrect input
validation, which produced the most severe issues, including arbitrary ERC20 restrictions
when transferring (T OB-LQT-001) , an improper handling of troves (T OB-LQT-013) ,
unexpected failure when redeeming collateral for the first time (T OB-LQT-014) .
The second category were issues related to source code maintenance or patching, which
produced issues that could impact future code modifications or third-party interaction with
them. These issues include duplicated code that could diverge in future revisions
(T OB-LQT-011, T OB-LQT-012) , lack of usage of immutable state variables (T OB-LQT-004) .
In addition to the security findings, we discuss code quality issues not related to any
particular vulnerability in A ppendix C. A ppendix D discusses several issues the Liquity team
identified prior to this assessment and requested guidance on. A ppendix E and A ppendix F
describe S lither scripts produced by Trail of Bits to facilitate our review.
Overall, the code follows a high-quality software development standard and best practices.
It has a suitable architecture and is properly documented. The interactions between
components are well-defined, and the testing is very extensive.
Trail of Bits recommends addressing the findings presented and expanding the
property-based testing with more system invariants. Finally, we recommend performing an
economic assessment to make sure the monetary incentives are properly designed.
Update: During the week of January 11, 2021, Trail of Bits reviewed fixes by Liquity for the issues
presented in this report. See a detailed review of the current status of each issue in A ppendix G.
© 2021 Trail of Bits Liquity Assessment | 3
Project Dashboard
Application Summary
Name Liquity
Version f0df3ef
Type Smart Contracts
Platforms Solidity
Engagement Summary
Dates November 30 to December 18, 2020
Method Whitebox
Consultants Engaged 4
Level of Effort 8 person-weeks
Vulnerability Summary
◼
Total High-Severity Issues 1
◼◼
Total Medium-Severity Issues 2
◼◼◼◼◼◼◼
Total Low-Severity Issues 8
◼◼◼
Total Informational-Severity Issues 4
Total Undetermined-Severity Issues 0
Total 14
Category Breakdown
◼
Access Controls 1
◼
Auditing and Logging 1
◼◼◼◼◼
Data Validation 5
◼◼◼
Patching 4
◼
Timing 1
◼◼◼
Undefined Behavior 3
Total 14
© 2021 Trail of Bits Liquity Assessment | 4
Code Maturity Evaluation
In the table below, 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.
Category Name Description
Access Controls Strong. Appropriate access controls were in place for performing
privileged operations by certain contracts.
Arithmetic Moderate. The contracts included use of safe arithmetics. No
potential overflows were possible in areas where these functions
were not used. However, certain arithmetic operations in corner
cases could block the trove operations (T OB-LQT-013, T OB-LQT-014)
Assembly Use Strong. The contracts only used assembly to fetch the c hainID for
ERC2612 p ermit functionality.
Centralization Strong. W hile the protocol relied on an owner to correctly deploy
the initial contracts, the ownership is renounced immediately after
it. There are no other privileged accounts.
Contract Not Applicable. The contracts contained no upgradeability
Upgradeability mechanisms.
Function Satisfactory. While most of the functions and contracts were
Composition organized and scoped appropriately, the borrower operations
contract code was difficult to review and should be refactored
(A ppendix C) .
Front-Running Moderate. Some functionality is affected by front-running attacks,
with a moderate impact (A ppendix D) .
Monitoring Satisfactory. T he events produced by the smart contract code were
sufficient to monitor on-chain activity.
Specification Moderate. White papers describing the functionality of the protocol
were available. However, some of the internal documentation
regarding system properties was outdated and incomplete.
Testing & Strong. The contracts included a very large number of unit tests and
Verification even the use of automatic tools such as fuzzers.
© 2021 Trail of Bits Liquity Assessment | 5
Engagement Goals
The engagement was scoped to provide a security assessment of Liquity protocol smart
contracts in the l iquity/dev repository.
Specifically, we sought to answer the following questions:
● Are appropriate access controls set for system components?
● Is it possible to manipulate the system by front-running transactions?
● Is it possible for participants to steal or lose tokens?
● Are there any instances whe