When the VaultAuthority is reset, malicious actors can seize control of the VaultAuthority permissions.
Summary
When the vault calls the reset_vault function to delete and requires reinitialization, the original logic states that the owner of oapp_config needs to call reinit_vault to reinitialize the vault. However, due to the lack of any external record, malicious actors can preemptively transact and call init_vault to initialize the vault, seizing control of the vault's ownership.
Admin need to call reset_vault function to re-init vault
External pre-conditions
None
Attack Path
Attacker call init_vault function to get vault ownership and prevent oapp_config owner re-init vault.
Impact
The vault account may be manipulated by the user, allowing them to gain privileges such as set_order_delivery.
For example, if the bridge needs to execute messages in an unordered manner for some reason, but a malicious actor sets the bridge to execute messages in an ordered manner, it could lead to a denial of service (DoS) in the system.
PoC
No response
Mitigation
Add a field to the oapp_config to distinguish whether the VaultAuthority has already been initialized.
Brisk Felt Lark
High
When the VaultAuthority is reset, malicious actors can seize control of the VaultAuthority permissions.
Summary
When the vault calls the reset_vault function to delete and requires reinitialization, the original logic states that the owner of oapp_config needs to call reinit_vault to reinitialize the vault. However, due to the lack of any external record, malicious actors can preemptively transact and call init_vault to initialize the vault, seizing control of the vault's ownership.
Root Cause
The root cause of this issue is the lack of any external records to distinguish whether the vault is being reinitialized or initialized for the first time. This problem does not occur with oapp_config, as it requires registration with the LayerZero protocol during the first initialization. https://github.com/sherlock-audit/2024-09-orderly-network-solana-contract/blob/main/solana-vault/packages/solana/contracts/programs/solana-vault/src/instructions/vault_instr/init_vault.rs#L12 https://github.com/sherlock-audit/2024-09-orderly-network-solana-contract/blob/main/solana-vault/packages/solana/contracts/programs/solana-vault/src/instructions/vault_instr/reinit_vault.rs#L10
Internal pre-conditions
Admin need to call reset_vault function to re-init vault
External pre-conditions
None
Attack Path
Attacker call init_vault function to get vault ownership and prevent oapp_config owner re-init vault.
Impact
The vault account may be manipulated by the user, allowing them to gain privileges such as set_order_delivery.
For example, if the bridge needs to execute messages in an unordered manner for some reason, but a malicious actor sets the bridge to execute messages in an ordered manner, it could lead to a denial of service (DoS) in the system.
PoC
No response
Mitigation
Add a field to the oapp_config to distinguish whether the VaultAuthority has already been initialized.