In the following proposal to the Curve community, we want to elaborate on what has happened in the most recent hack related to the Vyper compiler and how future exploits based on external attack vectors can be prevented. Furthermore, we are going to look into the underlying, fundamental characteristics of hacks, as well as looking into designing a safer security system based on identifying those characteristics on-chain, thereby preventing exploits in realtime.
Our team has been intensively working for the last 6 months on tangible solutions to mitigate the most profound attack vectors of DeFi protocols. We believe to have found a realistic and suitable solution with our most recent development: On-Chain Firewalls.
We are looking forward to opening up a discussion on the governance forum around our proposed security improvements to Curve. We hope to gain feedback, suggestions and potential support that could lead to a grant for further developing this novel concept.
The most recent exploit on Curve is a perfect example of how dependencies, outside the protocols actionable control, can become attack vectors, thereby compromising the overall protocols security.
Audits would not be even able to detect that vulnerability. Problem was lying in a deeper layer of the stack.
https://twitter.com/fubuloubu/status/1685856295033659392?s=20
Most established exploit prevention procedures like performing security audits are important, yet, we must understand that these have limitations and cannot asses risks beyond code produced by the engineering team. External dependencies as potential attack vectors are frequently being disregarded or assumed to be safe, as they lies outside a single protocol’s spectrum of actionable security measures. Furthermore, given the example of the most recent curve exploit: Auditing legacy versions of the Vyper compiler, was undoubtably out of the protocol’s security scope.
Even when exploring hypothetical scenarios, e.g.: All protocols using Vyper coming together beforehand and collectively sourcing audits for Vyper versions 0.2.15, 0.2.16, and 0.3.0, it still would not have solved the underlying problem: The unknown (un)knowns of vulnerable external dependencies. Given the infinite amount of unknowns, it is merely impossible to effectively draw the line between where to start and stop security audits.
This is why protocols have to hope for the best while keeping their fingers crossed🤞once deploying code to production. In essence: Hoping they won’t have to face any unknown (un)knowns in production, but if so, hopefully only through bug bounties programs and whitehats. Usually, the financial incentives for blackhat hackers largely outweigh bug bounty initiatives, leading to exploits of undiscovered attack vectors. Furthermore, in accordance to Murphy’s Law, the above strategy would lead to a hack in any case, sooner or later.
As an additional layer of protection to the protocol Firewalls can be added to mitigate in-production risks.
Even tough, the way the protocol gets exploited relies on an unknown (un)known, the target of the exploit always is a KNOWN KNOWN, being liquidity.
