The get_secret
function is intended to restrict access to the stored secret so that only the owner can retrieve it. While the function contains a check to verify whether the caller matches the owner, the caller parameter is supplied directly by the external caller. This means the function does not validate the identity of the transaction sender (signer) but instead trusts a freely user-supplied address. As a result, an attacker can pass the owner’s address as the caller and gain full read access to the stored secret.
The access control relies on a parameter that can be manipulated by the user, instead of deriving the address from the signer or validating ownership based on authenticated transaction context.
Likelihood - High
The function is publicly callable and the caller argument can be freely set by any user at call time.
No on-chain mechanism enforces that the supplied caller is tied to the caller’s signer account.
The vulnerability can be exploited immediately and remotely without any prerequisites such as prior access or special roles.
Impact - High
Unauthorized disclosure of sensitive secret data from any vault.
Complete loss of confidentiality for all stored secrets, as any attacker can retrieve any user’s vault content.
The following PoC, which can be added to the secret_vault::vault module, demonstrates how a malicious user can retrieve the owner’s secret without authorization and can be used to verify the issue.
Execution Output:
Remove the caller argument from the get_secret
function and instead derive the caller’s address from the &signer
parameter.
Implement the access control check using authenticated transaction context:
The contest is live. Earn rewards by submitting a finding.
This is your time to appeal against judgements on your submissions.
Appeals are being carefully reviewed by our judges.