When it comes to smart contract security on the Ethereum blockchain, a good place for anyone to start is with software that analyzes the contract byte-code. After all, most people who want to write contracts in Solidity can’t afford the time to become a smart contract security expert. And for many, hiring a consultant to audit your code may prove too costly. However, anyone harboring the ability to deploy their own smart contracts should also be capable of testing their code via automated analysis software. And while reading stories of Ponzi schemers losing hundreds of thousand in USD is fairly entertaining, the entire community will be much better off if we can adopt a few simple security standards before deploying our code to the quasi-immutable production environment we all share.
Currently, compared to the tradition web development space, the Ethereum development space is tiny. There are only a handful of security tools to choose from and Consensys even keeps a small curated list. While the list includes available linters and code-coverage tools, I’m more interested in static analysis tools that can help us pinpoint known security vulnerabilities. Out of the tools listed, there are only a couple of open-source libraries capable of analyzing our smart contracts for known threats: Oyente from Melon & Mythril from Consensys. Let’s have a close look at our 2 contenders!
How should we evaluate these libraries? Well, why not run both libraries through their paces by auditing a suite of contracts with known security vulnerabilities. Thankfully, online smart contract hacking challenges, like Open Zeppelin’s Ethernaut & HackThisContract have made it easy to collate sample vulnerable contracts. After running the libraries against each contract, I recorded the security threats they raised, and assessed whether or not they accurately identified the known vulnerability. Here are the results of Oyente v0.2.7 vs Mythril v0.8.6…
Neither library catches everything, but Mythril is catching more issues that Oyente isn’t. While it’s unlikely that any static library will ever be capable of capturing contract pitfalls due to poor design in contract logic — which are definitely present in a few of the contracts shown above — Mythril is still catching attack vectors dealing with integer underflows and weak randoms that Oyente is missing.
A few additional issues with Oyente v0.2.7 include:
Mythril also comes with a collection of test contracts in its gihub repo. How does Oyente handle the Mythril contracts? Well, I’ve got those results, too…
So, before asking someone else to put their money into your smart contract, you should at the very least run it through Mythril. Bernhard Mueller has done a magnificent job as the main developer of the library. And, if installing the python library proves too much of a challenge, I’ve also taken the liberty of creating a docker image.
Remember that using a library to analyze your code is NOT a substitute for human auditing, and common sense. If you’re going to be responsible for handling any amount of someone else’s money, you should be using libraries like OpenZeppelin, which is doing a great job at providing higher-level functions to keep developers from making silly mistakes like using +/- for arithmetic operations. If you can afford the time, you should also check out the plethora of articles on smart contract security from the informed blockchain veterans at Consensys. And if you can afford the investment, it might also be worth having an expert audit your contract, or offer a bug bounty.
I’d also like to give a shout-out to Haseeb Qureshi who wrote an amazing article which ignited my interest in smart contract security.
It should also be noted, that the above tests were run on the source code of the contract, and not on the deployed bytecode. As mentioned by the project lead of Mythril, Bernhard Mueller, Mythril should catch a few more of the Ethernaut bugs, at least “Fallout” and “Delegation”. For delegation, you need to deploy and link the contracts first and run an on-chain analysis, because Mythril can’t tell the interdependencies from the source code.
Side note: I am also one the aforementioned “Ponzi scheme participants” who lost some Ethereum due to a vulnerable smart contract written in haste. Special thanks to Peter Kinnaird for leading me to it! Would play again. And, in case you’re wondering, here’s the analysis of the PonziCoin contract…
