Bug Report Incident Response
TL;DR ~ Xave received a report of a potential vulnerability, and by activating our SOP for such incidents 100% of LP funds were protected and Xave is now back online.
Context and Response
On November 15th Xave received a bug report from a member of the community, which was investigated and found to represent a potential bug to certain FXPools.
Following our framework for responding to such incidents the team immediately informed partners, LPs and and the broader public to remove liquidity from the impacted pools while we investigated further. This message was amplified by our protocol partners Balancer and Avalanche, stablecoin issuers, and via our public communication channels.
While liquidity was removed from impacted FXPools the Xave team worked with third party auditors and security researchers to investigate the source of the bug. Once satisfied that the audit was completed new FXPools were deployed with the updated code, and partners were contacted to redeploy liquidity.
Description of Bug Report
In some cases, the bug would have allowed an actor to potentially gain a profit from the pool. This was due to user call data that was not sanitized correctly.
During the deposit or withdrawal operation, the FXPool contract would validate that the tokens to be withdrawn are part of the FXPool. One missing validation was checking that the tokens passed in the userData parameter are actually different from each other. Because of this, for a pool that has two tokens (tokenA, tokenB), one with 2 decimals and the other with 6 decimals, an attacker could craft a join / exit pool request such that both tokens passed in userData are the 6 decimals tokenB and therefore receive 4 orders of magnitude more tokenA from the pool.
Sequence of Events
Note: all times listed are GMT
Description of Fix
The fix was straightforward: we are not relying on the userData information for correctly sorting the tokens within the pool. We used the same sort logic as the Balancer’s Vault: tokenA < tokenB. This removed the possibility of this type of bug to be present in the code in the future. The fix is backwards compatible so any on chain or off chain integrations shouldn’t be affected by this.
Next Steps to Resume Operations
Reactions and Closing Thoughts
While Xave has received bug reports in the past, this was the first critical issue that warranted a thorough response. Thanks to the white hat’s responsible disclosure, existing response frameworks, immediate action and quick community support, 100% of LP funds on Xave were protected.
While building open source tools is a core tenet of a permissionless and non-custodial financial system, one side effect is that all parts of the system are accessible to anyone on the network. The goal of any protocol is to follow best security practices while building in this open financial system, and as we build this paradigm it is paramount that processes and procedures for these types of scenarios be put in place beforehand.
The Xave team continues to stick to its’ practice of having two separate auditors review the code before every release, as we did for the affected version of the code. However, both developers and auditors are still human and certain scenarios may be missed. We intend to add a third layer to our pre-release process and now add a CodeArena review step to get a wider set of eyes on our code instead of just two auditors.
