Penetration Test Report (Consensys): omisego morevp audit 2019 10

Omisego Morevp Audit
1 Summary Date January 2020
2 Audit Scope
Lead Auditor Alexander Wade
3 Key Observations/Recommendations
Co-auditors Daniel Luca, Martin Ortner
4 Security Specication
4.1 Actors
4.2 Trust Model
5 Issues
5.1 Merkle.checkMembership allows existence proofs for the same leaf in
multiple locations in the tree Critical ✓ Addressed
5.2 Improper initialization of spending condition abstraction allows “v2
transactions” to exit using PaymentExitGame Major ✓ Addressed
5.3 RLPReader - Leading zeroes allow multiple valid encodings and exit / output
ids for the same transaction Major ✓ Addressed
5.4 Recommendation: Remove TxFinalizationModel and
TxFinalizationVerifier . Implement stronger checks in Merkle Medium
5.5 Merkle - The implementation does not enforce inclusion of leaf nodes. Medium
✓ Addressed
5.6 Maintainer can bypass exit game quarantine by registering not-yet-deployed
contracts Medium ✓ Addressed
5.7 EthVault - Unused state variable Minor ✓ Addressed
5.8 Recommendation: Add a tree height limit check to Merkle.sol Minor
5.9 Recommendation: remove IsDeposit and add a similar getter to
BlockController Minor ✓ Addressed
5.10 Recommendation: Merge TxPosLib into UtxoPosLib and implement a
decode function with range checks. Minor
5.11 Recommendation: Implement additional existence and range checks on
inputs and storage reads Minor
5.12 Recommendation: Remove optional arguments and clean unused code
Minor ✓ Addressed
5.13 Recommendation: Remove WireTransaction and PaymentOutputModel .
Fold functionality into an extended PaymentTransactionModel Minor
5.14 ECDSA error value is not handled Minor ✓ Addressed
5.15 No existence checks on framework block and timestamp reads Minor
✓ Addressed
5.16 BondSize - effectiveUpdateTime should be uint64 Minor
5.17 PaymentExitGame contains several redundant plasmaFramework
declarations Minor
5.18 BlockController - inaccurate description of childBlockInterval for
submitDepositBlock Minor
5.19 PlasmaFramework - Can omit inheritance of VaultRegistry Minor
5.20 BlockController - maintainer should be the only entity to set new authority
Minor ✓ Addressed
Appendix 1 - Scope
Appendix 2 - Disclosure
1 Summary
ConsenSys Diligence conducted a security audit of OmiseGo’s plasma framework
contracts. The contracts are their implementation of More Viable Plasma (MoreVP), which
is based on Minimal Viable Plasma (MVP). MoreVP aims to improve on Plasma’s UX by
getting rid of MVP’s conrmation signatures in favor of a more involved exit game.
Diligence performed a secondary review of the plasma contracts following OmiseGo’s
implementation of fee transaction types as well as their inclusion of xes from our initial
review.
2 Audit Scope
Our review was concerned primarily with the smart contracts in OmiseGo’s plasma-
contracts repository. We began our review at commit
e13aaf759c979cf6516c1d8de865c9e324bc2db6.
Our subsequent review began at commit
9d79e35811a483277d4cd8b06b1678efc9f33151.
A complete list of Solidity les reviewed can be found in the appendix.
3 Key Observations/Recommendations
The bulk of the code (~80%) is concerned with the MoreVP exit game. Of this code,
large portions of many contracts are irrelevant to the intended behavior of the system:
boilerplate and leftovers from unused extensibility features.
The inclusion of this code makes it dicult to understand many components.
Code is spread across a sprawling le structure, and understanding individual
features involves hopping between les frequently.
The unused code may have unintended side effects. External calls and
delegatecalls are often made. Memory is frequently allocated without cause.
Functions often have more parameters than they use. It may be that these affect
the function of the contracts in some subtle way.
Update: Since our initial review, signicant refactoring has removed much of the
unused code initially found. In particular, the removal of unused parameters and
features like the output guard handler made it easier to reason about the code
(see 5.12).
Many future features are planned, but not yet implemented. The extensibility features
mentioned above are meant to support new features when they are released, but,
crucially, will never serve a purpose in the existing system post-deployment. Assuming
the system is deployed and initialized correctly, the extensibility features in the existing
codebase will never be active.
Instead, future features will be added via the registration of new exit games and
vaults. This process involves a quarantine period whereby users can ensure that
new features are understood and audited before being used. The quarantine
period is based on the minimum exit period, so that users are free to opt-out via
exit before any new features become active.
Some future features are represented in the current system. Of note is plasma
transaction fees, which are represented in the exit state transition verier contract.
This contract checks that the sum of the denominations of each input is greater
than or equal to the sum of the denominations of each output. Should fees not be
implemented, this representation is incorrect and could lead to invalid
transactions exiting successfully.
Update: Since our initial review, transaction fees have been implemented and
included in the smart contracts as rst-class citizens. However, the contracts are
still highly complex due to heavy use of abstractions and a complicated
transaction decoding scheme. The potential to enable future transaction types
and decoding schemes plays a large role in obfuscating the business logic of the
contracts. This obfuscation is magnied by the codebase’s aforementioned
sprawling le structure and relative lack of code commenting. Further work should
attempt to limit this sprawl and focus on making implementation details more
clear.
Because MoreVP does not use conrmation signatures, verifying a transaction’s
validity is nearly impossible in the resource-constrained environment of the EVM. To
get around this limitation, MoreVP allows invalid transactions to be exited. In order to
avoid losing funds, users must be sure that they are running the child chain watcher,
and that it is correctly congured to notify them of byzantine scenarios.
As a safeguard to the potential exiting of invalid transactions, users can perform a
mass exit. In this case, the gas cost required to exit each UTXO is a critically-
important bottleneck. Should a mass exit be too resource-intensive, the network
may be clogged up and invalid transactions may be exited successfully. Future
work on this codebase should make additional steps to ensure that exit game
implementations are as ecient as possible.
Update: As with any highly-complex system, it is impossible to account for every
possibility before launching. Our review was primarily concerned with the plasma
smart contracts as the critical point of infrastructure, but left other important
components nearly untouched. Of particular note is the implementation of the child
chain watcher (and its integration with the plasma chain), which serves as a crucial
safeguard for users during production.
Our review uncovered several issues in a highly complex codebase, and more were
uncovered by OmiseGo’s development team during the engagement. We highly
recommend proceeding with caution: rather than pushing immediately for a full-
scale production release, a testnet, public bug bounty, limited release, or a
combination of all of these would allow OmiseGo to work out the kinks of the
system before it reaches critical mass.
4 Security Specication
This section describes, from a security perspective, the expected behavior of the system
under audit. It is not a substitute for documentation. The purpose of this section is to
identify specic security properties that were validated by the audit team.
4.1 Actors
The relevant actors are as follows:
Operator: Runs the child chain and submits child chain blocks to the
PlasmaFramework contract.
Mainta