Penetration Test Report (TrailOfBits): RSKj

RSKj
Security Assessment
November 13, 2017
Prepared For:
RSK Labs
Prepared By:
Josselin Feist | T rail of Bits
josselin@trailofbits.com
Evan Sultanik | T rail of Bits
evan.sultanik@trailofbits.com
Changelog
November 13, 2017: Initial report delivered
November 30, 2017: Added A ppendix F with retest results
December 4, 2017: Updated A ppendix F with notes about EIP 161
Executive Summary
Project Dashboard
Goals
Coverage
Recommendations Summary
Short Term
Long Term
Findings Summary
1. Resource Leaks in Trie
2. Headers Not Properly Deleted in the BlockStore
3. Infinite Loop in EthereumJ Key Verification
4. Integrate Infer into the RSKj Build Process
5. Erroneous Gas Computation in CALL Breaks Sending Ether to a Contract
6. Wrong msg.value Parameter in CREATE Leads to a Broken Contract
7. Duplicated Logs May Lead to Misinterpreted Events
8. Incorrect Gas Computation in Modexp
9. Missing Implementation of EIPs May Lead to Denial of Service
10. Incorrect Encoding Implementation Leads to Wrong RLP Encoding
A. Vulnerability Classifications
B. SpotBugs Documentation
C. Coding Practices
D. Test cases
E. Exploitable Smart Contracts
TOB-RSK-005
TOB-RSK-006
F. Fix Log
About Trail of Bits
© 2017 Trail of Bits R SKj Security Assessment |2
Executive Summary
RSK engaged Trail of Bits to perform an audit of RSKj, its solution for providing smart
contracts using the Bitcoin cryptocurrency. Two Trail of Bits researchers performed the
assessment from October 23rd through November 10th, 2017. The engagement was
conducted as a source code review focusing on smart contract issues related to the virtual
machine, virtual machine compatibility with other Ethereum implementations, correctness
of the Trie data structure, and correctness of the precompiled contracts for the two-way
peg. RSK also expressed concern about general susceptibility to denial of service attacks.
Trail of Bits completed the assessment using static and dynamic analysis techniques over a
period of three calendar weeks. During the first week, Trail of Bits gained an understanding
of the VM architecture and how to interact with and test its implementation. During the
second week, Trail of Bits reviewed the correctness of the EVM opcode implementations,
their gas consumption, and the Trie data structure implementation. For the last week, Trail
of Bits continued the analysis of EVM opcode implementations, attempted to break the
virtual machine through exceptions, and audited the precompiled smart contracts,
including the two-way peg bridge.
The assessment identified a variety of issues in RSKj, including two high-severity findings in
the EVM implementation. These issues would allow an attacker to craft smart contracts that
are secure in Ethereum, but contain a backdoor when run in RSKj. As a result, an attacker
could fool users and steal ether. As these issues are all related to the EVM implementation,
we expect that similar issues may be present. Also, we report less-severe vulnerabilities
related to the EVM implementation and possible denial of service due to memory leaks
caused by improper resource management.
We discovered several concurrency issues where guarded variables are manipulated
without proper lock synchronization. Furthermore, the code contains several common Java
errors such as using primitive arrays as map keys and classes that override e quals but not
hashCode. These code quality issues and others like them may lead to the introduction of
future vulnerabilities, discussed in A ppendix C. Therefore, Trail of Bits recommends that
RSK consider these issues and enforce coding standards to eliminate them.
The discovered vulnerabilities and the current state of the platform are as expected. RSKj is
a complex system that integrates and extends several disparate technologies. Like any
complex system, a multitude of corner cases must be handled properly in order to avoid
potential bugs. An effort has been made to address specific areas of concern, such as
integer overflows in gas computation. Further efforts are required to properly protect RSKj
against other attack vectors. RSKj should correct the identified vulnerabilities, follow strict
coding rules, and anticipate future vulnerability discovery by adding thorough unit tests.
© 2017 Trail of Bits R SKj Security Assessment |3
Project Dashboard
Application Summary
Name RSKj
Version 4cb1492b
Type Smart Contract Platform
Platform Java
Engagement Summary
Dates October 23 - November 10, 2017
Method Whitebox
Consultants Engaged 2
Level of Effort 6 person-weeks
Vulnerability Summary
◼◼
Total High Severity Issues 2
◼◼◼
Total Medium Severity Issues 3
◼◼
Total Informational Severity Issues 2
◼◼◼
Total Undetermined Severity Issues 3
Total 10
Category Breakdown
◼◼◼◼◼◼
Denial of Service 6
◼◼◼
EVM incompatibility 3
◼
Data Validation 1
Total 10
© 2017 Trail of Bits R SKj Security Assessment |4
Goals
The goal of the engagement was to evaluate the security of RSKj with a particular focus on
potential denial of service vulnerabilities and errors in the EVM implementation.
Specifically, we sought answers to the following questions:
● Bitcoin SPV proofs: Are the merge-mining implementation and SPV proof
verification correct? Two nodes should not disagree on the sequence of blocks in the
blockchain.
● Bridge: Is the pre-compiled smart contract that implements the two-way peg
correct? Malicious RSK contracts can interact with the Bridge to exploit denial of
service or logical flaws that lead to incorrect accounting of ether or gas.
● Consensus: Is RSKj correctly handling block and signature validation? A miner could
abuse consensus to receive more reward than intended.
● EVM Compatibility: Is the Ethereum EVM specification correctly followed? RSKj
should execute contracts in the same manner as other Ethereum implementations.
Inconsistencies may be exploited to cause denial of service or loss of ether.
● JSON RPC: Are the remote procedure calls to modules secure? Remote attackers
may seek to abuse these interfaces to cause denial of service or execute commands
without authorization.
● Trie Implementation: Is RSKj’s Trie implementation correct? An adversary might be
able to cause a block that exercises the Trie’s worst case computational complexity,
thus creating a denial of service.
© 2017 Trail of Bits R SKj Security Assessment |5
Coverage
EVM compatibility. W e analyzed the EVM implementation for errors in instruction
execution and in gas consumption. We looked for arithmetic issues (e .g., integer overflows),
incorrect exception handling, and errors in the logic of the instructions. This area of
concern was one of our primary targets. We found a number of severe vulnerabilities.
General DoS Attacks. RSK asked us to focus on denial of service issues. For that reason,
we identified the six specific categories of bugs that are most likely to result in such a
vulnerability:
Denial of Service Bug Examples of What We Looked For Number
Discovered
Livelock Infinite loops 1
Deadlock Mutex locking and concurrency issues 0†
Memory Exhaustion Memory leaks and incorrect resource cleanup 2
Algorithmic Complexity Forcing hash collisions in data structure 0
lookups
EVM Bugs Contract operations that perform computation 2
that is not commensurate with their gas cost
Data Corruption Operations that can corrupt the node’s internal 1
state, causing it to be inoperable
† We found several instances of methods that could overwrite guarded variables without a
lock on their associated mutex. However, we could not exploit these bugs.
Trie Implementation. We analyzed the Trie data structure for both logical errors and
potential denial of service attacks (e .g., algorithmic complexity vulnerabilities such as hash
collision attacks), but were unable to discover any. Since the TrieStore holds serialized
copies of Tries, we checked if there were any instances of unnecessary saving to the
TrieStore, which would impose a significant memory overhead. All usage of the TrieStore
appeared to be correct.
Du