Zero Shares Acquisition Vulnerability in GSPFunding.sol Due to Front-Running
Summary
In the GSPFunding.sol contract, the buyShares function is vulnerable to a front-running attack that can result in users receiving zero shares despite supplying a significant amount of base and quote tokens. This vulnerability stems from the ability of any user to call the sync function in GSPVault.sol, which synchronizes the reserves with the current token balances.
Vulnerability Detail
The buyShares function calculates the number of shares to be allocated to a user based on the difference between the current token balances and the stored reserves (_BASE_RESERVE and _QUOTE_RESERVE). However, an attacker can front-run a user's buyShares transaction by calling the sync function, which updates the reserves to match the current balances. This results in the user's transaction seeing no difference between the reserves and the current balances, leading to zero shares being allocated.
Impact
This vulnerability can be exploited to prevent legitimate users from acquiring shares in the pool, despite depositing their tokens. It undermines the fairness and functionality of the share distribution mechanism, potentially leading to loss of trust and reduced participation in the pool.
Rewrite buyShares function. Approve current contract to spend tokens of behalf of msg.sender. Transfer from msg.sender needed amount of both tokens. And based on this amounts calculate shares
Invalid, similar to #78 comments here, buyShares() is meant to be executed via the proxy, where the corresponding recommendation has already been implemented
mike-watson
high
Zero Shares Acquisition Vulnerability in
GSPFunding.sol
Due to Front-RunningSummary
In the
GSPFunding.sol
contract, thebuyShares
function is vulnerable to a front-running attack that can result in users receiving zero shares despite supplying a significant amount of base and quote tokens. This vulnerability stems from the ability of any user to call thesync
function inGSPVault.sol
, which synchronizes the reserves with the current token balances.Vulnerability Detail
The
buyShares
function calculates the number of shares to be allocated to a user based on the difference between the current token balances and the stored reserves (_BASE_RESERVE
and_QUOTE_RESERVE
). However, an attacker can front-run a user'sbuyShares
transaction by calling thesync
function, which updates the reserves to match the current balances. This results in the user's transaction seeing no difference between the reserves and the current balances, leading to zero shares being allocated.Impact
This vulnerability can be exploited to prevent legitimate users from acquiring shares in the pool, despite depositing their tokens. It undermines the fairness and functionality of the share distribution mechanism, potentially leading to loss of trust and reduced participation in the pool.
Code Snippet
Tool used
Manual Review
Recommendation
Rewrite
buyShares
function. Approve current contract to spend tokens of behalf ofmsg.sender
. Transfer from msg.sender needed amount of both tokens. And based on this amounts calculateshares
Duplicate of #78