Prepared by:
HALBORN
Last Updated 06/27/2025
Date of Engagement: December 23rd, 2024 - January 10th, 2025
100% of all REPORTED Findings have been addressed
All findings
2
Critical
0
High
0
Medium
0
Low
0
Informational
2
Ripple
engaged Halborn to conduct a security assessment on XRP Ledger (XRPL) feature amendments, beginning on December 23rd, 2024 and ending on January 10th, 2025. The security assessment was scoped to the features provided to the Halborn
team.
Commit hashes and further details can be found in the Scope section of this report.
The Permissioned Domains feature introduced a new transaction type and structures to allow the creation of domains whitelisting specific credential bearers to send and receive transactions within that permissioned domain.
The team at Halborn
assigned a full-time security engineer to assess the security of the node. The security engineer is a blockchain and smart-contract security expert with advanced penetration testing, smart-contract hacking, and deep knowledge of multiple blockchain protocols.
The purpose of this assessment is to:
Ensure that the new features operate as intended.
Identify potential security issues with the new features.
In summary, Halborn identified some improvements to reduce the likelihood and impact of risks, which were acknowledged by the Ripple team
:
Improve the error handling.
Mind of unaccepted and expired credentials when implementing additional Permissioned Domain features.
Halborn
performed a combination of manual review of the code and automated security testing to balance efficiency, timeliness, practicality, and accuracy in regard to the scope of the node security assessment. While manual testing is recommended to uncover flaws in logic, process, and implementation; automated testing techniques help enhance coverage and can quickly identify items that do not follow security best practices. The following phases and associated tools were used throughout the term of the assessment:
Research into the architecture, purpose, and use of the platform.
Manual code review and walkthrough to identify any logic issue.
Graphing out functionality and contract logic/connectivity/functions.
EXPLOITABILITY METRIC () | METRIC VALUE | NUMERICAL VALUE |
---|---|---|
Attack Origin (AO) | Arbitrary (AO:A) Specific (AO:S) | 1 0.2 |
Attack Cost (AC) | Low (AC:L) Medium (AC:M) High (AC:H) | 1 0.67 0.33 |
Attack Complexity (AX) | Low (AX:L) Medium (AX:M) High (AX:H) | 1 0.67 0.33 |
IMPACT METRIC () | METRIC VALUE | NUMERICAL VALUE |
---|---|---|
Confidentiality (C) | None (I:N) Low (I:L) Medium (I:M) High (I:H) Critical (I:C) | 0 0.25 0.5 0.75 1 |
Integrity (I) | None (I:N) Low (I:L) Medium (I:M) High (I:H) Critical (I:C) | 0 0.25 0.5 0.75 1 |
Availability (A) | None (A:N) Low (A:L) Medium (A:M) High (A:H) Critical (A:C) | 0 0.25 0.5 0.75 1 |
Deposit (D) | None (D:N) Low (D:L) Medium (D:M) High (D:H) Critical (D:C) | 0 0.25 0.5 0.75 1 |
Yield (Y) | None (Y:N) Low (Y:L) Medium (Y:M) High (Y:H) Critical (Y:C) | 0 0.25 0.5 0.75 1 |
SEVERITY COEFFICIENT () | COEFFICIENT VALUE | NUMERICAL VALUE |
---|---|---|
Reversibility () | None (R:N) Partial (R:P) Full (R:F) | 1 0.5 0.25 |
Scope () | Changed (S:C) Unchanged (S:U) | 1.25 1 |
Severity | Score Value Range |
---|---|
Critical | 9 - 10 |
High | 7 - 8.9 |
Medium | 4.5 - 6.9 |
Low | 2 - 4.4 |
Informational | 0 - 1.9 |
Critical
0
High
0
Medium
0
Low
0
Informational
2
Security analysis | Risk level | Remediation Date |
---|---|---|
Lack of error handling | Informational | Acknowledged - 02/13/2025 |
Expired and non accepted credentials could be part of the domain | Informational | Acknowledged - 02/13/2025 |
//
When creating a permissioned domain via the PermissionedDomainSet
transaction, the creator needs to pass an array of credential objects to the transaction. This array is validated against duplicates during the preliminary verifications, and used to construct the permissioned domain object in a second part.
During the permissioned domain object creation, the function iterates through each credential objects of the parameters and inserts them in a map. If the object is already present, an empty map would be returned. While the code is in this state protected against duplicates due to the aforementioned verification, it would gain to be more robust and return an error instead of an empty map to handle codebase updates without potential bugs.
src/xrpld/app/misc/CredentialHelpers.cpp
: the following snippet shows the aforementioned preliminary verification, ensuring that the credential array does not contain duplicates.
auto [it, ins] = duplicates.insert(sha512Half(issuer, ct));
if (!ins)
{
JLOG(j.trace()) << "Malformed transaction: "
"duplicates in credenentials.";
return temMALFORMED;
}
src/xrpld/app/misc/CredentialHelpers.cpp
: the function returns an empty map if a duplicate is found, and could be improved by returning an error.
std::set<std::pair<AccountID, Slice>>
makeSorted(STArray const& credentials)
{
std::set<std::pair<AccountID, Slice>> out;
for (auto const& cred : credentials)
{
auto [it, ins] = out.emplace(cred[sfIssuer], cred[sfCredentialType]);
if (!ins)
return {};
}
return out;
}
src/xrpld/app/tx/detail/PermissionedDomainSet.cpp
: the permissioned domain object creation invokes the above function, not checking for empty content either.
TER
PermissionedDomainSet::doApply() // @note apply the transaction to the ledger
{
// @note not sure the need to check if the ownerSle exists since
// it's initialized in the transactor
auto const ownerSle = view().peek(keylet::account(account_));
if (!ownerSle)
return tefINTERNAL; // LCOV_EXCL_LINE
auto const sortedTxCredentials =
credentials::makeSorted(ctx_.tx.getFieldArray(sfAcceptedCredentials));
STArray sortedLE(sfAcceptedCredentials, sortedTxCredentials.size());
for (auto const& p : sortedTxCredentials)
{
auto cred = STObject::makeInnerObject(sfCredential);
cred.setAccountID(sfIssuer, p.first);
cred.setFieldVL(sfCredentialType, p.second);
sortedLE.push_back(std::move(cred));
}
It is recommended to return an error instead of an empty map.
ACKNOWLEDGED: The Ripple team acknowledged this finding.
//
The permissioned domain object contains a list of credentials objects with only the credential_type
and the issuer
fields set. This allows anyone is possession of matching credentials to be part of the domain. Expired credentials are not automatically deleted from the subject account if no transactions occur, and even non-accepted credentials could be possibly accepted as part of the domain without the subject approval either.
This would allow, depending on the PermissionedDomain further implementation, to perform unauthorized actions on the subject. At the time of the assessment, this feature was still under development and this finding does not report an actual vulnerability, rather a suggestion for future development.
src/xrpld/app/tx/detail/PermissionedDomainSet.cpp
: the following snippets show that accepted credentials are using sfIssuer
and sfCredentialType
as only filters.
STArray sortedLE(sfAcceptedCredentials, sortedTxCredentials.size());
for (auto const& p : sortedTxCredentials)
{
auto cred = STObject::makeInnerObject(sfCredential);
cred.setAccountID(sfIssuer, p.first);
cred.setFieldVL(sfCredentialType, p.second);
sortedLE.push_back(std::move(cred));
}
It is recommended to mind the expirations and non-acceptance of credentials for the upcoming implementations using the PermissionedDomains.
ACKNOWLEDGED: The Ripple team acknowledged this finding.
Halborn strongly recommends conducting a follow-up assessment of the project either within six months or immediately following any material changes to the codebase, whichever comes first. This approach is crucial for maintaining the project’s integrity and addressing potential vulnerabilities introduced by code modifications.
// Download the full report
Ripple - Smart Contract Audit - Permissioned Domains
* Use Google Chrome for best results
** Check "Background Graphics" in the print settings if needed