Secret Vault on Aptos

Description

The set_secret() function in the SecretVault module lacks proper access control validation, allowing any account to set or override secrets. While the contract documentation explicitly states that "Only the owner should be able to store a secret and then retrieve it later", the implementation permits any caller to invoke this function and store secrets under their own account, violating the intended security model.

Root Cause

The function accepts any &signer without validating that the caller is the authorized owner (@owner). The function is designed to be called only by the contract owner, but no access control mechanism is implemented to enforce this restriction, allowing any account to invoke it.

Key issues:

1. No validation that caller is the contract owner (@owner)

2. Any account can call set_secret() and store secrets under their own address

3. Multiple accounts can have their own vault resources, breaking the intended single-vault design

Risk

Likelihood: High - Any account can trivially call this public function without restrictions

Impact: High - Complete bypass of the intended access control model, allowing unauthorized secret storage

Impact

High severity because:

• Breaks the fundamental security assumption that only the owner can manage secrets

• Violates the Move ownership model by allowing unauthorized resource storage

Proof of Concept

The following test demonstrates how any attacker account can successfully set secrets without being the owner:

Recommended Mitigation

Implement access control by adding an assertion to verify the caller is the authorized owner:

Test Results After Mitigation:

This fix ensures that only the designated owner (@owner) can invoke the set_secret() function, properly enforcing access control and maintaining the security guarantees of the vault system. The @owner address must be specified during deployment.