Penetration Test Report (TrailOfBits): PegaSys Pantheon Final Report Updated

PegaSys Pantheon
Ethereum Client Security Assessment
December 5th, 2018
Prepared For:
Faisal Khan | C​ onsenSys
faisal.khan@consensys.net
Meredith Baxter | ​ConsenSys
meredith.baxter@consensys.net
Prepared By:
Evan Sultanik | ​Trail of Bits
evan.sultanik@trailofbits.com
Mike Myers | T​ rail of Bits
mike.myers@trailofbits.com
Paul Kehrer | ​Trail of Bits
paul.kehrer@trailofbits.com
Changelog:
October 22nd, 2018: Initial report delivered
December 5th, 2018: Updates and fixes
Executive Summary
Project Dashboard
Engagement Goals & Coverage
Recommendations Summary
Short Term
Long Term
Findings Summary
1. Invalid entry set in key-value store due to object reuse
2. Multiple remote-code-execution CVEs in JSON deserialization package
3. Multiple CVEs in version of Jenkins server used for Pantheon project
4. Gas overflows can result in null pointer exceptions
5. Unnecessary complexity around setup and use of the CSPRNG
6. Plaintext local storage of node private key risks disclosure
7. <removed after discussion with PegaSys>
8. Unsecured JSON-RPC interface
9. RLP decoding throws on encodings that report a length greater than
Integer.MAX_VALUE
10. Implementation differences between RLP length calculation vs. decoding
11. Pantheon permits RLP encoded ints with leading zeros
12. eth_getTransactionReceipt silently fails for raw transaction
13. Inconsistent milestone defaults can lead to rejected transactions
A. Vulnerability Classifications
B. Code Quality Recommendations
C. Notes on Cryptographic Libraries
JCE providers
Tink
Newer JDK improvements simplify cryptographic operations
urandom permissions issues when reseeding on macOS
D. Additional RLP Unit Tests
E. Using the Java SecurityManager
F. Differential Testing with Etheno
Using Etheno for Differential Testing
Automated Fuzzing with Etheno and Echidna
PegaSys Pantheon Assessment | 1
Executive Summary
From September 24th through October 19th 2018, PegaSys engaged with Trail of Bits to
review the security of their Ethereum client, Pantheon. Trail of Bits conducted this
assessment over the course of eight person-weeks with three engineers working from
commit hash 6​ 8164f65cf7b0467cc5accf88c7c3f50cab9f568 [68164f65] from the
​
Pantheon repository.
In the first week, Trail of Bits reviewed the codebase at a high level, checked for known
vulnerabilities in Pantheon’s dependencies, reviewed the build process and the output of
static analysis tools, and discussed Pantheon’s usage of PRNG APIs, specifically Java’s
SecureRandom.
​
In the second week, we focused on the overall cryptographic design, the use of
cryptographically secure pseudo-random number generation (CSPRNG), the selection of an
entropy source for the CSPRNG, the local storage of private keys, and the risk from
malformed public keys received from peer nodes. Many of these focal areas arose from
discussions with ConsenSys at the start of the effort.
In week three, we focused on issues related to Pantheon’s implementation of Ethereum’s
DevP2P "wire protocol,” including its implementation of RLP deserialization
(Recursive-Length Prefix encoding format, used by Ethereum network nodes). We also
reviewed the EVM implementation, with a specific focus on potential denial-of-service
attacks (e​ .g.,​ gas cost manipulation).
We focused week four on an examination of Pantheon’s implementation of the Ethereum
API specification, and its associated JSON-RPC-based interface. This included the integration
of Pantheon with a custom test tool for Ethereum clients, Etheno, that uses differential
analysis to help identify issues with a client’s transaction handling.
Pantheon’s codebase incorporates a robust set of unit tests that prevented many potential
implementation errors. The Pantheon development team had good intuition about
potentially problematic areas of their codebase, and had prepared well for this
assessment.
One high-severity issue was discovered, related to publicly disclosed vulnerabilities in the
version of one of Pantheon’s Java package dependencies. The other findings were medium-
and low-severity, with the typical impact being a potential denial-of-service. In the case of
the unsecured JSON-RPC interface, the risk is partially mitigated by that interface being
off-by-default.
PegaSys should integrate a dependency security-checking solution with the Pantheon build
system. Our recommendations for the use of secure random number generation will
eliminate the difficulties PegaSys has encountered (complexity, prediction resistance, and
reseeding) without reducing security (q​ q.v. A​ ppendices ​C ​and ​E)​ . Pantheon must implement
the recommended Host header check in its JSON-RPC interface in order to mitigate
PegaSys Pantheon Assessment | 2
browser-based attacks. Incorporating our additional unit tests for RLP and
EVM (​q.v. ​Appendix ​D)​ , including differential testing (q​ .v. ​Appendix ​F​), will further reduce the
likelihood of implementation errors.
PegaSys Pantheon Assessment | 3
Project Dashboard
Application Summary
Name Pantheon
Version 68164f65
Type Ethereum full-node client
Platform Java
Engagement Summary
Dates September 24 to October 19, 2018
Method Whitebox
Consultants Engaged 3
Level of Effort 8 person-weeks
Vulnerability Summary
Total High-Severity Issues 1 ◼
Total Medium-Severity Issues 2 ◼◼
Total Low-Severity Issues 3 ◼◼◼
Total Informational-Severity Issues 5 ◼◼◼◼◼
Total Undetermined-Severity Issues 1 ◼
Total 12
Category Breakdown
Access Controls 1 ◼
Cryptography 1 ◼
Data Exposure 1 ◼
Data Validation 4 ◼◼◼◼
Patching 2 ◼◼
Undefined Behavior 2 ◼◼
Denial of Service 1 ◼
Total 12
PegaSys Pantheon Assessment | 4
Engagement Goals & Coverage
During this assessment, Trail of Bits focused on Pantheon’s use of cryptographic primitives,
the correctness of its EVM implementation, any potential denial-of-service vectors, its
implementation of the DevP2P and RLPx protocols, and its JSON-RPC API.
Crypto
✓ Provide guidance on using S​ ecureRandom correctly
​
✓ Provide guidance on specifying JCE security providers
✓ Dynamic analysis crypto check with ​CryptoSense Analyzer
✓ Review public key exchange between nodes
✓ Provide guidance on node private key storage
EVM
✓ Evaluate the correctness of the EVM implementation
✓ Evaluate gas-cost calculations
✓ Identify any denial-of-service cases in the EVM implementation
DevP2P and RLPx
✓ Review DevP2P edge cases
✓ Review type-handling within RLP decoding implementation
JSON-RPC
✓ Review Pantheon’s JSON-RPC method handlers for logic errors
✓ Review Pantheon’s JSON-RPC method handlers for correctness
✓ Review the localhost-only assurance method for the JSON-RPC interface
✓ Investigate RPC edge cases
Misc.
✓ Static analysis check with D​ evSkim
✓ Enumerate dependencies and review associated codebases for important bugfixes
✓ Examine the use of JNI components RocksDB and Xerial Snappy-Java
✓ Examine the use of a Java Security Manager, if any, as a security sandbox
A future review may wish to examine Pantheon’s implementation of the DevP2P peer
discovery protocol, which is a remaining area to check for exceptional conditions that might
result in a denial-of-service. Likewise, during this assessment we did not examine the use
of the Trie data structure or whether there were any potential abuse cases that could cause
a denial-of-service, because it was considered unlikely and not a current priority.
PegaSys Pantheon Assessment | 5
Recommendations Summary
This section aggregates all the recommendations made during the engagement. Short-term
recommendations address the immediate causes of issues. Long-term recommendations
pertain to the development process and long-term design goals.
Short Term
❑❑ Adopt a dependency-security checking solution and integrate it into Gradle.
Manually checking the security alerts on every dependency in a project is inefficient and
allows a longer window for vulnerabilities to be introduced. Integrating one of the
open-source or commercial solutions for dependency-checking will alert the devel