Vulnerability to first depositor pool frontrunning attack in PSM deployment

[c4-bot-3]

Lines of code

https://github.com/code-423n4/2023-12-ethereumcreditguild/blob/main/test/proposals/gips/GIP_0.sol#L25

Vulnerability details

high

Impact

The GIP_0 contract, which is responsible for the deployment of the system, is expected to mint 100e18 gUSDC before anyone interacts with the protocol. This is a crucial step as it prevents share price manipulation as pointed out in the contest documentation. However, it appears that these tokens are not being minted by the deployment script. This omission makes the deployed PSM vulnerable to a first depositor pool frontrunning attack.

https://github.com/code-423n4/2023-12-ethereumcreditguild/blob/main/test/proposals/gips/GIP_0.sol#L25

In a first depositor pool frontrunning attack, an attacker could potentially manipulate the price of the token by being the first to interact with the protocol. This could lead to significant financial loss for other users and could undermine the integrity of the entire system.

Proof of Concept

In the current implementation, the deploy() function of the GIP_0 contract does not include a step to mint 100e18 gUSDC tokens. An attacker could exploit this by being the first to interact with the protocol after deployment, potentially manipulating the price of the token.

Here is a simplified sequence of events illustrating the issue:

1. The GIP_0 contract is deployed, but the 100e18 gUSDC tokens are not minted.
2. Alice, an attacker, is the first to interact with the protocol.
3. Alice manipulates the price of the token to her advantage.
4. Bob, an honest user, interacts with the protocol after Alice, and suffers financial loss due to the manipulated token price.

Tools Used

Manual review

Recommended Mitigation Steps

To mitigate this issue, ensure that the 100e18 gUSDC tokens are minted by the deployer address during the deployment process. This could be achieved by adding a minting step to the deploy() function of the GIP_0 contract. It's also recommended to add tests to verify that the tokens are correctly minted during deployment.

Assessed type

Other

[c4-pre-sort]

0xSorryNotSorry marked the issue as sufficient quality report

[c4-pre-sort]

0xSorryNotSorry marked the issue as primary issue

[c4-pre-sort]

0xSorryNotSorry marked the issue as duplicate of #179

[c4-judge]

Trumpero marked the issue as unsatisfactory: Invalid