Bug Reports that Exploit External Dependencies Resulting in Directly Exploitable Impacts on the Project

There may be situations where whitehats finds bugs in an external dependency that your project is relying on. It could be a third-party Oracle or a library that your project is using. In some cases, bugs in external dependencies don’t cause an impact on your project, but there have been instances where this type of bug has resulted in catastrophic, directly exploitable impacts on the project.

This is a dreadful scenario, so we want to help you to prepare for it and respond effectively in case it should occur.

First example: A vulnerable 3rd party oracle

Imagine you're using CurvePools as an oracle. During the integration with Curve.fi, you decide to use the get_virtual_price function to get the current price of the LP Tokens for stable swaps. Then, you receive a bug report showing that relying on get_virtual_price can lead to the vulnerabilities of price manipulation due to a read-only reentrancy. It's an issue with how the Curve.fi get_virtual_price is implemented, which is not something you could have prevented, as it was made to be safe. But if your project has upgradability functionality and could easily switch to another oracle (like Chainlink), you could prevent the exploitation of the Curve.fi get_virtual_price function, thus fixing the issue on your end.

Second example: A vulnerable 3rd party library

Another example of a vulnerability in an external dependency affecting a project is an instance where whitehat pwning.eth found a bug in the Frontier Library. That library was owned by Parity, and it was used by Moonbeam Network, Acala, and Astar. The vulnerability could have resulted in minting fake wrapped native tokens, which are widely used across the DeFi ecosystem of each network. Fortunately, the affected projects had the ability to fix the library and prevent the bug from being exploited.

 

How should you deal with external dependency vulnerabilities? Treat them as in-scope

We strongly advise projects to accept these vulnerabilities as valid due to the simple fact that the overall impact is in scope and the damage is extreme. At the end of the day, most protocol users or investors don’t care whether something was in scope for a bug bounty or not; they care whether or not they could have lost their money invested in the protocol or otherwise adversely harmed.

Conversely, to receive on and act on such vulnerability disclosures while using ‘external dependency, not my mistake’ as an excuse to deny an appropriate bounty is a guaranteed way to destroy trust in the blockchain security community at scale.

Here’s how we recommend you approach this type of issue:

• Projects should pay bounties when they are able to act on the bug report and make the fix themselves.
• If a reported vulnerability exists in an external dependency that also affects other parties, you should first pay the whitehat for submitting to your bug bounty program, and then advise them to disclose the vulnerability to the other affected parties so that they may claim any available bounty for their good work.
• If the issue is on the blockchain level (L1 / L2) we recommend that you close the report as Out of Scope for your program and that you ask for the Whitehat to contact the L1 / L2 directly with their report instead. 
• If you cannot make a fix yourself but the report gives you the power to avert harm, you should award the bounty as you are averting extreme impact to your protocol. If there is not a clear path for you to fix the issue, think about other emergency measures your project can take to stop the money loss. Is there a “big red button” you can press to stop the protocol or the money flow? Can you upgrade your way out of the issue? Can you execute a whitehat hack to protect user funds?

By awarding bug bounties for in-scope impacts, even if they are on external dependencies, you will maximize your products security, as whitehats are incentivized to look for any way to make your project safer, and they know you will honor their hard work for any valid vulnerability disclosed.

Related Articles:

Best Practices: Primacy of Impact