Post-mortem: Wyvern v2.2 denial-of-service vulnerability

What happened?

On Tuesday, October 22nd, the Wyvern team was made aware of a potential denial-of-service vulnerability in the production deployment of Wyvern v2.2 by the independent Ethereum security researcher epheph. The vulnerability allowed any user to gain control of and self-destruct a special AuthenticatedProxy contract used by the Wyvern registry. If exploited, the vulnerability would have required Wyvern users to upgrade their wallet contracts and likely temporarily halted trading at exchange services such as OpenSea which utilize the protocol.

After verifying the vulnerability internally, assessing the possible impact, and analyzing mitigation strategies, the Wyvern team coordinated with epheph to fix the denial-of-service vulnerability in a manner which would minimize required actions and gas expenditures by Wyvern protocol users. The mitigation was tested on Thursday, October 24th, and the fix deployed on Friday, October 25th (yesterday). The vulnerability has not been exploited, no user funds or assets are or were at risk, and no action on the part of Wyvern protocol users is necessary. The registry contract on GitHub has been patched so anyone who deploys a separate instance of the protocol in the future will be unaffected.

Why was this contract uninitialized?

This particular AuthenticatedProxy contract is special: it was not created by or intended for use by any user of the protocol. Rather, this contract was created by the Wyvern registry, and intended for use only as a DELEGATECALLtarget so that the Wyvern registry contract could check that the user’s wallet contract was executing the correct code when the user executed a Wyvern order. Thus the storage values of this AuthenticatedProxy instance have no effect on the functionality of the protocol.

A correct registry implementation would have initialized this contract, but this was not done, so any user could call initialize and claim ownership of it. Subsequently, they could have used the DELEGATECALL functionality of the AuthenticatedProxy itself to delegate-call into another contract and self-destruct this special instance. If they had done so, users of the Wyvern protocol would have needed to upgrade their individual wallet contracts to point to a different AuthenticatedProxy contract, and the Wyvern registry contract would have needed to be upgraded. This vulnerability is a bit like the Parity wallet bug, but with a custom kill() function (and, unlike the bug, not locking any funds, since the user wallet contracts are upgradable).

As soon as epheph discovered this vulnerability, they claimed ownership of the AuthenticatedProxy instance, and after communicating with the Wyvern team, transferred control of the instance to a dummy self-destructed contract, such that it is now uncontrollable (and thus un-self-destructable).

Were user funds or assets at risk?

No. Wyvern’s architecture is constructed such that user wallet contracts can be upgraded individually by the owning user without interaction with or dependence upon any other smart contracts. If the vulnerability had been exploited, users would have needed to upgrade their individual wallet contracts and possibly re-sign Wyvern orders, but no funds or assets were at risk of being stolen or locked.

What do Wyvern Protocol users need to do?

Individuals and services using the Wyvern Protocol do not need to take any action. The vulnerability has been mitigated by rendering this special instance of the AuthenticatedProxy contract unowned and un-self-destructable, and it can no longer be exploited.

Why was the vulnerability undiscovered for so long?

This vulnerability was not caught by multiple independent auditors and security reviews and remained undiscovered on the Ethereum mainnet for over a year. Writing complex smart contracts which are performant, flexible, and bug-free is an extraordinarily difficult task. This was the first vulnerability discovered in mainnet deployments of any version of the Wyvern Protocol.

epheph discovered this vulnerability through the use of blockchain data indexing & query products created by Amberdata.

We eagerly await future advancements in secure smart contracts, including symbolic execution and dependently typed languages.

Were any special permissions used to enact the fix?

No. The Wyvern team does not have any special permissions over the protocol’s smart contracts, and none were necessary in order to enact the fix.

The only entity with special permissions in the protocol is the Wyvern DAO, which can enact upgrades to the Exchange contract after a mandatory two-week delay period. The Wyvern DAO does not control user wallet contracts.

Was the security researcher paid a bounty?

Yes. The researcher epheph was paid a bounty of $6000 in this transaction.

What procedures will be put in place to mitigate such issues in the future?

• The security researcher was initially unsure who to contact. The Wyvern team will establish a public bug bounty program and a secure line of communication for researchers who discover any future bugs in production protocol deployments.
• Although version 3 of the Wyvern Protocol uses the same proxy registry contract and is thus no longer vulnerable to this bug, the Wyvern team will run another security audit and public bug bounty protocol on version 3 prior to mainnet deployment.
• The Wyvern team will look into options for formal verification of current or future protocol smart contracts.