in BathToken attacker can make the ratio underlyingBalance()/totalSupply() very high (when bathToken created) that users deposits will be lost because of rounding error
Audit: 2022-05-rubicon-findings
Severity: HIGH

# Lines of code

https://github.com/code-423n4/2022-05-rubicon/blob/8c312a63a91193c6a192a9aab44ff980fbfd7741/contracts/rubiconPools/BathToken.sol#L556-L585


# Vulnerability details

## Impact
when `BathToken` created and `totalSupply()` is `0`, code use deposited `token` amount as `share`  amount to `mint` for user. attacker can transfer `100 ether` `underlying token` directly to contract and then deposit `1 wei` so that `underlyingBalance()/totalSupply()` will be high enough that users deposits will be lost because, low amount of share will be calculated because of rounding error.
attacker can send `underlying token` and deposit with sandwich attack when deployment transaction happens.

## Proof of Concept
This is `_deposit()` code in `BathToken`:
```
function _deposit(uint256 assets, address receiver)
        internal
        returns (uint256 shares)
    {
        uint256 _pool = underlyingBalance();
        uint256 _before = underlyingToken.balanceOf(address(this));

        // **Assume caller is depositor**
        underlyingToken.transferFrom(msg.sender, address(this), assets);
        uint256 _after = underlyingToken.balanceOf(address(this));
        assets = _after.sub(_before); // Additional check for deflationary tokens

        (totalSupply == 0) ? shares = assets : shares = (
            assets.mul(totalSupply)
        ).div(_pool);

        // Send shares to designated target
        _mint(receiver, shares);
        emit LogDeposit(
            assets,
            underlyingToken,
            shares,
            msg.sender,
            underlyingBalance(),
            outstandingAmount,
            totalSupply
        );
        emit Deposit(msg.sender, msg.sender, assets, shares);
    }
```
As you can see, when `(totalSupply == 0)`, then the number of `shares` contract mint for user is deposit amount. contract don't consider current balance of contract in `underlying token`. in this line:
```
        (totalSupply == 0) ? shares = assets : shares = (
            assets.mul(totalSupply)
        ).div(_pool);
```
if `underlyingBalance() / totalSupply()` was too high user will receive lower amount of share.
Attacker can cause very high ratio for `underlyingBalance() / totalSupply()`, with early transferring `underlying token` like `1000 * 1e18` to `BathToken` address and then depositing small amount like `1 wei` by attacker or others will create high `underlyingBalance() / totalSupply()` and any deposit will lose up to `1000 * 1e18` value because of rounding in share calculation round.
To exploit this attacker can create `BathToken` himself too, creating `BathToken` is permissionless. because there is only one `BathToken` for every `ERC20` address, so attacker can perform this attack for popular `ERC20` addresses and create their `BathToken` himself and steal others deposits.

## Tools Used
VIM

## Recommended Mitigation Steps
add more precision for share or consider contract balance in `underlying token` when `totalSupply == 0`