Penetration Test Report (TrailOfBits): sai

Sai
Security Assessment
Sai Smart Contracts
October 24, 2017
Prepared For:
Andy Milenius | D appHub
andy@dapphub.com
Prepared By:
Josselin Feist | T rail of Bits
josselin@trailofbits.com
Mark Mossberg | T rail of Bits
mark@trailofbits.com
Changelog
October 24, 2017: Initial report delivered
December 15, 2017: Added A ppendix E with retest results
January 31, 2018: Public release
Table of Contents
Table of Contents
Executive Summary
Engagement Goals
Project Dashboard
Vulnerability Classifications
Recommendations Summary
Short Term
Long Term
Findings Summary
1. Race condition in the ERC20 approve function may lead to token theft
2. Unprotected function and integer overflow may lead to system destabilization
3. Reliance on undefined behavior may lead to unexpected behavior
4. Rounding strategy in DSMath fixed-point multiplication/division may lead to errors
5. Misconfigured deploy may lead to unusable system
6. Inconsistent SaiTub.join() docs may lead to unexpected user behavior
7. Race conditions during contracts deployment may lead to system compromise
8. Multiple divisions by zero may lead to unusable system
9. Lack of validation on tax may lead to unusable system
10. Inconsistent debt bookkeeping may lead to trapped tokens
11. Loss of decimal precision leads to free tokens
12. Loss of decimal precision leads to incomplete global settlement
A. Code Quality Recommendations
B. Analysis on the feasibility to call rdiv(x, 0)
C. Test cases
TOB-Sai-008
TOB-Sai-010
TOB-Sai-011: Pattern 1
TOB-Sai-011: Pattern 2
TOB-Sai-011: Pattern 3
TOB-Sai-011: Pattern 4
TOB-Sai-012
2
D. Manticore test case for TOB-Sai-011
E. Fix Log
3
Executive Summary
From September 19 to October 24, DappHub engaged with Trail of Bits to conduct an
assessment of the Sai system, the Dappsys libraries, and the DS-Chief project. All assessed
code was written in Solidity, except for a small number of shell scripts. Trail of Bits
conducted this assessment over the course of eight person-weeks with two engineers.
Trail of Bits completed the assessment using manual, static, and dynamic analysis
techniques. The first week focused on understanding Sai at a high level through
documentation and code, which was checked for common Solidity flaws. The second week
focused on examining the main contracts for more nuanced errors. The third week focused
on reviewing the authorization system as well as exploring mathematical exceptions as a
means of functionality disruption. The last two weeks focused on investigating the
possibility and implications of numerical errors in Sai and auditing DS-Chief (e a8759a0) for
common Solidity errors. Overall, most of the audit resources were devoted to the Sai main
contracts (SaiTub, SaiTap, SaiTop) and DS-Math, which were deemed highest priority. The
other various libraries and DS-Chief were assigned lower priority.
The assessment identified a variety of issues in Sai, including issues of high severity. The
most severe may lead to the generation of tokens for free, trapped tokens, and denial of
service. Though not directly part of Sai, for completeness, a relevant high-severity design
flaw of the ERC20 standard enabling token theft was also reported. Other reported issues
involved various implications of errors in configuration and deployment of the system as a
whole. Inconsistencies of low severity were discovered between documentation and code
in both Sai and DS-Chief, which may lead to incorrect use of the contracts.
Overall, the code reviewed is of excellent quality, written with obvious awareness of current
smart contract development best practices. Sai excels in the area of system design. Its
interfaces are well designed and its use of patterns such as p ull vs p ush token transfer
displays maturity. The emphasis on constant time functions and simple business logic is
another sign of robust Solidity code. In the area of numerical computing, a notoriously
complex field, Sai can be improved. DSMath provides a solid, correct foundation for fixed
point computing. However, its higher level usage in Sai requires vigilance and updates to
ensure that numerical errors are anticipated and handled gracefully by the system.
4
Engagement Goals
The goal of the engagement was to evaluate the security of the Sai system with specific
focus on potential numerical issues enabling stolen or trapped tokens. Specifically, we
sought out answers to the following questions:
● Is it possible for an attacker to steal or trap tokens?
● Is it possible to interfere with the settlement mechanism?
● Are the arithmetic calculations trustworthy?
5
Project Dashboard
Application Summary
Name Sai
Version e138cbdc
Type Ethereum Smart Contract
Platform Solidity
Engagement Summary
Dates September 19 - October 24, 2017
Method Whitebox
Consultants Engaged 2
Level of Effort 8 person-weeks
Vulnerability Summary
◼◼◼◼◼
Total High Severity Issues 5
◼◼◼◼
Total Medium Severity Issues 4
◼◼◼
Total Low Severity Issues 3
Total Informational Severity Issues 0
Total 12
Category Breakdown
◼
Business Logic 1
◼◼
Configuration 2
◼◼
Data Validation 2
◼◼◼◼
Numerics 4
◼
Undefined Behavior 1
◼◼
Timing 2
Total 12
6
Vulnerability Classifications
Vulnerability Classes
Class Description
Access Controls Related to authorization of users and assessment of rights
Auditing and Logging Related to auditing of actions or logging of problems
Authentication Related to the identification of users
Business Logic Related to application business logic
Configuration Related to security configurations of servers, devices or software
Cryptography Related to protecting the privacy or integrity of data
Data Exposure Related to unintended exposure of sensitive information
Data Validation Related to improper reliance on the structure or values of data
Denial of Service Related to causing system failure
Error Reporting Related to the reporting of error conditions in a secure fashion
Numerics Related to numeric calculations
Patching Related to keeping software up to date
Session Management Related to the identification of authenticated users
Timing Related to race conditions, locking or order of operations
Undefined Behavior Related to undefined behavior triggered by the program
7
Severity Categories
Severity Description
Informational The issue does not pose an immediate risk, but is relevant to security
best practices or Defense in Depth
Undetermined The extent of the risk was not determined during this engagement
Low The risk is relatively small or is not a risk the customer has indicated is
important
Medium Individual user’s information is at risk, exploitation would be bad for
client’s reputation, moderate financial impact, possible legal
implications for client
High Large numbers of users, very bad for client’s reputation, or serious
legal or financial implications
Difficulty Levels
Difficulty Description
Undetermined The difficulty of exploit was not determined during this engagement
Low Commonly exploited, public tools exist or can be scripted that exploit
this flaw
Medium Attackers must write an exploit, or need an in-depth knowledge of a
complex system
High The attacker must have privileged insider access to the system, may
need to know extremely complex technical details or must discover
other weaknesses in order to exploit this issue
8
Recommendations Summary
Short Term
Mitigate all rounding issues. T hese issues may lead to free tokens or trapped users.
Remediate all the other identified vulnerabilities. Remove D S‑Warp, add the proper
checks for the functions parameters. Except for the rounding issues, all the identified
issues have straightforward solutions.
Update and document the deployment scripts. The Sai deployment is a key step in the
system. It has to be updated and documented in sync with the code.
Long Term
Verify the corner cases of mathematical operations. E nsure that mathematical corner
cases, such as rounding, integer overflow/underflow, division by zero, modulo by zero, are
properly handled. Consider formal methods for