Reentrancy in Ethereum Smart Contracts : methods and tools for detection

Abstract

Obwohl die Softwareschwachstelle Reentrancy schon seit mehreren Jahren in der Ethereum-Community bekannt ist, stellt sie dennoch nach wie vor ein Problem dar, wenn es um die Sicherheitsanalyse von Smart Contracts geht. Aus diesem Grund gibt es regelmäßige Veröffentlichungen in diesem Forschungsgebiet, die darauf abzielen, verbesserte Methoden zur Verhinderung oder Erkennung von Reentrancy vorzustellen. In dieser Arbeit versuchen wir, die bereits vorhandene Forschung in dem Gebiet zusammenzuführen und einen Überblick bereitzustellen, der die verschiedenen Arten von Reentrancy sowie die Code Patterns zur Vermeidung der Sicherheitslücke beschreibt, wobei der Fokus auf der Programmiersprache Solidity liegt. Weiters präsentieren wir verschiedene Ansätze zur Analyse von Smart Contracts und heben deren Stärken und Schwächen hervor. Eine Literatursuche, die auf einer vorhergehenden Arbeit basiert, wird genutzt, um die kürzlich entstandenen Publikationen in dem Bereich der Smart Contract-Analyse zusammenzutragen. Insgesamt identifizieren wir 104 neue Tools, die laut Angaben der Autoren geeignet sind, um Ethereum Smart Contracts auf Reentrancy zu untersuchen. Zusätzlich wählen wir anhand der gesammelten Informationen vier Analysetools, sowohl neuere als auch etabliertere, und testen diese auf einem für diese Arbeit geschriebenen Datenset bestehend aus Smart Contracts. Das Datenset enthält alle vier Arten von Reentrancy, die in der Arbeit behandelt werden, und deckt die Solidity-Versionen 0.4 bis 0.8 ab. Die Daten sind öffentlich auf GitHub verfügbar und beinhalten sowohl Quellcode als auch Bytecode. Die Ergebnisse unseres Experiments zeigen, dass alle vier Tools - Oyente, Mythril, eThor und Sailfish - Probleme bei der Erkennung verschiedener Arten von Reentrancy haben, und dass ihre Leistung stark variiert, je nachdem, ob nach Reentrancy-Typ, Solidity-Version oder Codetyp beurteilt wird. Während drei von vier Tools in der Lage sind, die einfachste Form von Reentrancy konsistent zu erkennen, so werden die komplexeren Formen nur von jeweils einem der Tools entdeckt. Unsere Ergebnisse legen nahe, dass es innerhalb der Ethereum-Community noch an Bewusstsein für die komplexeren Arten von Reentrancy mangelt, und dass die Kombination mehrerer Analysetools sowie das gezielte Aussuchen eines Tools basierend auf den Eigenschaften des zu testenden Contracts die besten Chancen bieten sollten, um Smart Contracts frei von Reentrancy zu halten.

Despite having been well known in the Ethereum community for many years, reentrancy still poses a problem when it comes to Smart Contract security analysis. For this reason, there are regular innovations in terms of newly proposed approaches to mitigate or detect this vulnerability. In this paper, we attempt to combine the available research on the topic by providing an overview of the identified types of reentrancy and the coding patterns used to avoid them, focusing on the programming language Solidity. Furthermore, we present different Smart Contract analysis approaches and highlight their strengths and weaknesses. A literature review based on previous work in the field is used to collect recent research on the topic. In total, we identify 104 new tools that, according to the authors, are suitable for reentrancy detection in Ethereum Smart Contracts. Furthermore, a combination of both recent and more established tools is selected and subsequently tested on a data set containing all four reentrancy types as well as five different Solidity versions, 0.4 to 0.8. The data set, which contains both source code as well as runtime bytecode, is built by hand specifically for this thesis and made available on GitHub. The results show that all four of the tools - Oyente, Mythril, eThor, and Sailfish - struggle with certain types of reentrancy and greatly vary in performance depending on whether the data is split by reentrancy type, Solidity version, or file type. While three out of four tools manage to consistently detect the simplest form of reentrancy, same-function reentrancy, the more complex types cross-function, delegated, and create-based reentrancy are detected by only one tool each. Our results suggest that there is a lack of awareness with regard to the more complex types of reentrancy within the tool development community, and that users wanting to keep their contracts secure might fare best by consulting multiple Smart Contract analysis tools or by tailoring their tool choice to the properties of the contract that is to be analyzed.