Optimism Self Destruct Exploit

Notice: This page is a new case study and some aspects have not been fully researched. Some sections may be incomplete or reflect inaccuracies present in initial sources. Please check the References at the bottom for further information and perform your own additional assessment. Please feel free to contribute by adding any missing information or sources you come across. If you are new here, please read General Tutorial on Wikis or Anatomy of a Case Study for help getting started.

Notice: This page contains sources which are not attributed to any text. The unattributed sources follow the initial description. Please assist by visiting each source, reviewing the content, and placing that reference next to any text it can be used to support. Feel free to add any information that you come across which isn't present already. Sources which don't contain any relevant information can be removed. Broken links can be replaced with versions from the Internet Archive. See General Tutorial on Wikis, Anatomy of a Case Study, and/or Citing Your Sources Guide for additional information. Thanks for your help!

Optimism

Optimism is a layer 2 scaling solution on Ethereum. A critical bug existed in the protocol which would have allowed an attacker to mint additional unbacked Ethereum. The bug was only exploited once, apparently by accident with no loss of funds. On February 2nd, 2022, a white hacker named Jay Freeman found and reported it. The issue was fixed, and he received bounties that totaled $2.1m.

This is a global/international case not involving a specific country.

About Optimism

"Optimism is a low-cost and lightning-fast Ethereum L2 blockchain."

"Optimism is an "Optimistic Rollup," which is basically just a fancy way of describing a blockchain that piggy-backs off of the security of another "parent" blockchain. Specifically, Optimistic Rollups take advantage of the consensus mechanism (like PoW or PoS) of their parent chain instead of providing their own. In Optimism's case this parent blockchain is Ethereum."

"Optimism is built according to a strong design philosophy that stands on four main pillars: simplicity, pragmatism, sustainability, and, of course, optimism."

"As few lines of code as possible separate Optimism from Ethereum's battle-tested infrastructure. Build your app on the L2 that doesn't quit." "Optimism is equivalent with the Ethereum Virtual Machine, not just compatible. This means all Ethereum apps and tooling just work."

"Optimism is a Public Benefit Corporation, a for profit corporation that is obligated to balance financial interests of our stockholders with the best interests of our community, and society."

"Not only are we writing software that scales Ethereum technology, we are also scaling Ethereum values by creating the rails for highly impactful projects that don’t have a business model to succeed. Read more about how we’re doing that here." ‍ "Until the project is fully decentralized, we will be donating all profits from running a centralized sequencer towards scaling and sustaining public goods."

a hacker identified an infinite Ether bug in the Optimism scaling solution for Ethereum but chose not to exploit it. Instead, the hacker, Jay Freeman, reported the bug to Optimism's development team, who awarded him a $2 million bug bounty. Freeman, known for his work on Cydia, discovered the glitch while investigating nano payment protocols. The bug allowed for the creation of unlimited "layer 2" crypto tokens on Optimism, which could have disrupted decentralized exchanges and devalued other tokens. The bug had similarities to the overflow bug in Bitcoin's code in 2010, which resulted in the creation of 184 billion BTC. Another party had previously encountered the bug on Ethereum blockchain explorer Etherscan but may not have realized its potential. Freeman emphasized the importance of prioritizing security and decentralization in blockchain projects.

The Reality

"With the ability to sneakily print IOUs (known on Optimism as OETH) on the other side of the bridge, you still can try to (slowly) withdraw money from the reserves, but now it will look like a legitimate transfer, making it easier to go unnoticed."

"(And, in case you believe that "someone would notice if the total number of IOUs were different than the amount of money locked in the reserves", this bug actually was triggered 40 days ago—as I will point out later—and no alarm bells were raised.)"

"Further, with your unbounded supply of IOUs, you could go to every decentralized exchange running on the L2 and mess with their economies, buying up vast quantities of other tokens while devaluing the chain's own currency."

"Using your access to infinite capital, you could further manipulate on-chain pricing oracles to leverage for other attacks\; and, until someone finally realizes your money is counterfeit, arbitragers will flock to the network to sell you their assets."

"This makes this bug capable of economic griefing attacks, wherein once someone notices—even if it is a mere hour later!—it might be "too late" to unravel what is and what isn't a legitimate transaction, calling into question the entire ledger."

What Happened

"Software engineer Jay Freeman (who goes by Saurik online) didn’t leverage the exploit. Instead, he reported the issue to Optimism’s dev team." "On 2/2/2022, I reported a critical security issue to Optimism—an "L2 scaling solution" for Ethereum—that would allow an attacker to replicate money on any chain using their "OVM 2.0" fork of go-ethereum (which they call l2geth)."

Key Event Timeline - Optimism Self Destruct Exploit

Date	Event	Description
February 2nd, 2022	Main Event	Expand this into a brief description of what happened and the impact. If multiple lines are necessary, add them here.
February 10th, 2022 7:54:31 PM MST	CoinTelegraph Article Published	CoinTelegraph reports that Jay Freeman, an iOS jailbreak software developer, discovered and reported a critical bug in the Optimism project, a Layer 2 scaling solution for Ethereum. The bug, which has since been patched, could have allowed hackers to create an unlimited amount of ETH in an Optimism account balance. Freeman was awarded a bug bounty of $2,000,042 for his discovery. The bug involved triggering the SELFDESTRUCT opcode on a contract to repeatedly create ETH. The Optimism team quickly fixed the issue and deployed the patch on its networks. The bug was not exploited, except for an accidental activation by a staff member at Ethereum data startup Etherscan, but no usable excess ETH was generated. Optimism is a Layer 2 scaling solution that employs optimistic rollups to improve efficiency, reduce transaction costs, and increase transaction speeds on the Ethereum network. The bug discovery highlights the ongoing need for security in Layer 2 protocol development. Additionally, MakerDAO recently announced a bug bounty program with a maximum reward of $10 million for identifying critical security threats in its smart contracts.
February 11th, 2022 3:38:00 AM MST	Self Destruct Post	@amanusk_ posts about self destruct further.
February 14th, 2022 3:19:35 AM MST	Protos Article Published	Protos reports that a hacker identified an infinite Ether bug in the Optimism scaling solution for Ethereum but chose not to exploit it. Instead, the hacker, Jay Freeman, reported the bug to Optimism's development team, who awarded him a $2 million bug bounty. Freeman, known for his work on Cydia, discovered the glitch while investigating nano payment protocols. The bug allowed for the creation of unlimited "layer 2" crypto tokens on Optimism, which could have disrupted decentralized exchanges and devalued other tokens. The bug had similarities to the overflow bug in Bitcoin's code in 2010, which resulted in the creation of 184 billion BTC. Another party had previously encountered the bug on Ethereum blockchain explorer Etherscan but may not have realized its potential. Freeman emphasized the importance of prioritizing security and decentralization in blockchain projects.

Technical Details

"With the ability to sneakily print IOUs (known on Optimism as OETH) on the other side of the bridge, you still can try to (slowly) withdraw money from the reserves, but now it will look like a legitimate transfer, making it easier to go unnoticed."

"(And, in case you believe that "someone would notice if the total number of IOUs were different than the amount of money locked in the reserves", this bug actually was triggered 40 days ago—as I will point out later—and no alarm bells were raised.)"

"Further, with your unbounded supply of IOUs, you could go to every decentralized exchange running on the L2 and mess with their economies, buying up vast quantities of other tokens while devaluing the chain's own currency."

"Using your access to infinite capital, you could further manipulate on-chain pricing oracles to leverage for other attacks\; and, until someone finally realizes your money is counterfeit, arbitragers will flock to the network to sell you their assets."

"This makes this bug capable of economic griefing attacks, wherein once someone notices—even if it is a mere hour later!—it might be "too late" to unravel what is and what isn't a legitimate transaction, calling into question the entire ledger."

"The UsingOVM flag is set with a USING_OVM environment variable (with no corresponding command line flag, as far as I know; that you need to set this environment variable while initializing the genesis block took me too long to figure out ;P)."

"Operations on the StateDB that affect an account balance are then redirected from the underlying stateObject (which represents an individual, cached account) to storage state in the OVM_ETH contract. Below is the code for state.StateDB.SetBalance."

"Now, there's actually already something interesting going on: s.GetOrNewStateObject has an observable side effect; but, when UsingOVM, this doesn't get called. This means that an account might own native currency without having an account object!"

"The exact issue here is that contracts are able to ask for the hash of the code of other accounts (which is sometimes used to verify their trusted behaviors). If an account has no code, its code is "", so its codehash is the hash of an empty buffer."

"However, if you ask for the codehash of an address that isn't currently backed by an object in the state trie, the codehash you get back is null. This observable effect is an example of the subtle incompatibilities that Optimism keeps experiencing."

"(If this were my project, I'd definitely have dropped everything long ago—pre-OVM 2.0—to prioritize removing this set of patches by fixing GetOVMBalanceKey to store hash preimages, re-executing the chain, and then swapping out the state trie.)"

"The code for Suicide is still directly modifying the stateObject's data.Balance field instead of checking UsingOVM and redirecting that modification to OVM_ETH."

"This means that, when a contract self-destructs, its balance is BOTH given to the beneficiary AND ALSO KEPT. If the contract had 10 OETH, 10 OETH are CREATED from thin bits and handed to the beneficiary."

"One of the questions we often want to answer is "has anyone else already pulled off an exploit using this bug?". To answer this, I instrumented the code for the OVM 2.0 to log any time a transaction destroyed a contract with a balance."

"As SELFDESTRUCT is already a rare opcode, and this is even then a subset of all uses of SELFDESTRUCT—and further, as OVM 2.0 was only released three months ago—there was only a single user who had ever tried this: on Christmas Eve (2021)."

"The bug presented here—which I dub "Unbridled Optimism"—can maybe be (crudely) modelled as a bug on the far side of a "bridge", but is actually a bug in the virtual machine that executes smart contracts on Optimism (an aforementioned L2 rollup)."

"Exploiting this enables the attacker to have access to an effectively unbounded number of tokens (aka, the IOUs) on the far side of the bridge. It is my contention that this is more dangerous than merely tricking the reserves into allowing a withdraw[a]l."

Total Amount Lost

No funds were lost since the exploit was uncovered before it could be maliciously exploited. While the incident was exploited 40 days earlier it appears to be accidental and there was no loss of funds.

"Exploiting this enables the attacker to have access to an effectively unbounded number of tokens (aka, the IOUs) on the far side of the bridge. It is my contention that this is more dangerous than merely tricking the reserves into allowing a withdraw[a]l."

Immediate Reactions

"The UsingOVM flag is set with a USING_OVM environment variable (with no corresponding command line flag, as far as I know; that you need to set this environment variable while initializing the genesis block took me too long to figure out ;P)."

"Operations on the StateDB that affect an account balance are then redirected from the underlying stateObject (which represents an individual, cached account) to storage state in the OVM_ETH contract. Below is the code for state.StateDB.SetBalance."

"Now, there's actually already something interesting going on: s.GetOrNewStateObject has an observable side effect; but, when UsingOVM, this doesn't get called. This means that an account might own native currency without having an account object!"

"The exact issue here is that contracts are able to ask for the hash of the code of other accounts (which is sometimes used to verify their trusted behaviors). If an account has no code, its code is "", so its codehash is the hash of an empty buffer."

"However, if you ask for the codehash of an address that isn't currently backed by an object in the state trie, the codehash you get back is null. This observable effect is an example of the subtle incompatibilities that Optimism keeps experiencing."

"(If this were my project, I'd definitely have dropped everything long ago—pre-OVM 2.0—to prioritize removing this set of patches by fixing GetOVMBalanceKey to store hash preimages, re-executing the chain, and then swapping out the state trie.)"

"The code for Suicide is still directly modifying the stateObject's data.Balance field instead of checking UsingOVM and redirecting that modification to OVM_ETH."

"This means that, when a contract self-destructs, its balance is BOTH given to the beneficiary AND ALSO KEPT. If the contract had 10 OETH, 10 OETH are CREATED from thin bits and handed to the beneficiary."

"One of the questions we often want to answer is "has anyone else already pulled off an exploit using this bug?". To answer this, I instrumented the code for the OVM 2.0 to log any time a transaction destroyed a contract with a balance."

"As SELFDESTRUCT is already a rare opcode, and this is even then a subset of all uses of SELFDESTRUCT—and further, as OVM 2.0 was only released three months ago—there was only a single user who had ever tried this: on Christmas Eve (2021)."

"In those transactions (as seen on the Optimism block explorer hosted by Etherscan) we see a user creating and destroying three contracts. The first two times, the contract's beneficiary is the 0x0 address, while the third time it is the user themself."

"It frankly felt like someone had noticed the bug—seeing that Etherscan left the balance in place after the contract was destroyed—and even played with it a bit (to see if this was a behavior of 0x0)... but hadn't realized it was exploitable."

"I actually managed to track down this user (!!) and it turns out they work for Etherscan ;P. It just goes to show that sometimes even people who are staring directly at a bug don't always see the indirect security implications."

Ultimate Outcome

"Software engineer Jay Freeman (who goes by Saurik online) didn’t leverage the exploit. Instead, he reported the issue to Optimism’s dev team." "On 2/2/2022, I reported a critical security issue to Optimism—an "L2 scaling solution" for Ethereum—that would allow an attacker to replicate money on any chain using their "OVM 2.0" fork of go-ethereum (which they call l2geth)."

A bounty of $2,100,000 USD was paid for the discovery. "[Optimism] paid him a $2-million bug bounty."

"We thank Jay Freeman (@saurik) for his amazing detective work in discovering and then reporting the print-ETH vulnerability to Optimism." "In appreciation for @saurik’s deep detective work on this critical vulnerability, we have offered him the maximum amount in our bug bounty program."

"Last week, I discovered (and reported) a critical bug (which has been fully patched) in @optimismPBC (a "layer 2 scaling solution" for Ethereum) that would have allowed an attacker to print arbitrary quantity of tokens, for which I won a $2,000,042 bounty."

"I'd missed the confirmation of this on Thursday, but @bobanetwork had decided to additionally extend to me their (maximum) $100k bug bounty payout, making the total reward for my Ethereum L2 bug--"Unbridled Optimism"--$2,100,042! (...I think this might actually set a new record?)"

"Optimism—whose platform currently uses a centralized "sequencer"—moved to both fix this bug on their nodes and infrastructure, as well as arrange for downstream projects that used their codebase (Boba and Metis) to get patched."

"Last week we patched a critical bug in the Optimism codebase, discovered by @saurik." "We’re incredibly thankful to saurik for spending so much time analyzing our protocol over the year--enough to find such an important fix! We highly recommend you check out his in-depth breakdown. We'll award the full $2,000,042 promised in our bug bounty."

"Optimism did a superb job fixing the vulnerability and working with all ORs and Infra providers to roll out a patch across the OR ecosystem within hours. Your funds are safe and Boba was patched within three hours of the vulnerability being reported."

Total Amount Recovered

There do not appear to have been any funds lost in this case.

Ongoing Developments

TBD

Individual Prevention Policies

This case does not appear to have resulted in a loss to any individual.

Individuals should avoid storing funds on smart contracts which have not been properly validated, and ideally store most funds offline while not being used.

Avoid the use of smart contracts unless necessary. Minimize the level of exposure by removing or withdrawing assets whenever possible. Aim to choose smart contracts which have obtained third party security audits, preferably having been audited by at least three separate reputable firms. Pay attention to the audit reports, which smart contracts are covered, and whether the smart contract has been upgraded or modified since the report. Ensure that any administrative functions with the ability to remove funds from the smart contract are under the authority of a multi-signature wallet which is controlled by at least three separate and reputable entities.

Store the majority of funds offline. By offline, it means that the private key and/or seed phrase is exclusively held by you and not connected to any networked device. Examples of offline storage include paper wallets (seed phrase or key written down and deleted from all electronic media), hardware wallets, steel wallet devices, etc...

For the full list of how to protect your funds as an individual, check our Prevention Policies for Individuals guide.

Platform Prevention Policies

This case does not appear to have resulted in a loss to any platform.

The issue was actually found and accidentally exploited (with no loss) 40 days prior to the report, and still remained uncaught. It is likely that more expert reviews would have caught the problem. Storing most funds in a multi-signature treasury would heavily limit the amount at risk. Finally, an industry insurance fund can assist any affected users.

All aspects of any platform should undergo a regular validation/inspection by experts. This validation should include a security audit of any smart contracts, reporting any risks to the backing (of any customer assets, ensuring treasuries or minting functions are properly secured under the control of a multi-signature wallet, and finding any inadequacies in the level of training or integrity of the team. The recommended interval is twice prior to launch or significant system upgrade, once after 3 months, and every 6 months thereafter. It is recommended that the third party performing the inspection not be repeated within a 14 month period.

All wallets, minting functions, and critical infrastructure should be implemented with a multi-signature requirement, with a recommended minimum of 3 signatures required. This means that making important changes or approving spending will require the keys held by at least 3 separate individuals within the organization to approve. The multi-signature should be implemented at the lowest layer possible, all key holders should have security training, and all key holders should be empowered and encouraged to exercise diligence.\

Work with other industry platforms to set up a multi-signature wallet with private keys held separately by delegate signatories from seven prominent platforms and services within the industry. Establish requirements for contributions by all platforms and services, designed to be affordable for small platforms yet large enough to cover anticipated breach events. Any breach event can be brought forth by a member platform or a petition of 100 signatures for consideration by the delegate signatories. A vote of 4 or more delegate signatures is required to release any funds, which could partially or fully restore lost funds based on their assessment.

For the full list of how to protect your funds as a financial service, check our Prevention Policies for Platforms guide.

Regulatory Prevention Policies

It does not appear that any funds were lost in this case.

The issue was actually found and accidentally exploited (with no loss) 40 days prior to the report, and still remained uncaught. It is likely that more expert reviews would have caught the problem. Storing most funds in a multi-signature treasury would heavily limit the amount at risk. Finally, an industry insurance fund can assist any affected users.

All platforms should undergo published security and risk assessments by independent third parties. Two assessments are required at founding or major upgrade, one after 3 months, and one every 6 months thereafter. The third parties must not repeat within the past 14 months. A risk assessment needs to include what assets back customer deposits and the risk of default from any third parties being lent to. The security assessment must include ensuring a proper multi-signature wallet, and that all signatories are properly trained. Assessments must be performed on social media, databases, and DNS security.

Set up a multi-signature wallet with private keys held separately by delegate signatories from seven prominent platforms and services within the industry. Establish requirements for contributions by all platforms and services within the country, designed to be affordable for small platforms yet large enough to cover anticipated breach events. Any breach event can be brought forth by a member platform or a petition of 100 signatures for consideration by the delegate signatories. A vote of 4 or more delegate signatures is required to release any funds, which could partially or fully restore lost funds based on their assessment.

For the full list of regulatory policies that can prevent loss, check our Prevention Policies for Regulators guide.