Penetration Test Report (TrailOfBits): CasperLabsHighwayProtocol

CasperLabs Highway Protocol
Security Assessment
December 1 , 2 020
Prepared For:
Andreas Fackler | C asperLabs
andreas@casperlabs.io
Medha Parlikar | C asperLabs
medha@casperlabs.io
Prepared By:
Fredrik Dahlgren | T rail of Bits
fredrik.dahlgren@trailofbits.com
Jim Miller | T rail of Bits
jim.miller@trailofbits.com
David Pokora | T rail of Bits
david.pokora@trailofbits.com
Will Song | T rail of Bits
will.song@trailofbits.com
Changelog:
December 1, 2020: Initial draft
January 8, 2021: Finalized draft with fix log
Executive Summary
Project Dashboard
Engagement Goals
Coverage
Recommendations Summary
Short Term
Long Term
Findings Summary
1. LNC validation not implemented
2. Peers are not punished for sending invalid vertices
3. Insufficient rate limiting mechanism
A. Vulnerability Classifications
B. Recommendations for Documentation
C. Recommendations for Code Quality
D. Fix Log
Detailed Fix Log
© 2020 Trail of Bits CasperLabs Highway Protocol Assessment | 1
Executive Summary
From November 16 to December 1, 2020, Trail of Bits performed an assessment of
CasperLabs’ Highway consensus protocol. Trail of Bits performed this assessment working
from commit hash 4 0a573e of the c asper-node repository.
Trail of Bits engineers used the first week to familiarize themselves with the provided
protocol paper for Highway, deriving security properties to verify within the codebase.
Preliminary manual review was conducted against the provided implementation in search
of issues regarding improper authentication, insufficient data validation, denial of service,
and undefined behavior. A non-exhaustive list of initial concerns included verification of
signatures against creators for wire units, validating endorsement logic, review of leader
selection, and improperly handled u nwrap calls that may lead to panics. This resulted in
one preliminary finding (T OB-CLHW-001) and several documentation recommendations
detailed within A ppendix B.
In the final week, Trail of Bits validated remaining concerns regarding malicious validator
banning/slashing mechanisms, state transitions, resource exhaustion attacks, and triaging
concerns from the previous week. This resulted in two additional findings (T OB-CLHW-002,
TOB-CLHW-003) , documentation recommendations, and a code quality recommendation
listed within A ppendix C.
Overall, Trail of Bits’ investigation into the Highway protocol did not produce high severity
results and showed proper use of security hygiene. Moving forward, we recommend
improving the protocol paper for clarity and employing the use of fuzz tests to discover any
potential deep-rooted data validation issues in the implementation. Additionally, we
recommend testing denial of service attacks against the network and individual nodes in
practice, as time did not permit us to conduct these tests in depth during the course of the
assessment.
© 2020 Trail of Bits CasperLabs Highway Protocol Assessment | 2
Project Dashboard
Application Summary
Name Highway Protocol
Version 40a573e
Type Rust, PDF
Platforms UNIX
Engagement Summary
Dates November 16 - December 1, 2020
Method Whitebox
Consultants Engaged 4
Level of Effort 4 person-weeks
Vulnerability Summary
Total Low-Severity Issues 2 ◼◼
Total Informational-Severity Issues 1 ◼
Total 3
Category Breakdown
◼
Data Validation 1
◼◼
Denial of Service 2
Total 3
© 2020 Trail of Bits CasperLabs Highway Protocol Assessment | 3
Engagement Goals
The engagement was scoped to provide a security assessment of the Highway protocol
paper and corresponding Rust implementation within the c asper-node repository.
Specifically, we sought to answer the following questions:
● Will misbehaving validators be punished?
● Is the system prone to a resource exhaustion attack?
● Are units appropriately validated before being appended to state?
● Are signed wire units appropriately signed/verified?
● Can an attacker game the system such that they are selected as the next leader?
● Is LNC validation appropriately implemented? Is the buffer mechanism for LNC
validators appropriate?
Coverage
This section highlights some of the analysis coverage we achieved based on our high-level
engagement goals.
● Differential review of the protocol paper against the implementation revealed some
inconsistencies (T OB-CLHW-001, A ppendix B) .
● Analysis of the signature scheme used for wire units ensured the signature was
validated against the creator’s keypair.
● Partial coverage of leader selection did not yield any immediate concern. There was
emphasis on ensuring that an attacker could not control leader selection. We
considered if an attacker could control or influence the weights map or random
seed, they may have been able to influence leader selection, however we did not
determine an avenue for such an attack.
● Review of the data validation performed on units prior to any state changes
generally yielded positive results, although we made recommendations regarding
the handling of invalid vertices (T OB-CLHW-002) .
● General review of code correctness did not yield any findings. Initial concerns
involved suspected potential panics which could be triggered by failed calls prior to
an u nwrap o peration.
● Employment of static analysis tooling did not reveal any concerns.
● A review of rate limiting capabilities with respect to units led to a broad concern for
denial of service attacks via non-unit type messages (T OB-CLHW-003) .
© 2020 Trail of Bits CasperLabs Highway Protocol Assessment | 4
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
❒
Implement LNC validation as specified within the Highway protocol paper.
TOB-CLHW-001
❒
Consider rate limiting or otherwise penalizing the sender and disconnecting from
them in the event of invalid vertices being sent. T OB-CLHW-002
❒
Consider flagging users who have sent invalid messages to be restricted at the
receiving socket before pushing subsequent messages into the queue. T OB-CLWHW-003
Long Term
❒
Review all code locations regarding failed data validation to deduce if the sender
should be rate limited or otherwise penalized. This will disincentivize peers from further
malicious acts.
© 2020 Trail of Bits CasperLabs Highway Protocol Assessment | 5
Findings Summary
# Title Type Severity
1 LNC validation not implemented Data Validation Informational
2 Peers are not punished for invalid Denial of Low
vertices Service
3 Insufficient rate limiting mechanism Denial of Low
Service
© 2020 Trail of Bits CasperLabs Highway Protocol Assessment | 6
1. LNC validation not implemented
Severity: Informational Difficulty: Undetermined
Type: Data Validation Finding ID: TOB-CLHW-001
Target: n ode/src/components/consensus/highway_core/state.rs
Description
The current iteration of the Highway protocol does not support LNC validation as it is
defined in the protocol paper.
Verification of LNC is important for units in order to ensure that the amount of
equivocation votes contained in any message downset is limited. This in turn helps protect
against malicious behavior such as equivocation bombs.
The impact of this finding has not been determined during the course of this assessment.
As such, there may be alternate mitigations in place to prevent any such attacks.
Recommendation
Implement LNC validation as specified within the Highway protocol paper.
© 2020 Trail of Bits CasperLabs Highway Protocol Assessment | 7
2. Peers are not punished for sending invalid vertices
Severity: Low Difficulty: Medium
Type: Denial of Service Finding ID: TOB-CLHW-002
Target: n ode/src/components/consensus/era_supervisor.rs
Description
The Highway protocol considers messages within the network as vertices within a graph.
When processing incoming vertices with the a dd_vertices function, validation is
performed upon initial receipt and after initial pr