Read the findings of the 2022 Web3 Security Report

A new escrow can be created via the `EscrowInit` instruction. 
Inside `EscrowInit`, if the escrow data account has not been created yet, a new escrow account will be created using system instructions.
The concern is that the current codebase did not handle the condition that the escrow account already existed. 
Because the escrow data account is owned by the escrow program and the seed `escrow_vault_word` for PDA creation does not include initiator and validator public keys,
anyone can modify the data in an existing escrow account using `EscrowInit` instruction, even if the `active` filed has already set to `true`.

One potential exploit scenario:
1. Alice creates an escrow as a buyer and deposits the lamports to the escrow account.
2. Attacker invokes `EscrowInit` instruction (using the same seed) to change the initiator to himself.
3. Attacker invokes `InitiatorWithdraw` to get the funds.

Unhandled `else` Branch and PDA Seed Concern

In the escrow program, the role `admin` has authority over the following instructions:

- `AdminWithdraw` will allow the admin to move all deposit lamports to the specified `to` account, send only the rent back to the initiator, and close the escrow account.
- `SPLAdminWithdraw` will allow the admin to move all deposit tokens to the specified `to` account, send only the rent back to the initiator, and close the escrow account.
- `AddToWhitelist` will create a whitelist account for a specific mint.

The admin account is hardcoded with **5xTMmKS5ZDXCBwogZF2tqtfmHpdyfUCVSMpg34TKHVjU** in the audited codebase.

Any compromise to the `admin` account may allow a hacker to take advantage of this authority, for example, moving funds from any escrow account.

Additionally, if the program is upgradeable, the upgrade authority account can change the program content, thus causing unexpected consequences. The upgrade authority should also be carefully managed.

Centralization Related Risks

In the escrow program, when the initiator is the seller(`is_initiator_buyer==False`), it allows the buyer(validator) to negotiate the price using `UpdateEscrowAmount` or `SPLUpdateEscrowAmount`.
In the `UpdateEscrowAmount`, the validator will deposit lamports or tokens, and most importantly `is_initiator_buyer` will be set to `true`.
This will result in a role change to ensure that the escrow works correctly afterwards. 
The original validator will become the new initiator and the original initiator will be the validator.
This will lead to a rent refund to the wrong role when closing the escrow account.
We plotted the potential workflow graph as follows, and **the admin operation(`AdminWithdraw/SPLAdminWithdraw`) which is not shown in the graph would also hold the same issue**:

![](https://pic-base.s3.us-east-2.amazonaws.com/img/vaultx-workflow.png)


Moreover, due to `is_initiator_buyer` switched to `true`, it will allow attackers to gain rent in an account for free when the initiator is the seller. One possible exploit scenario is described below.

While creating an escrow as a seller, the initiator, say A, would have to pay the `required_lamports` rent for the `escrow_data_info` account.
Now assuming that the validator, say B, adversarially updates the escrow to an extremely low proposal using `UpdateEscrowAmount`, which A will not accept and validate. 
In this situation, B is able to withdraw the `required_lamports` in the `escrow_data_info` account (which was paid by A) by calling the `InitiatorWithdraw()` or `SPLInitiatorWithdraw()` function, because B is switched to the initiator role after the update.
Hence, the initiator A suffers a `required_lamports` loss in an unsuccessful escrow deal.


Potential Rent Loss Due to Adversarial Update

When creating an SPL escrow, the whitelist validation should be implemented to avoid invalid mint.
In the current codebase, the validation is performed only when `deposit > 0`.
Therefore, an invalid escrow account could be created when `deposit==0`


Lack of Whitelist Validation When `deposit == 0`

Throughout the project, customized error codes (e.g., `0x108` and `0x109`) are used to indicate a program error.
However, the same error code is used for different program errors (though they may semantically similar).
For example, when `escrow_data.is_initiator_buyer` in L233 and `escrow_data.buyer!=*validator.key` in L242, 
the same error code `0x109` is returned. 

Unclear Error Code

The escrow program interacts with the following `System Program` but lacks validations which could cause unexpected program behaviors:
- `system_program_account` should equal to `11111111111111111111111111111111`

Lack of Input Validation on `System Program`

The instruction `AddToWhitelist` will be used when registering a whitelisted mint account. 
In the current codebase, the mint account is lacking owner validation.

Lack of Owner Check for Mint Account

Checked math is not used in any mathematical operations throughout the whole codebase, which could potentially result in overflow and underflow issues.

Potential Overflow/Underflow

When an SPL escrow is approved, the SPL escrow data account will be closed.
In the current codebase, the associated token account for the SPL escrow data account will not be closed, due to the seed(`escrow_vault_word`) being reusable, another user may recreate the SPL escrow account with the same address and use the associated token account without creation.



Discussion on Unclosed Token Account

Vaultxcrypto2022

lib.rs

Vault-X

Vault-X

Highlights & Alerts

This is just a placeholder

highlight placeholder lorem Ipsum...

highlight lorem

This is a alert demo

Alert demo

Code Audit History

9

0

2

0

7