Potential Security Vulnerability in `claim_unbond_public` Method - Unauthorized Claim and Incomplete Transaction Records
🐛 Bug Report
Summary
A potential security vulnerability has been identified and confirmed in the credits.aleo contract, specifically in the claim_unbond_public method. The current implementation lacks proper permission checks, allowing unauthorized addresses to claim unbonded funds and leading to incomplete transaction records.
Description
The claim_unbond_public method's finalize function currently only includes the staker address as a parameter, omitting the caller address. This implementation differs from other methods like unbond, where the caller address is passed to the finalize function, allowing explorers to capture this information.
Current implementation:
finalize claim_unbond_public:
// Input the staker's address.
input r0 as address.public;
// Get the unbond state for the address, or fail if it does not exist.
get unbonding[r0] into r1;
// ...
// Current implementation
This discrepancy creates several critical issues:
-
Lack of Permission Checking: Without the
calleraddress, it's impossible to verify if the person initiating theclaim_unbond_publicis actually authorized to do so. -
Unauthorized Claim of Unbonded Funds: Any address can successfully call the
claim_unbond_publicfunction and claim unbonded funds for any staker. -
Incomplete Explorer Transaction Records: Aleo explorers cannot capture the full transaction details, specifically the caller and withdrawal addresses, making it difficult to track fund movements triggered by
claim_unbond_public. -
Inconsistent Balance Changes: The withdrawal address receives funds without any corresponding transaction record, making it appear as if the balance increased out of thin air.
Steps to Reproduce
We have confirmed this vulnerability on the testnet with the following scenario:
- Staker address:
aleo1uqv7a3gggcs4ktc5q7m65628mje9vha0qdya49ktudxj5qkjdsyq9dqrnv - Withdrawal address:
aleo10knhj6n6pe769gnu3vuuq2x7pxqlkc38trkj2u3ezhc08u84yyrq5u9u47 - Unrelated address:
aleo1yvx2sl4p85lj83lk27x856grunzeusk3wvqnych9p3tx0w6gtqqq5t7u6s
Steps to reproduce:
- Completed the unbond operation with the withdrawal address.
- Waited for more than 360 blocks to pass.
- Successfully called the
claim_unbond_publicfunction using the private key of the unrelated address.
Results:
- The unbonded funds were transferred to the withdrawal address.
- All relevant mappings for this function were cleared.
- The
claim_unbond_publicexecution record appeared in the staker's address history. - No transition records appeared for either the withdrawal address or the unrelated address that initiated the claim.
- The balance increase in the withdrawal address appeared to occur without any corresponding transaction.
Potential Impact
- Unauthorized claiming of unbonded funds by any address
- Severe inaccuracies in Aleo explorer statistics and transaction histories
- Difficulty in auditing and tracking fund movements
- Potential for large-scale exploitation by malicious actors
Suggested Fix
Modify the claim_unbond_public method to include both the caller and staker addresses in its finalize function, and implement proper authorization checks.
This change would allow for proper permission checking, ensuring that only the authorized withdrawal address can claim unbonded funds. It would also enable complete transaction recording, accurately reflecting fund movements in Aleo explorers.
Additional Notes
- This vulnerability has been confirmed on the testnet and poses a significant risk if present on the mainnet.
- The current implementation severely undermines the security model of the staking and unbonding process.
- The current Aleo explorers data mostly relies on information from the
finalizepart of transitions, making this omission particularly problematic for transparency and security. - Immediate action is required to prevent potential exploitation.
Thank you for your time and dedication to maintaining the security and reliability of the Aleo ecosystem. If you need any clarification or additional information, please don't hesitate to reach out. I look forward to your response and am hopeful that together we can address this potential vulnerability.