Full Report
Balancer is a specialized AMM that allows trading pools of more than 2 coins. Most of the time, these pools are 2 coins, where the price is self balancing and really simple: Balance of token A * Balance of token B = Constant product called the "constant product" equation. The adaption is to generalize this formula to work for more than 2 tokens they called weighted math. The algorithm above allows for an algorithm to facilitate trades by calculating its own price. If there is less of one token, then this one goes up in price. AMMs are a fascinating concept! Balancer also has a flash loan functionality built into each pool. This is a borrow that can be performed without providing any assets in return; this has the major caveats of ONLY working if it is returned in a single transaction. To perform a flash loan, a function call is performed with a list of tokens and their values to retrieve. In order to ensure that money is repaid at the end of the block, the original cost of each token is kept track of. This is checked at the end of the call to ensure that they are the same and the fee is also taken for the service. An additional piece of information to understand this is proxies. Proxies allow the contract to be editable by having one base contract have the storage then send future calls to another contract, which is the current version. At this point, contract has two entrypoints: the proxy and the implementation. Several ERC20 tokens allow for this, such as sBTC and SNX. The vulnerability is within the handling of double entrypoint tokens. Both the proxy and token address can be specified in the call. The first coin will appear to have all of the money, while the initial will have none of the money. When this is inserted back into the contract, (as required), the excess money will all go to the fees contract. This sends a MAJOR excess of money from the contract to the fees collector, causing a DoS on the pool. This is an interesting bug for a very weird edge case of ERC20 tokens. This required a deep understanding of token implementations and the Balancer contract as a whole. This was only a partial denial of service, but was still interesting none-the-less.
Analysis Summary
# Vulnerability: Balancer Partial Denial of Service via Double Entry-Point Tokens in Flash Loans
## CVE Details
- CVE ID: Not specified in the provided text (Likely a recent, unassigned disclosure or internal ID used by Balancer/Immunefi).
- CVSS Score: Not specified (Reported as "Medium" severity by Balancer previously).
- CWE: Likely related to Improper State Tracking or Insufficient Input Validation, specific to token implementation handling.
## Affected Systems
- Products: Balancer Protocol, specifically pools utilizing the flash loan functionality.
- Versions: Not explicitly listed, but implied to be the version vulnerable to the flash loan interaction with double entry-point tokens.
- Configurations: Pools interacting with specific ERC20 tokens that implement a "double entry-point" mechanism (where both the proxy and token address can be specified in calls).
## Vulnerability Description
The vulnerability resides in the Balancer contract's handling of operations, such as flash loans, when interacting with specialized ERC20 tokens that support a "double entry-point" (where both proxy and implementation addresses are addressable via the token call).
In a flash loan scenario involving such a token:
1. The attacker can specify both the proxy and the implementation token addresses in the function call.
2. This manipulation causes the token balances tracked internally by Balancer to become inconsistent: one account appears to hold all the funds, while the initial account appears to have none.
3. When the flash loan requires repayment, the excess funds resulting from this token state split are incorrectly funneled to the fees collector contract (`ProtocolFeesCollector.sol`).
4. This action results in a **Partial Denial of Service (DoS)** on the affected pool by sending a "MAJOR excess of money" to the fees collector, effectively draining or severely imbalancing the necessary collateral/liquidity required for further standard operations within the pool.
## Exploitation
- Status: Implied to be **Not exploited in the wild** as it was reported via a bug bounty program.
- Complexity: **High** (Required deep understanding of token implementations and the Balancer contract architecture, specifically proxies and flash loans).
- Attack Vector: Transactional (via a crafted flash loan request).
## Impact
- Confidentiality: No direct impact described.
- Integrity: **High** (Severe disruption to pool accounting and asset distribution due to incorrect fee collection).
- Availability: **Medium/High** (Caused a Partial Denial of Service (DoS) by misallocating assets, likely impeding the pool's liquidity function until resolved or accounted for).
## Remediation
### Patches
- Specific patch version details are **not provided** in the summary, only that the bug was reported on May 14th and subsequently fixed. Researchers should check Balancer security disclosures for the associated fix commit/version.
### Workarounds
- None explicitly mentioned, but implicitly, avoiding pools featuring double entry-point tokens during the vulnerable period would serve as a temporary mitigation.
## Detection
- Indicators of compromise: Unusually large transfers or drains of liquidity directed specifically towards the associated protocol fees collector address immediately following a flash loan execution.
- Detection methods and tools: Monitoring deviations in expected token accounting post-flash loan callbacks, particularly when interacting with non-standard ERC20 tokens.
## References
- Vendor Advisory: Balancer protocol disclosure (Date of report: May 14th).
- Relevant links: [Balancer protocol documentation (for context)](https://docs.balancer.fi/)