Bypassing Smart Contract Timelocks

Security
1

Originally published at: https://blog.openzeppelin.com/bypassing-smart-contract-timelocks/

cover_blog_flatsecurity_generic_simple-copy.png840Ă—473 9.58 KB

In this article we present a game theoretical attack against timelock incentive mechanisms.

Introduction

It is common for designers of smart contract systems to attempt to prevent stakeholders from divesting their interest in a project for some amount of time.

For example, after an ICO, the project owners may want to prevent the initial investors from dumping their newly-minted tokens on the open market for, say, 1 year. This keeps the investors’ incentives aligned with that of the project, at least until the year has passed. It may also put upward pressure on the market price of the tokens by limiting the circulating supply.

Here is another common example: A company may reward their founders with some tokens but require that the tokens vest over a 4 year period in order to keep the founder’s incentives aligned with that of the company.

In the Ethereum space, the most common way to achieve this goal of delaying the divesting of interest is to use a smart contract that implements a timelock. That is, they put the tokens into a contract with a beneficiary and a releaseTime and arrange matters so that only the beneficiary can receive the tokens and only after the releaseTime has passed.

In this article, we look at a game theoretical attack against smart contract timelock systems that allows the beneficiary (i.e., the early ICO investor or the company founder) to trustlessly sell their timelocked tokens without waiting for the timelock to expire.

The scope of the problem

It is important to note that the two attacks we’ll cover are not an exploitation of a vulnerability in the code of any smart contract timelock system (though modifications of the code can almost entirely prevent this attack, as we’ll discuss later). The attack does not require that the locked ETH or ERC20 tokens can somehow be moved before the timelock expires. Indeed, that is impossible if the timelock contract is coded properly.

Instead, we’re exploiting a vulnerability that exists at the mechanism-design level. In particular, we leverage the fact that almost all deployed smart contract timelock systems unintentionally allow for the trustless transfer of future ownership of the locked tokens without having to move the tokens.

Both attacks require the attacker to perform some setup before they become the beneficiary of the timelock contract. In particular, the attacker must first write an exploit contract and make sure that their exploit contract becomes the beneficiary of the timelock. So, if you have timelock contracts being used in production right now, and if it is not possible for the beneficiary addresses to be changed, then you don’t have to worry about your existing beneficiaries implementing this attack when they read this. They’ve either already gotten their exploit contracts listed as beneficiaries or they’ve missed their opportunity. But for any future timelocks you create, consider implementing the preventative measures described at the end of this article.

Finally, not all timelock mechanisms are intended to delay the divesting of interest. For example, some are used to impart delays to prevent race conditions or for other security reasons. The attacks described here are only for bypassing timelock incentive mechanisms and are unlikely to apply to timelocks used for other reasons.

The basic timelock setup

The implementation details of timelocks can vary greatly, but they all have two important elements in common: a beneficiary and a releaseTime. The timelock mechanism sets aside some amount of ETH/ERC20 tokens in such a way that they can be received only by the beneficiary address and only after the releaseTime has come to pass.

For the remainder of this article, we’ll use the following simple timelock contract as an example. To keep the code simple, we’ll deal with timelocking ETH instead of ERC20 tokens, but the exact same principles can be used for token timelocks as well.

This contract locks some amount of ETH and releases it to a beneficiary at some time in the future.

Note the following key properties of the SimpleTimelock contract. Any timelock contract with these 4 properties is susceptible to our attacks:

  1. The balance that will ultimately go to the beneficiary cannot decrease before the payout happens. In our example, the balance can increase, but that is not important. All that matters is that the balance cannot decrease.
  2. The beneficiary address cannot be changed by anyone who is not the beneficiary. In our example, it is also the case that the beneficiary herself cannot change the beneficiary address, but that is not important. All that matters is that anyone who is not the beneficiary cannot change the beneficiary address.
  3. Nobody can prevent the beneficiary from releasing the ETH once the releaseTime has passed. In our example, since the release function is public, anyone can cause the release to happen, but that is not important. All that matters is that at a minimum, the beneficiary is able to cause the funds to be released once the releaseTime has passed.
  4. The beneficiary address can be a contract address. There are no checks in place to ensure that the beneficiary is an externally owned account (EOA).

One way or another, the deployer of the timelock contract will collect a beneficiary address. Perhaps they do this automatically by grabbing msg.sender during a token sale. Or perhaps they simply ask the founder of the company to email them the address at which they want to receive their vesting tokens.

The important thing to point out here is that, while the deployer of the contract is the one passing the beneficiary parameter to the constructor function of the timelock contract, it is the beneficiary who ultimately decides what the beneficiary address will be.

In any case, the deployer collects the beneficiary address, deploys the timelock contract, and then funds the deployed contract.

Next, we look at two different attacks, a simple one and a more sophisticated one, that allow a malicious beneficiary to divest themselves of their timelocked ETH. That is, we’ll go over two different ways they can sell their timelocked ETH on the open market before the timelock has expired. Of course, these attacks can easily be adapted to ERC20 tokens or other timelocked assets.

A simple timelock bypass

Our attacker, Alice, is asked by the deployer of the SimpleTimelock contract for the address where she’d like to receive her ETH after the releaseTime expires in 2 years.
Alice deploys the following “Bypasser” contract and gives its address to the deployer of the SimpleTimelock contract. That is, Alice’s SimpleTimelock beneficiary becomes this contract:

A few things to note about this Bypasser contract:

  1. The contract has an owner, which starts off being Alice.
  2. At any time, the owner of the contract can call collect(), which transfers all ETH in the Bypasser contract to the current owner.
    This means that whoever the owner of the Bypasser contract is when the SimpleTimelock’s releaseTime has passed will be able to collect all the timelocked ETH!
  3. The owner can sell ownership of the contract to anyone. First, the owner calls setPrice to set the selling price. Then, anyone who wants to buy can call buyOwnership (while sending enough ETH to cover the price) and become the new owner.

With this contract in place as the SimpleTimelock beneficiary, all Alice has to do is publish & verify the SimpleTimelock and Bypasser contract code on Etherscan so that anyone can verify it.

After that, Alice should be able to (trustlessly) sell ownership of the Bypasser contract on the open market for a price equal to the discounted future value of the timelocked ETH, thereby divesting herself entirely of all her current interest in the timelocked tokens.

Understanding the simple bypass

Notice that Alice was able to divest herself of her interest even though the ETH never moved. She didn’t sell the timelocked ETH itself. She sold the future ownership of the ETH. The Bypasser contract didn’t magically make the timelocked ETH transferable — it made the future ownership of the timelocked ETH transferable.

The Bypasser contract is a trustlessly transferable and perfectly enforceable claim to the timelocked ETH. Alice divests by selling this claim on the open market. Since the claim is perfectly enforceable (at zero cost), the market price it ought to fetch should be the discounted future value of the timelocked ETH.

A more sophisticated bypass

It may be difficult for Alice to find potential buyers if the amount of ETH in the SimpleTimelock contract is very large. While selling a few hundred dollars worth of ETH to several small investors is easy, selling a large amount of ETH to a single large investor may require more effort.

Also, Alice may not want to divest herself of all of her interest. Perhaps she just wants to partially divest, to sell only a fraction of her timelocked ETH.

Furthermore, in some situations, the amount of ETH in the SimpleTimelock contract may increase over time. In these cases, if Alice sells the Bypasser contract before the amount of ETH in the SimpleTimelock contract increases, Alice will have lost out on the value of that additional ETH (to the happy surprise of the person to whom she sold it). This is not ideal for Alice.

To resolve all of these problems, Alice can tokenize her claim to the locked ETH. That is, she can use a more sophisticated version of the Bypasser contract that mints one AliceCoin for every one ETH to which the beneficiary is entitled. This modified Bypasser contract would — after the releaseTime of the SimpleTimelock contract has passed — allow owners of AliceCoin to cash in their AliceCoins for an equal amount of ETH.

The following contract, TokenizedBypasser, is an example of how this can be done:

So, Alice would deploy the TokenizedBypasser contract and give its address to the deployer of the SimpleTimelock contract. That is, this TokenizedBypasser contract would become the beneficiary of the SimpleTimelock contract.

Then, once the SimpleTimelock contract was deployed, Alice would pass its address to the setSimpleTimelockInstance function of the TokenizedBypasser contract.

From that point forward, anyone can cause the TokenizedBypasser contract to mint AliceCoin that is 100% backed by an equal amount of ETH. Also, any owner of AliceCoin can be 100% certain that they will be able to cash in their AliceCoin for an equal amount of ETH once the releaseTime has passed.

Additionally, if the SimpleTimelock contract receives any more ETH, the TokenizedBypasser will allow more AliceCoin to be minted in response.

In this way, Alice has created a new token — AliceCoin — that is fully backed by (and trustlessly redeemable for) her timelocked ETH. She can sell any portion of it she wants to other investors. Additionally, if at any time the SimpleTimelock contract receives more ETH, Alice will be able to use that to back the minting of more AliceCoin.

Holders of AliceCoin are 100% guaranteed that they’ll be able to cash in their AliceCoin for an equal amount of ETH once the releaseTime has passed. Therefore, the market price of a single AliceCoin should be the discounted future value of one timelocked ETH. Alice can thus divest her current interest in the timelocked ETH by seller her AliceCoins on the open market.

How we can prevent timelock bypassing

Recall from the “The basic timelock setup” section that the following four properties of the timelock contract are necessary for this attack to work:

  1. The balance that will ultimately go to the beneficiary cannot decrease before the payout happens.
  2. The beneficiary address cannot be changed by anyone who is not the beneficiary.
  3. Nobody can prevent the beneficiary from receiving the ETH once the releaseTime has passed.
  4. The beneficiary address can be a contract address.

Removing any of these properties from our timelock contract will neutralize our bypass attack. However, properties 1-3 are almost always critical to the incentive alignment we’re attempting to achieve with the timelock to begin with. Therefore, the removal of those properties should be off the table.

That leaves property 4: The beneficiary address can be a contract address.

To prevent the bypassing attack without threatening our intended incentive alignment, we can simply modify the timelock contract so that the beneficiary address cannot be a contract address.

There are two common ways to do this:

Prevention Method #1: msg.sender == tx.origin

If the deployer of the timelock contract is setting the beneficiary of the timelock as the msg.sender of some transaction, then they can simply require msg.sender == tx.origin before setting the beneficiary to msg.sender. Since tx.origin is always an EOA, we know it cannot be a contract.

While this approach is simple, it has some downsides. First, it requires that the beneficiary has ETH (for gas) in their beneficiary address because they need to initiate a transaction in order to set the beneficiary address.

Second, it limits the design space of the timelock contract. In particular, it requires that the timelock (or some other contract) first be deployed and that the beneficiary sends a transaction to it.

Finally, Vitalik has suggested that developers should “NOT assume that tx.origin will continue to be usable or meaningful.” To remain future-proof, we should avoid leaning on tx.origin whenever possible.

Prevention Method #2 (recommended): ecrecover(m, v, r, s)

Rather than using msg.sender as the beneficiary address, the timelock contract can instead require that a message and signature be passed. The timelock contract can extract the beneficiary address from a valid signature using ecrecover. Since only EOAs can create valid signatures, this ensures that the beneficiary is not a contract. OpenZeppelin provides an ECDSA library with a recover function that wraps ecrecover and makes it easier to use.

This method is nice because it doesn’t require that the beneficiary address has ETH for gas. They can simply sign a message and pass it to the deployer of the timelock contract. It also gives the designer of the timelock contract more flexibility because they can collect and submit the signatures in any number of ways. They don’t necessarily have to set the beneficiary address at the same time the beneficiary sends a transaction to their contract.

An important caveat to this approach is that we should not allow the signed message, m, to be any arbitrary message. If we allow m to be any arbitrary message, then a malicious beneficiary could use Nick Johnson’s method to create a one-time-use EOA that can provably do only one thing: sign a transaction that forwards ETH to a Bypasser contract. If that signed transaction is used as the message m, then we end up right back where we started: The future control of the locked tokens would rest with a Bypasser contract. So we have to prevent the beneficiary from being a contract and also prevent it from being a one-time-use EOA that forwards ETH/tokens to a contract. There are two easy ways to do this.

First, you can simply require that the message being signed is a message that cannot be parsed as an Ethereum transaction. For example, you could require the beneficiary to sign the message, “This is an EOA.” Since a one-time-use EOA can sign only a single message, this would ensure that the signing address is not a one-time-use EOA that forwards to a contract.

Second, if for some reason you do want to accept arbitrary messages, you could simply require that the beneficiary sign two distinct messages. Since one-time-use EOAs cannot sign more than one message, we know that any address that signs two distinct messages is a non-one-time-use EOA.

Finally, remember that any time you are using ecrecover you should always require that the signer present the original message being signed — not just the hash. If the signer is allowed to present a signed hash without also presenting its preimage then they can produce “valid” signatures for any address.

OpenZeppelin Contracts may soon be adding EOA-verification functionality, so you’ll be able to implement these protections easily.

Limitations on prevention

It is always possible for a beneficiary of a timelock to perform an attack similar to this (assuming properties 1-3 of the “The basic timelock setup” hold), even if their beneficiary address is a non-one-time-use EOA. For example, the beneficiary can create a traditional legal contract (no blockchain required) that promises their timelocked tokens to some third party. There is nothing any smart contract could do to prevent that.

However, such traditional methods are not trustless. They depend on the enforceability of (and the cost of enforcing) the legal contract. These limitations would negatively affect the price Alice could fetch for her locked coins as well as greatly limit the number of investors to whom she could sell. That being said, these more traditional bypasses are always possible and cannot be prevented with code.

On the other hand, the trustless bypassing methods are preventable using the recommendations we mentioned above.

Credit where it’s due

I believed this is a little-known idea. However, it is certainly not an original idea. Indeed, I have a vague memory of someone performing an attack like this during one of the late 2017 ICOs and then posting an offer to sell his “claim” to the timelocked tokens on Twitter. The idea has stuck with me ever since, and I only recently decided to write about it. Despite my best efforts, I’ve been unable to find those old tweets or any other examples of this attack being performed in the wild. However, I know they’re out there.

If you can point to any examples of this kind of attack being performed in the wild, please let us know in the comments!

Conclusion

Any timelock incentive mechanism that has the four key properties listed in the “The basic timelock setup” section can be bypassed by malicious beneficiaries. We can prevent the most damaging and easy-to-execute versions of these bypassing attacks by requiring that all beneficiary addresses be non-one-time-use EOAs.

8 Likes
2

Great write up @Austin-Williams! This post is really helpful :slight_smile:

1 Like
3

Thanks! It looks like the contract examples didn’t copy/paste over from the original blog post.

The SimpleTimelock contract (the one that we’re attempting to bypass) is here:
https://gist.github.com/Austin-Williams/69bf064683c604c294addeb934c945b1#file-simpletimelock-sol

The simple Bypasser contract (the one we use to bypass the SimpleTimelock contract) is here:
https://gist.github.com/Austin-Williams/3e757dccd62d329401c26e287c0b9dae#file-attack1-sol

And the more advanced Bypasser contract (the one that tokenizes future ownership) is linked to in my next comment (because I can’t post more than two links per post as a new user).

2 Likes
4

And the more advanced Bypasser contract (the one that tokenizes future ownership) is here:
https://gist.github.com/Austin-Williams/5558078d0f60d7ff636256596ae6f7f6#file-tokenizedbypasser-sol

2 Likes
5

I generally look at the ability to recursively tokenize interest in an asset as a powerful feature - but this was an interesting read. I have read more than a handful of times that distinguishing between EOAs and contracts will get harder in Serenity and, as you mentioned, to generally avoid tx.origin.

You address the latter concern, but would the former cause any sort of issues for your ecrecover method of rejecting contracts?

Thanks for sharing this!

2 Likes
6

I generally look at the ability to recursively tokenize interest in an asset as a powerful feature

I generally agree. It's one of the reasons I found this particular issue so interesting. It's a strange case where the design goal is to prevent the user from selling something they own.

I have read more than a handful of times that distinguishing between EOAs and contracts will get harder in Serenity

I've read this too, but I haven't yet dug into exactly why it will be harder to distinguish between the two account types. The details there are critical to answering your question of whether the ecrecover techniques will work in Serenity.

If you (or anyone) can link to any good resources related to how contract-vs-EOA detection will be effected by changes brought by Serenity, please do. It's something I'd love to dive into more deeply.

3 Likes
7

I have added the Gists and will change the number of links you can post. :smile:

2 Likes
8

Thank you. I appreciate that. :slight_smile:

2 Likes
9

To add to the existing caveats about tx.origin: if account abstraction is introduced in the future, tx.origin could eventually be a contract.

2 Likes
10

One thing that has been overlooked here is that some beneficiaries may use smart contract wallets. For example, if a company receives time-locked tokens they may want to have a multisig contract for those tokens so the CEO and CFO or Chairman of the board have to sign off on spending them once they've vested. This mechanism would prevent this option.

2 Likes