Penetration Test Report (TrailOfBits): Symbol

Symbol
Security Assessment
27th J uly, 2 020
Prepared For:
Iain Wilson | N EM Group
info@nem.group
Dave Hodgson | N EM Group David Mansell | N EM Group
info@nem.group info@nem.group
Prepared By:
Dominik Czarnota | T rail of Bits Jim Miller | T rail of Bits
dominik.czarnota@trailofbits.com jim.miller@trailofbits.com
David Pokora | T rail of Bits
david.pokora@trailofbits.com
Changelog:
Jul 27, 2020: Initial report draft
Aug 7, 2020: Updated issue #11
Aug 31, 2020: Added Appendix D. Fuzzing catapult-server
Sep 18, 2020: Updates made to Appendix D
Sep 24, 2020: Added Appendix E. Fix Log
Oct 30, 2020: Review of amendments detailed in Appendix F
Nov 25, 2020: Review of amendments detailed in Appendix G
Dec 7, 2020: Added Appendix H and extended executive summary
Executive Summary
Project Dashboard
Engagement Goals
Coverage
Recommendations Summary
Short term
Long term
Findings Summary
1. Missing compiler mitigations
2. Undefined behavior dereferencing std::list.back() on an empty container
3. Current ConfigurationBags verification may lead to bugs
4. High-entropy RNG does not guarantee high entropy
5. Use O_CLOEXEC flag by default when opening files on Linux
6. The symbol-cli saves the config file as readable for others
7. Maximum packet size of 4GB may lead to denial-of-service attacks
8. Lack of overflow checks
9. The boost::filesystem::create_directory defaults to 0777 permissions
10. Potential padding oracle attack in AesCbcDecrypt
11. Incorrect ReceiptType in catapult-rest
A. Vulnerability Classifications
B. Compiler Mitigations
C. Fuzzing catapult-server
D. Previous security testing report fixes
E. Fix Log
Detailed Fix Log
F. Amendments to Voting Key Structure
G. Additional Symbol changes review
H. Fix log for issues from Appendix G
© 2020 Trail of Bits NEM Group Symbol Assessment | 1
Executive Summary
From June 13 through June 24, 2020, NEM Group engaged Trail of Bits to review the
security of the Symbol network’s node and REST gateway repositories. Trail of Bits
conducted this assessment over the course of four-person weeks with two engineers
working from the provided repositories.
In the first week of the assessment, we employed static analysis techniques such as
cppcheck, scan-build, CodeQL, and CLion code inspection while gaining a deeper
understanding of the codebase through manual review. Preliminary manual review
included potential generic classes of issues such as memory corruption, use of
cryptography, data validation, auditing/logging, configuration, and more. This led to the
discovery of six findings ranging from informational to high severity.
In the final week, we conducted a deeper analysis of the Symbol network, identifying critical
components within the system and pursuing testing against those targets. This led to the
discovery of several new issues ranging from informational to low severity. A partial review
of data flow and chain state validation revealed insufficient data validation issues related to
maximum packet sizes (T OB-SYM-007) and inflationary mosaic supply (T OB-SYM-008)
within the catapult server, and incorrect receipt types defined within the REST gateway
(T OB-SYM-011) . Further review of authentication schemes and access controls revealed
additional concerns regarding default permissions used with boost filesystem APIs
(T OB-SYM-009) .
Finally, a review of cryptography led to the discovery of a potential padding oracle attack
(T OB-SYM-010) . Trail of Bits engineers also began pursuing dynamic testing via l ibFuzzer
and various engines multiplexed via D eepState. Unfortunately, when we wished to employ
dynamic analysis, the fuzzing targets were often at a level of depth within the system that
required additional overhead for setup.
Overall, we believe the Symbol network repositories reviewed show positive consideration
for common classes of security vulnerabilities. As a result, low-hanging fruit seemed less
prevalent throughout the codebase, and static analysis techniques reflected few
true-positive concerns. Trail of Bits believes there may be latent data validation issues
deeper within the system that could be exposed through increased dynamic testing. We
recommend integrating a robust fuzzing harness such as A FL to test security properties
in-depth, while employing static analysis tools in the CI/CD build pipeline to uncover newly
introduced vulnerabilities and strengthen the system’s security posture.
Update September 24, 2020: Trail of Bits reviewed fixes implemented for the issues presented in
this report, amendments to voting key structure, and additional changes made to certain
repositories. See the results from those reviews in A ppendix E: Fix Log, A ppendix F: Amendments
© 2020 Trail of Bits NEM Group Symbol Assessment | 2
to Voting Key Structure, A ppendix G: Additional Symbol changes review, and H : Fix log for issues
from Appendix G.
© 2020 Trail of Bits NEM Group Symbol Assessment | 3
Project Dashboard
Application Summary
Name Symbol
Version catapult-server commit: f 84eb88727
catapult-rest commit: 2 5d62f2393
Type C++, JavaScript
Platforms Windows, Linux
Engagement Summary
Dates July 13–July 24, 2020
Method Whitebox
Consultants Engaged 2
Level of Effort 4 person-weeks
Vulnerability Summary
◼
Total High-Severity Issues 1
◼
Total Medium-Severity Issues 1
◼◼◼
Total Low-Severity Issues 3
◼◼◼
Total Informational-Severity Issues 3
◼◼◼
Total Undetermined-Severity Issues 3
◼◼◼◼◼◼◼◼◼◼◼
Total 11
Category Breakdown
◼◼
Access Controls 2
◼◼
Configuration 2
◼◼
Cryptography 2
◼◼◼
Data Validation 2
◼
Denial of Service 1
◼◼
Undefined Behavior 2
◼◼◼◼◼◼◼◼◼◼◼
Total 11
© 2020 Trail of Bits NEM Group Symbol Assessment | 4
Engagement Goals
This engagement was scoped to provide a security assessment of the previously
mentioned Symbol network components and their communications, namely the
catapult-server and c atapult-rest repositories.
Specifically, we sought to answer the following questions:
● Are there standard compiler and platform mitigations that could be leveraged to
improve the security posture of Symbol nodes?
● Do the provided repositories have code correctness issues that could lead to
memory corruption, arbitrary code execution, etc.?
● Are appropriate access controls set for sensitive information stored at rest?
● Do the target components make appropriate use of encryption to secure sensitive
information?
● Is the default configuration for the server overly permissive?
● Are there any insufficient data validation issues that may lead to a denial-of-service
attack? Could they be leveraged against the consensus model to take over the
network?
● Does logging result in sensitive data exposure? Could the logging system be
leveraged to perform a resource exhaustion attack?
Coverage
This section highlights some of the analysis coverage we achieved based on our high-level
engagement goals.
● Review of currently configured compiler mitigations revealed the need for additional
mitigations that would help prevent an attack against the server. (T OB-SYM-001) .
● In analyzing the codebase for generic classes of vulnerabilities such as memory
corruption, use-after-frees, arbitrary code execution, and more, we discovered an
issue dereferencing a potentially invalid pointer (T OB-SYM-002) and a lack of
overflow checks (T OB-SYM-008) .
● While investigating the use of cryptography in the system, we discovered a
potentially cryptographically insecure RNG (T OB-SYM-004) and a potential padding
oracle attack (T OB-SYM-010) . We also found some positive reinforcements, including
appropriate wrapping of dependencies like OpenSSL and proper implementation of
EdDSA.
● Review of various file operations revealed permission-based concerns
(T OB-SYM-005, T OB-SYM-006, T OB-SYM-009) .
© 2020 Trail of Bits NEM Group Symbol Assessment | 5
● Default server configurations related to authentication were found to be sufficient.
For example, by default, only machine-local connections are allowed, and the
maximum ban list size is fairly large.