Root + Impact

Description

• Intended behavior: Only the owner is allowed to store a secret and later retrieve it. No other account should be able to access the secret.

• Actual behavior (bug): The get_secret function authorizes by comparing a user-supplied address to the named address @owner instead of authenticating the actual caller (no &signer is used). As a result, any account can pass the owner’s address as the argument and read the owner’s secret.

Why this is exploitable:
Authentication is based on what argument the caller supplies, not on who is calling. Because the owner’s address is publicly knowable after deployment (named addresses are bound into published bytecode and visible on-chain), any user can call get_secret(owner_addr) and obtain the secret.

Risk

Likelihood:

• The function is public #[view] and callable by any account; no privilege is required.

• The owner’s on-chain address is observable after deployment (e.g. via explorer), so the required parameter value is trivially discoverable.

Impact:

• Direct disclosure of the owner’s secret, violating the core requirement (“Only the owner should be able to store a secret and then retrieve it later”).

• Irreversible data breach: once read, the secret cannot be “unseen”; redeploying does not mitigate prior leakage.

Proof of Concept

The unit test creates two accounts (owner and attacker, the attacker parameter is present only to emphasize roles; it’s not required for the unit test to pass).

The owner stores a secret via set_secret. The exploit then calls get_secret(owner_addr) and succeeds because the function authorizes by the user-supplied address parameter instead of the actual caller (&signer).

The final assert verifies that the value returned by get_secret equals the original secret, confirming an unauthorized read by any caller who passes owner_addr.

Recommended Mitigation

Authenticate the actual caller via &signer (and keep storage/reads bound to @owner).