GUSD smart contract allows for theft of antispam payments

Exploring front-running to capture the Gemini dollar’s antispam stake.

Exploring front-running to capture the Gemini dollar’s antispam stake.

The Winklevoss twins are best known as the alleged founding fathers of Facebook — and even received $65 million in compensation from Mark Zuckerberg in 2008. In 2013 they invested heavily in Bitcoin, buying about 1% of all existing coins at $120 apiece.

Soon after, the brothers opened the Gemini cryptocurrency exchange, and in 2018 they launched the stablecoin Gemini dollar (GUSD). A stablecoin is a fixed-rate cryptocurrency — 1 GUSD token always costs 1 US dollar. Stablecoins are handy for “digitizing” real dollars. They make moving blockchain dollars between exchanges quick and easy. The guarantor of the reverse conversion to dollars is the company that issued and sold them to you.

Under the Kaspersky Smart Contract Source Code Review service, we analyzed a smart contract that provides GUSD functionality, and we detected a flaw.

Disclaimer

Note that the given smart contract had already been reviewed, although we do not know if any code flaws were described in the report.

In line with our Responsible Disclosure Policy, we contacted Gemini’s security team to report the problem. They informed us the issue was considered during the design phase but presented no risk to GUSD.

For a simple explanation of how smart contracts work, see our post on smart contracts, Ethereum, and ICOs.

Gemini dollar smart contracts

Generally speaking, when someone wants to create new tokens based on the Ethereum blockchain, they write a smart contract (a miniprogram) that specifies the following:

  1. Data (“this many tokens are at such-and-such address),
  2. Methods (“please transfer my tokens to such-and-such address,” plus a few others).

The creators of the Gemini dollar system implemented the following enhancements as well:

  1. They separated the contract into three components: Proxy (the permanent interface with which token holders can interact and perform operations), store (the mapping of token holders to their balances), and Impl (the underlying logic);
  2. The component describing the logic can be updated and supplemented with new features such as the ability to freeze funds. Meanwhile, the data and interface remained unchanged; the update is transparent to everyone;
  3. For updating and control, a separate, “Custodian” smart contract is used that is managed by several people (custodians) for additional protection. If one custodian proposes an action, the others must confirm before the action can take place.

The enhancements are sound and increase overall security and flexibility.

Antispam payments

If someone other than the primary custodian enters a proposal in a custodian contract, they must pay a 1 ETH stake (about $200 at the current exchange rate). As noted in the comments to the contract itself, this antispam measure aims to dissuade participants from creating too many requests.

The antispam payments ultimately go to one person: the one who announces the approval of a particular proposal/request. This implementation may not look terrifically fair, but the comments clearly indicate that its creators conceived it that way.

        } else {
            if (address(this).balance > 0) {
                // reward sender with anti-spam payments
                // ignore send success (assign to ʹsuccessʹ but this will be overwritten)
                success = msg.sender.send(address(this).balance);

For our part, we recommend using the Solidity Withdrawal Pattern approach.

Front-running attackers can steal all antispam payments

The person who determines the approval of the request thus also receives all ETH antispam payments. To do so, he or she calls the smart contract function completeUnlock and passes the signatures of two custodians in the parameters.

The problem is that Ethereum, like any other blockchain, executes requests on a delay. A client transaction (transferring money or calling a function) waits in line for some time (usually 15 seconds or longer). During this time, absolutely anyone can view the planned transfers of other Ethereum users, including amounts, recipients, and parameters. And the peeper can use this information to create their own transaction and push it to the front by paying a higher commission to the miner.

Any advantage gained through peeping is considered front-running, a form of attack (Known Attacks: Front-Running).

From investopedia.com:

Front-running is when a broker or other entity enters into a trade because they have foreknowledge of a big nonpublicized transaction that will influence the price of the asset, resulting in a likely financial gain for the broker. It also occurs when a broker or analyst buys or sells shares for their account ahead of their firm’s buy or sell recommendation to clients.

In our case, a complete outsider can set up a robot to monitor the custodian contract. If it sees that someone called the completeUnlock function (that is, a custodian is interacting with Gemini dollar), it immediately copies all of the parameters and calls the function to extract the Ether that has accumulated there.

To counter such an attack, we again recommend using the popular Solidity Withdrawal Pattern approach.

On top of that, we recommend blocking unknowns from calling a function intended for custodians.

Practical implementation of an attack

Although dangerous in theory, the detected vulnerability is fairly benign in practice. Here’s why:

  1. Antispam payments are of little concern to custodians of such a major venture as the Gemini dollar. GUSD capitalization (the total volume of issued tokens) at one point topped $100 million. Even now it exceeds $5 million.
  2. Antispam payments have not yet appeared in this contract and may never do so, because the primary custodian is in no way obliged to deposit them (all others are).
  3. Knowing about the vulnerability, users can simply avoid the vulnerable function, or update the contract.
  4. During the review, we found no vulnerabilities that threaten GUSD tokens.

Gemini comments: “We chose this design because Gemini does not intend to stake ether under normal conditions, and, as a result, we made a risk-based decision not to materially expand the complexity of our codebase solely for the immaterial benefit of a more robust recovery mechanism for a theoretical, and nominal, anti-spam stake. Prioritizing secure, simple code remains the best solution for the Gemini dollar and its users. In the future we may revisit this decision if the risk changes and a more costly and complex contract becomes appropriate.”

We decided to publish this post in coordination with Gemini, given that antispam stakes are at risk only through a combination of specific and unlikely circumstances, and GUSD is not at risk.

Again, we remind everyone of the need for a holistic security approach to ICOs and other activities related to cryptocurrencies and blockchains.

Tips