Micro Neon Beaver Migrator Bug: Unmigrated Borrow Positions

by Axel Sørensen 60 views

Hey guys! Let's dive into a critical issue found in the Micro Neon Beaver project related to its migrator functionality. Specifically, we're talking about how the migrator fails to handle certain borrow-only positions, potentially leaving users in a sticky situation. This article will break down the problem, explore the root cause, and discuss the impact, complete with a proposed solution. Let's get started!

Summary of the Migrator Failure

So, here’s the deal: The Migrator in Micro Neon Beaver skips borrow positions from markets that users haven't entered as collateral. This means that while some positions migrate successfully, these specific debt positions are left behind. Imagine borrowing some USDC without entering the USDC market as collateral – that's the kind of scenario where this issue pops up. It's like packing for a big trip and accidentally leaving your toothbrush behind – not ideal!

Root Cause Analysis: Why Are These Positions Left Behind?

The heart of the problem lies within the _collectMendiPositions function in Migrator.sol, specifically line 165. This function uses getAssetsIn(), which only returns markets the user has entered as collateral. If a user has borrowed from a market without entering it as collateral, those positions are simply excluded from the migration process. It's like the function is only looking at the VIP list and forgetting about the rest of the guests. This oversight leads to those debt positions being stranded, causing a headache for users trying to migrate their assets smoothly.

To really understand this, let's break it down further. The getAssetsIn() function is designed to fetch markets where a user has supplied assets as collateral. This is a common pattern in DeFi protocols, but in this case, it creates a blind spot. Users who have borrowed assets without providing collateral in the same market (a perfectly valid strategy in Compound forks and similar systems) are essentially invisible to the migrator's initial sweep. This is a critical detail because it directly impacts the completeness of the migration process, leading to potential inconsistencies in a user's portfolio across different platforms.

The reason this happens is because the logic assumes that all relevant positions are tied to collateralized markets. However, the DeFi landscape allows for more nuanced strategies where borrowing can occur independently of collateralization in a specific market. This is often seen as a way to optimize capital efficiency or manage risk in a more granular way. Therefore, the migrator's reliance on getAssetsIn() creates a significant limitation, as it fails to account for these legitimate and potentially large portions of a user's debt.

Think of it like this: you're moving houses, and the moving company only packs the boxes that are in the living room, completely ignoring the ones in the attic. You might get most of your stuff moved, but you're going to have a problem when you realize half your belongings are still at the old place. This is precisely the situation users face with this migrator issue – a partial migration that leaves them with assets spread across different platforms, complicating their DeFi management.

Pre-Conditions: Setting the Stage for Failure

To trigger this issue, a few conditions need to be met:

  1. User has borrowed from a Mendi market: This is the baseline – there needs to be a borrow position in the first place.
  2. User has NOT entered that market (not using as collateral): This is the key condition. The user must have borrowed without entering the market as collateral.
  3. User attempts migration: Finally, the user needs to initiate the migration process for the flaw to surface.

These pre-conditions highlight a common scenario in DeFi, where users strategically borrow assets without necessarily collateralizing in the same market. This strategy might be employed for various reasons, including optimizing borrowing rates or managing exposure to different assets. The fact that the migrator fails to account for this scenario is a significant oversight.

Attack Path: How This Plays Out in the Real World

Let’s walk through a step-by-step attack path to see how this vulnerability manifests:

  1. User deposits WETH and enters it as collateral: The user starts by depositing WETH and using it as collateral in the Mendi protocol.
  2. User borrows USDC but doesn't enter USDC market: The user then borrows USDC but doesn't enter the USDC market as collateral. This is perfectly valid in Compound forks and similar protocols.
  3. User calls migrate(): The user initiates the migration process, expecting all their positions to be moved.
  4. WETH position migrates (in getAssetsIn()): The WETH collateral position migrates successfully because it's captured by getAssetsIn().
  5. USDC borrow position NOT migrated (not in getAssetsIn()): The USDC borrow position, however, is left behind because it's not in the list returned by getAssetsIn().
  6. Result: WETH collateral on Malda, USDC debt remains on Mendi: The user ends up with their WETH collateral on the new Malda protocol, but their USDC debt remains on the old Mendi protocol.
  7. Split position across two protocols: This creates a split position, with assets and liabilities spread across two different platforms.

This scenario paints a clear picture of the problem. The user's intention was to migrate their entire portfolio, but the migrator's limitations result in a fragmented position. This not only complicates portfolio management but also introduces additional risks, as we'll discuss in the impact section.

Impact: The Consequences of Incomplete Migration

The impact of this vulnerability is significant. An incomplete migration leads to split positions across protocols, meaning specific borrow positions from non-entered markets remain on Mendi while other positions are migrated to Malda. This creates several issues for the user:

  • Increased Complexity: Users have to manually manage positions on both protocols, which is a pain and requires extra effort.
  • Higher Risk: Split positions increase liquidation risk. If the user's collateral on Malda isn't sufficient to cover the debt remaining on Mendi, they could face liquidation. It’s like having one foot on solid ground and the other on a banana peel!

Imagine trying to keep track of your finances when some of your accounts are at one bank and others are at a completely different institution. It's a headache, right? This is the same kind of problem users face when their DeFi positions are split across protocols. The added complexity makes it harder to monitor and manage risk, potentially leading to costly mistakes.

Moreover, the increased liquidation risk is a serious concern. In DeFi, positions are often overcollateralized to protect lenders. However, if a user's collateral is split from their debt, it can throw off the balance and make them more vulnerable to liquidation. This is especially true in volatile market conditions, where prices can move rapidly and trigger liquidations unexpectedly. The migrator's failure to handle borrow-only positions exacerbates this risk, putting users' funds in jeopardy.

Proof of Concept (PoC)

Unfortunately, the provided text doesn't include a specific Proof of Concept (PoC). A PoC would typically involve a code snippet or a step-by-step guide demonstrating how to reproduce the vulnerability. However, the attack path outlined above provides a clear conceptual understanding of how the issue can be triggered.

To create a formal PoC, one would need to write a test case that simulates the scenario described in the attack path. This would involve deploying the relevant contracts (MendiComptroller, MendiMarket, Migrator, etc.), setting up a user with a borrow-only position, and then calling the migrate() function. The test would then assert that the borrow position remains on the Mendi protocol while the collateral position is migrated to Malda, thus confirming the vulnerability.

While the absence of a PoC in the original text is a limitation, the detailed explanation of the vulnerability and the attack path make it relatively straightforward to construct a PoC for verification purposes.

Mitigation: A Potential Solution

To fix this issue, the _collectMendiPositions function needs to iterate through all markets, not just the ones entered as collateral. Here’s a code snippet demonstrating the proposed mitigation:

function _collectMendiPositions(address user) private returns (Position[] memory) {
    // Get ALL markets, not just entered
    address[] memory allMarkets = IMendiComptroller(MENDI_COMPTROLLER).getAllMarkets();
    
    for (uint256 i = 0; i < allMarkets.length; i++) {
        uint256 borrowAmount = IMendiMarket(allMarkets[i]).borrowBalanceStored(user);
        if (borrowAmount > 0) {
            // Include even if not entered as collateral
        }
    }
}

This modified function retrieves all markets from the Mendi Comptroller and then checks the borrow balance for the user in each market. By including all markets, the migrator will correctly identify and migrate borrow positions, even if the user hasn't entered those markets as collateral. This ensures a complete and accurate migration, preventing the issues associated with split positions.

This mitigation strategy addresses the root cause of the vulnerability by expanding the scope of the position collection process. Instead of relying on getAssetsIn(), which is inherently limited to collateralized markets, the modified function casts a wider net and considers all markets within the protocol. This ensures that all relevant positions, including borrow-only positions, are captured and migrated.

The beauty of this solution lies in its simplicity and effectiveness. By making a small change to the _collectMendiPositions function, the migrator can correctly handle a wider range of user scenarios, improving the overall reliability and user experience of the migration process. This is a prime example of how a targeted code modification can have a significant impact on the security and functionality of a DeFi protocol.

Conclusion: Ensuring Smooth Migrations

In conclusion, the migrator's failure to handle borrow-only positions is a significant issue that can lead to split positions and increased risk for users. By modifying the _collectMendiPositions function to iterate through all markets, we can ensure a more complete and reliable migration process. This fix not only addresses the immediate vulnerability but also enhances the overall robustness of the Micro Neon Beaver protocol. Let's keep building safer and more user-friendly DeFi guys!