Summary
Orbit - a top Internet Computer based multi-approver governance platform for multichain assets - was recently assessed by Trail of Bits, a leading technical security auditor operating as a center of excellence for blockchain security. To learn more about Orbit, see the Medium post and Orbit on GitHub.
The new report can be found here, along with a list of all previous third-party audits.
The finding breakdown is as follows:
Many issues have been addressed and went through a fix review. 1 high and 2 medium were resolved, 1 high was partially resolved. See the fix review results in Appendix E of the report.
We’d like to thank the Trail of Bits team for their excellent contributions, the audit and security-related recommendations, and the effective collaboration.
Discussion Leads
Happy to discuss and answer any questions you may have. The people at DFINITY who were most involved and can be tagged for questions are @robin-kunzler (Security) and @aterga (Orbit).
Previous Forum Discussions about Security Assessments
6 Likes
Could you elaborate just a little bit on this point - why only partially resolved? I’m struggling to view the whole report on mobile.
Found the context.
Asset edit requests allow users to change asset data such as the asset name, symbol, token
standards, and other metadata. This allows privileged users to arbitrarily rename asset
types. For example, a user who can edit asset data can swap the asset names for ckBTC to
ckETH, which could cause other users to confuse the two assets with each other.
The severity of this issue is rated as high because it could lead to significant financial
for affected users. On the other hand, the difficulty is also rated as high because the ab
to edit asset metadata assumes a high level of privilege within the system.
Exploit Scenario
Eve, a malicious Orbit user, tricks an administrator into swapping the names and symbols
of ckBTC and ckETH using the issue described in TOB-ORBIT-14. She then asks Bob, another
Orbit user, to transfer one ckETH to an address controlled by Eve. Since the two assets’
names and symbols have been swapped, Bob transfers one ckBTC instead of one ckETH to
Eve by mistake, losing 91,000 USD in the process.
Recommendations
Short term, prevent all users from editing the assets from the initial list of known assets,
and prevent users from introducing custom assets with names or symbols that correspond
to known assets. This would protect metadata associated with well-known assets from
being manipulated by malicious users.
Long term, consider validating ICRC-1 token metadata against the corresponding ledger to
ensure it matches what is reported by the ledger before allowing users to add the asset
type to their Orbit accounts. Care must be taken when checking token metadata against
third-party ledgers since these can return unexpected or invalid responses.
Would be good to know more about the partial resolution, and the associated risk of publishing this potential attack vector.
It’s an interesting one, because presumably users should be able to name the assets. It’s not going to be possible to validate the appropriateness of all names, so I’m not sure I agree with the recommendation.
Hi @Lorimer ,
Thanks for looking into this!
Let me explain why this is marked partially resolved (see TOB-ORBIT-18 in the Fix Review Results in Appendix E):
- What is addressed? TOB-ORBIT-14 (high risk, resolved) made it really easy to miss and be tricked into approving an asset name change (e.g. “ckBTC” to “ckETH”) because the UI only showed the new value “ckETH” when reviewing and approving the proposed changes. To fix TOB-ORBIT-14, the UI now displays a clear diff between the old and new value, explicitly highlighting a change from “ckBTC” to “ckETH”. This makes it significantly less likely that an approver could be tricked into approving such a malicious change.
- What has not been addressed? (Reason for “partially resolved”) The recommendation suggests further mitigations which we currently have not implemented:
- Short term suggestion: We don’t currently prevent users from editing an initial list of known asset names. One could consider this to further decrease the likelihood of such an attack.
- Long term suggestion: We don’t currently check asset names against the names provided by the ICRC-1 ledgers. One could consider this and e.g. display a clear warning to the approver if there is a name mismatch.
I think the suggestions make sense and we can still consider implementing them in the future. We decided to not implement those at this point due to the engineering effort. We think displaying a clear diff to the user (TOB-ORBIT-14) significantly reduces the risk and the residual risk is currently acceptable.
Let me know if you have any further questions regarding the review and the report!
4 Likes