Missing access control on `FeeSplitter::setCurves` function. Malicious user can set his curves contract and withdraw all ethers from `FeeSplitter` using `FeeSplitter:claimFees` function.
Audit: 2024-01-curves-findings
Severity: HIGH

# Lines of code

https://github.com/code-423n4/2024-01-curves/blob/main/contracts/FeeSplitter.sol#L35-L37


# Vulnerability details



## Summary

`FeeSplitter::setCurves`function does'nt have any access control. So anyone can call this and set `curves` contract to a malicious contract which gives the value in favour of malicious user. Some malicious `curvesTokenSubject` can buy 1st token in real `Curves` contract. He can set his own curves state variable in `FeeSplitter.sol` using `setCurves` function. Which will return `curvesTokenSubject` wanted unlimited balance output from `curvesTokenBalance` in `FeeSplitter::balanceOf` function. Based on that malicious balance `curvesTokenSubject` can claim all the fees present in `FeeSplitter` contract for all the holders but malicious`curvesTokenSubject` will withdraw all the ethers present in `FeeSplitter` and he will completely drain it.

## Vulnerability Details and POC :

Clearly below we can see `setCurves` has no access control. So anyone can call it and set `curves` contract to his own malicious contract which will return the value in favour of malicious actor.

### Vulnerable Code [contracts/FeeSplitter.sol#L35-L37](https://github.com/code-423n4/2024-01-curves/blob/main/contracts/FeeSplitter.sol#L35C5-L37C6)

```solidity
      //@audit missing access control on Critical function
35:  function setCurves(Curves curves_) public {
36:        curves = curves_;
37:    }
```

### Attack Path (POC) :

1.  Attacker will buy 1 token from real `Curves` contract's [buyCurvesToken](https://github.com/code-423n4/2024-01-curves/blob/main/contracts/Curves.sol#L211C5-L211C89) function as he is first buyer and by passing his address in `curvesTokenSubject`. so it can call `onBalanceChange` and `addFees` functions in `FeeSplitter`. So that `data.cumulativeFeePerToken` have something. So it's difference with `data.userFeeOffset[account]` will not be 0 in [updateFeeCredit](https://github.com/code-423n4/2024-01-curves/blob/main/contracts/FeeSplitter.sol#L63) function. So that it updates the `data.unclaimedFees[account]` for attacker address same as ether balance of `FeeSplitter`.

2.  He will set his malicious curves contract in `FeeSplitter::setCurves` function. This contract implements a `curvesTokenBalance` and `curvesTokenSupply` function and returns the value according to the `FeeSplitter` total eth balance so he can claim all the ethers present in `FeeSplitter`.

3.  Now he checks using [getClaimableFees](https://github.com/code-423n4/2024-01-curves/blob/main/contracts/FeeSplitter.sol#L73) function how much balance should his malicious Curves `curvesTokenBalance` function return to make fees equal to `FeeSplitter` eth balance.

[FeeSplitter::getClaimableFees](https://github.com/code-423n4/2024-01-curves/blob/main/contracts/FeeSplitter.sol#L73)

```solidity

   function getClaimableFees(address token, address account) public view returns (uint256) {
       TokenData storage data = tokensData[token];
       uint25