Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Protocol supports stETH but doesn't consider its unique transfer logic which would lead to not only a DOS of the depositing/withdrawal channel for this collateral token but also a flaw in multiple other core protocol logic #161

Closed
c4-bot-3 opened this issue Jul 8, 2024 · 0 comments
Labels
3 (High Risk) Assets can be stolen/lost/compromised directly bug Something isn't working insufficient quality report This report is not of sufficient quality 🤖_primary AI based primary recommendation

Comments

@c4-bot-3
Copy link
Contributor

c4-bot-3 commented Jul 8, 2024

Lines of code

https://github.com/code-423n4/2024-06-badger/blob/main/ebtc-zap-router/src/ZapRouterBase.sol#L110
https://github.com/code-423n4/2024-06-badger/blob/main/ebtc-zap-router/src/ZapRouterBase.sol#L103
https://github.com/code-423n4/2024-06-badger/blob/main/ebtc-protocol/packages/contracts/contracts/LeverageMacroBase.sol#L270

Vulnerability details

Impact

eBTCZap__ Protocol supports stETH but doesn't consider its unique transfer logic.

    /// @notice Transfer an arbitrary token back to you
    /// @dev If you delegatecall into this, this will transfer the tokens to the caller of the 
    /// DiamondLike (and not the contract)
    function sweepToken(address token, uint256 amount) public {
        _assertOwner();

        IERC20(token).safeTransfer(msg.sender, amount);//<@
    }

As per the comment we can pass any arbitrary token to this function.
If the token used is stEth in the above function, then we should consider that stEth is a special token as per lido's official docs, we can see that there is a special section that talks about it's unique concept, i.e the "1-2 wei corner case" here is the link.

transferShares is used in few functions of the contract, but the other functions doesn't use transferShares (shared below) which can lead to a vulnerability.

The probability of issue appearing is high and you can check in the following discussion. It has also been classified as a High severity on past contests: lidofinance/core#442
Not taking in account the 1-2 wei edge case at some places can cause some breaking of functionality and potentially the protocol.

Proof of Concept

In the following functions transferShares is not implemented

https://github.com/code-423n4/2024-06-badger/blob/main/ebtc-zap-router/src/ZapRouterBase.sol#L110
https://github.com/code-423n4/2024-06-badger/blob/main/ebtc-zap-router/src/ZapRouterBase.sol#L103
https://github.com/code-423n4/2024-06-badger/blob/main/ebtc-protocol/packages/contracts/contracts/LeverageMacroBase.sol#L270

Tools Used

Manual review

Recommended Mitigation Steps

Follow Lido's recommendation to utilize transferShares function while transferring stEth, so the amount is accurate.

Assessed type

Context

@c4-bot-3 c4-bot-3 added 3 (High Risk) Assets can be stolen/lost/compromised directly bug Something isn't working labels Jul 8, 2024
c4-bot-1 added a commit that referenced this issue Jul 8, 2024
@c4-bot-12 c4-bot-12 added the 🤖_primary AI based primary recommendation label Jul 8, 2024
@howlbot-integration howlbot-integration bot added the insufficient quality report This report is not of sufficient quality label Jul 10, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
3 (High Risk) Assets can be stolen/lost/compromised directly bug Something isn't working insufficient quality report This report is not of sufficient quality 🤖_primary AI based primary recommendation
Projects
None yet
Development

No branches or pull requests

2 participants