Penetration Test Report (TrailOfBits): livepeer

Livepeer
Security Assessment
Smart Contract and Token Protocol
March 12, 2018
Prepared For:
Doug Petkanics | L ivepeer
doug@livepeer.org
Prepared By:
Evan Sultanik | T rail of Bits
evan.sultanik@trailofbits.com
Chris Evans | T rail of Bits
chris.evans@trailofbits.com
Changelog
March 9, 2018: Initial report delivered
March 10, 2018: Added informational finding T OB-Livepeer-005
March 12, 2018: Public release
© 2018 Trail of Bits Livepeer Security Assessment | 1
Executive Summary
Coverage
Project Dashboard
Recommendations Summary
Short Term
Long Term
Findings summary
1. Transcoder election can be predictable and influenced
2. Loss of precision for sufficiently high denominator and amount
3. Pseudorandom number generation is not random
4. Transcoders with low bonded stake can avoid slashing penalties
5. Bonding synchronization errors between data structures can enable stolen and
locked tokens
A. Vulnerability classifications
B. Code quality recommendations
C. Slither
Usage
D. Storage mapping deletion pattern in SortedDoublyLL
E. Pseudorandom number generation in smart contracts
© 2018 Trail of Bits Livepeer Security Assessment | 2
Executive Summary
From February 26 through March 9, 2018, Livepeer engaged with Trail of Bits to assess the
Livepeer system’s smart contracts. The assessed contracts components were written in
Solidity with a small amount of EVM assembly. Trail of Bits conducted this assessment over
the course of four person-weeks with two engineers.
The priority of the assessment focused on interactions between bonding management, job
management, stake and earning allocation, and round progression. We directed extensive
static analysis and dynamic instrumentation effort towards finding interactions that could
lead to ill-gotten monetary gain or denial of service attacks against the protocol.
The code reviewed is of excellent quality, written with obvious awareness of current smart
contract development best practices and utilizing well tested frameworks such as
OpenZeppelin. T he manager proxy and delegate controller contracts are restrictive enough
to defend against any unauthorized administrative action.
The Livepeer protocol is designed to make several randomized decisions which are
generally unfair and susceptible to collusion. The logic and state machines of the managers
are very complex and could easily harbor new vulnerabilities as the result of a hasty future
refactor. Edge-cases related to the floating-point and linked-list implementations can
prevent delegated stake from being burnt after a slash. Analysis of the utility libraries for
floating-point and linked-list implementations revealed some edge-case scenarios that
prevent some delegated stake from burning after being slashed.
Overall the largest indicator of Livepeer’s security strength is the consistency of its code.
Integration and unit tests handle many edge cases that result from normal use of the
protocol. Changes made in response to these findings can indirectly mitigate many exploit
patterns. Extensive parameter handling and requirements also reduce the threat of
malformed patterns.
As development of smart contract software continues, ensure the same level of consistency
is maintained when adding features or upgrading pre-existing components. The current
iteration of the smart contract protocol provides a secure foundation and meets many of
the standards set by the Livepeer platform.
Appendix B and A ppendix D contain references to implementation specifics that will help
developing around certain areas of the code. A ppendix C contains a short reference to the
Slither static analyzer used in this engagement and accompanied with the final report.
Appendix E discusses the challenges of pseudorandom number generation with respect to
findings T OB-Livepeer-001 and T OB-Livepeer-003.
© 2018 Trail of Bits Livepeer Security Assessment | 3
Engagement Goals & Scope
The engagement was scoped to provide a security assessment of the risk factors related to
the core Livepeer smart contract implementation and ecosystem.
In particular we sought to answer the following questions:
● Is it possible for an unauthorized third party to gain administrative access to
deployed Livepeer contracts?
● Are tokens managed and stored securely within the contract?
● Can participants manipulate the bonding and transcoding protocols to gain an
unfair advantage?
● Is it possible to cause the contract services to enter an unrecoverable state?
The following components remained out of scope and were not examined as part of the
assessment:
● The external TrueBit verification protocol for transcoded segments.
● Network protocols for peer-to-peer video streaming and playback.
● Transcoding libraries and software for desktop and mobile applications.
● The out-of-band storage and retrieval of transcoded segments on the Swarm layer.
● The Livepeer website and online media platform.
Trail of Bits conducted a detailed security analysis from the perspective of an attacker with
access to the public Livepeer documentation and source code. We sought to identify risks,
and scored their severity based on their likelihood and potential impact. We also sought to
provide a mitigation strategy for each risk factor, whether it required a procedural change
or a replacement of the solution, in whole or in part, with a more secure alternative.
© 2018 Trail of Bits Livepeer Security Assessment | 4
Coverage
While the entire codebase was inspected for common solidity flaws, this audit focused on
an in-depth analysis of the job, rounds, and bonding managers. Since the quality of the
coding standards are so high, latent bugs are likely to be related to logic or concurrency.
ERC20 token implementation and genesis. S cenarios involving token ownership,
transfer, and minting were assessed and tested. Usage of the OpenZepplin base templates
were analyzed for attack surface exposure. The initial token release contract was verified to
conform with standard ICO and crowdsale procedures. In the initial token genesis we
looked for initial parameters that could trigger the end of token distribution and delegation
prematurely. Proper handling of grant allocation arithmetic was inspected, but owner
restrictions on critical functions prohibited any extensive tampering outside of initialization.
Token minting and inflation. The token minter contract was primarily analyzed for use
cases that could manipulate inflation management to create unstable and unreasonable
bonding rates. Conditional logic prevents underflowing the inflation. However, the absence
of SafeMath might cause problems in the future.
Floating point arithmetic library. P ercentage calculations were explored for edge cases
that could cause unintentional behavior in the core contract logic. The precision limits of
basic fractional operators were explored and tested for consistency and correctness
against expected results.
Internal on-chain data structures. T he double linked-list for transcoder pools was
interrogated for bugs and situations that could corrupt the integrity of the data stored. It
was also tested for resilience against unorthodox requests for rapid insertion and removal
of nodes.
Job management protocols. B ehavior for creation of transcoding jobs as well as claiming
rewards for completed work were examined for vulnerabilities. The penalty mechanism for
slashing dishonest participants was also explored for use cases of potential abuse.
Rounds Management Protocols. T he mechanism for scheduling activity on the Livepeer
network was inspected for issues that could lead to deadlock or miscalculation. The
invariant assumptions of elapsed time, locking periods, and permissible function calls
within a round were tested.
Earnings protocols. The mechanism for claiming work was inspected to see if the checks
could be bypassed, e .g., via a race condition. The verification methods were evaluated for
determinism and their susceptibility to collusion. Fee and earnings share stabili