All smart contract security issues in one place: An introduction to the SWC Registry

The SWC Registry is an indispensable resource for securing your smart contracts. Here we show how you can use it most effectively.

In our last post, we showed you how you can use Remix with the MythX plugin to detect weaknesses in smart contract code.

Now, let’s talk about those weaknesses.

Smart contract weaknesses are classified into many different types, allowing for easier management and discussion. The code that generates the weakness may vary widely, but the type of weakness is the same.

This sort of thing isn’t unique to smart contracts, of course. The idea of “signatures” in an antivirus context has been around for decades, and the Common Weakness Enumeration (CWE), describes software weaknesses in much the same way.

But smart contracts, due to the specific nature of the blockchain, require specialized discussion. A weakness in software written in C++ is just not the same.

With this in mind, a group of developers, auditors, and researchers at Consensys Diligence (where MythX was originally developed) created an analog to the CWE called the SWC Registry, or Smart Contract Weakness Classification Registry.

The SWC Registry is designed to provide smart contract developers with both language and remediation steps for dealing with issues that come up in the smart contract secure development lifecycle (SDLC).

In the SWC Registry, each entry (what we call an “SWC”) has its own ID and signature, description, code samples and remediation steps. In short, the SWC Registry contains everything you need to know to fix your smart contracts. Plus, it is both open source and community-managed.

Now let’s take a look at the registry itself.

SWC Registry

The SWC Registry is found at swcregistry.io.

Its interface is very simple. The home page contains a list of every known smart contact weakness type, sorted by descending number of the SWC ID. At the time of writing, there are over two dozen entries in the registry. (The order is not significant.)

For each entry, there is the SWC ID, the title of the weakness, a relationship to other CWEs, and links to test cases.

More details can be found by clicking the SWC ID.

Now let’s take a look at one of the weaknesses found in our previous guide on testing a smart contract.

SWC-128: Denial of Service with Block Gas Limit

We’ll start with SWC-128: Denial of Service with Block Gas Limit.

This weakness states that it is possible to structure the contract in such a way that a transaction could potentially exceed the block gas limit, which would lead to a denial of service condition. The entry specifically highlights looping over every entry in an unbounded array.

This weakness is listed as being related to CWE-400: Uncontrolled resource consumption, and there are a number of references for further information.

More pragmatically, there is a code sample which shows a specific situation where an array can grow unbounded in a few different contexts.

A tool such as MythX can determine precisely where in your code this situation occurs. You can then use the remediation steps listed to alter your code to prevent this situation from occurring. In this case, the suggestion is to never loop across an entire data structure, but if you must, to plan for it to happen over multiple blocks/transactions.

SWC-107: Reentrancy

Here’s another SWC, the infamous SWC-107: Reentrancy.

The structure of this page is the same as before. First, the description of the weakness is stated; a malicious contract calls back into the calling contract before the first invocation of the function is finished.

This weakness is listed as being related to CWE-841: Improper Enforcement of Behavioral Workflow

As before, there are remediation suggestions and code samples, but in this case, the entry goes even further: in addition to code samples showing the problem, there are code samples showing how one would fix the problem. These are denoted by a file name with fixed in the title.

These are just two example SWC entries, but the rest of them work in much the same way.

Official status and contributions

The idea for the SWC Registry was floated in the Ethereum Improvement Proposal EIP-1470. It is currently still listed as Pending.

But we still feel that it is crucial for all tools and auditors to be “speaking the same language” when talking about smart contracts, so we seek to grow adoption of the SWC Registry and usage of SWCs themselves.

The SWC Registry isn’t a MythX product or a Consensys Diligence product; it is an Ethereum community resource. This means that it’s up to all of us—all of you—to keep this project alive.

You can view the SWC Registry repo on GitHub. We welcome all contributions, both edits to existing SWCs and new SWCs.

The smart contract space is very nascent, and we fully expect new weaknesses to be found over time. That’s why it’s important to test your contracts for weaknesses even after they’ve been deployed. While your smart contract may never change, the smart contract security landscape always will.

---

Thinking about smart contract security? We can provide training, ongoing advice, and smart contract auditing. Contact us.

All posts