OpenZeppelin Timelock Reentrancy Vulnerability

Notice: This page is a freshly imported case study from the original repository. The original content was in a different format, and may not have relevant information for all sections. Please help restructure the content by moving information from the 'About' section to other sections, and add any missing information or sources you can find. 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!

OpenZeppelin

It was uncovered that OpenZeppelin, a well-known smart contract audit provider, had a critical vulnerability in their smart contract, which would have allowed privilege escallation. This was found through a bug bounty program, and not exploited, so no funds were lost. A significant number of projects all had the same vulnerability, as it was commonly used code.

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

About OpenZeppelin

"The standard for secure blockchain applications. OpenZeppelin provides security products to build, automate, and operate decentralized applications. We also protect leading organizations by performing security audits on their systems and products."

"The TimelockController is used as the owner of controlled contracts (e.g. some configuration contract of DeFi protocol). Whenever a call is to be made on controlled contract (e.g. to update some configuration parameters) it is scheduled via TimelockController contract and delayed in time. It allows any users to react to change and either accept it or withdraw their assets if they do not agree with the change."

"Whitehat Zb3 submitted a critical reentrancy vulnerability in OpenZeppelin’s TimelockController contract on August 21, 2021." "This is the only critical vulnerability that OpenZeppelin has ever had in its open source smart contract library to the best of its knowledge."

"[T]he vulnerability “allows an actor with the executor role to escalate privileges”." "The root cause of the vulnerability is that it does not follow the well-known Check-Effects-Interactions pattern."

"Proposal execution firstly executes function calls (Interactions) and then checks whether these function calls should be executed, in _afterCall function (Checks). If you are able to bypass the check using function calls you can call any function on behalf of the timelock controller contract."

"First, the attacker, who has the EXECUTOR role, must be able to schedule execution that will be accepted with no delay. Fortunately (for the attacker of course), there is a updateDelay function that allows to set the minimum delay to 0, thus allowing execution of a proposal in the same block."

"Second, the TimelockController inherits from AccessControll and has the grantRole function which is quite powerful, because it allows to manage the contract. Also, the TimelockController is an admin of itself so the attacker is able to manage the controller."

"Third, in order to bypass the isOperationReady check, the attacker must schedule a batch function calls that corresponds to the exploit. To avoid recursion, the attacker can use another contract and call TimelockConroller indirectly."

"OpenZeppelin has graciously paid the whitehat a bounty of $25,000 for their contribution to community security and issued a patch." "When you look at the source code of the commit, you will see only one change: isOperationReady check added in _beforeCall function."

"OpenZeppelin has released an updated contract version which fixes the vulnerability." "Contracts v4.3.1 is out, fixing a security vulnerability in the TimelockController smart contract. All projects using TimelockController should migrate. The latest version is available on Github."

"Immunefi and OpenZeppelin proceeded to responsibly disclose the vulnerability to as many of the affected projects as possible, identifying and contacting 20 high risk projects out of a total of 316 instances of the TimelockController across numerous chains."

"[W]e found no cases of malicious exploitation of the vulnerability and no critical instances of the vulnerability containing funds at risk."

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

The background of the exchange platform, service, or individuals involved, as it would have been seen or understood at the time of the events.

Include:

• Known history of when and how the service was started.
• What problems does the company or service claim to solve?
• What marketing materials were used by the firm or business?
• Audits performed, and excerpts that may have been included.
• Business registration documents shown (fake or legitimate).
• How were people recruited to participate?
• Public warnings and announcements prior to the event.

Don't Include:

• Any wording which directly states or implies that the business is/was illegitimate, or that a vulnerability existed.
• Anything that wasn't reasonably knowable at the time of the event.

There could be more than one section here. If the same platform is involved with multiple incidents, then it can be linked to a main article page.

The Reality

This sections is included if a case involved deception or information that was unknown at the time. Examples include:

• When the service was actually started (if different than the "official story").
• Who actually ran a service and their own personal history.
• How the service was structured behind the scenes. (For example, there was no "trading bot".)
• Details of what audits reported and how vulnerabilities were missed during auditing.

What Happened

The specific events of the loss and how it came about. What actually happened to cause the loss and some of the events leading up to it.

Key Event Timeline - OpenZeppelin Timelock Reentrancy Vulnerability

Date	Event	Description
August 21st, 2021 12:00:00 AM	Main Event	Expand this into a brief description of what happened and the impact. If multiple lines are necessary, add them here.

Total Amount Lost

No funds were lost.

How much was lost and how was it calculated? If there are conflicting reports, which are accurate and where does the discrepancy lie?

Immediate Reactions

How did the various parties involved (firm, platform, management, and/or affected individual(s)) deal with the events? Were services shut down? Were announcements made? Were groups formed?

Ultimate Outcome

What was the end result? Was any investigation done? Were any individuals prosecuted? Was there a lawsuit? Was any tracing done?

Total Amount Recovered

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

What funds were recovered? What funds were reimbursed for those affected users?

Ongoing Developments

What parts of this case are still remaining to be concluded?

Prevention Policies

This demonstrates the effectiveness of bug bounty programs at incentivizing source code review by skilled white hackers, and also reinforces that smart contract hot wallets cannot be guaranteed to be safe, even if audited and in wide use.