/sereum-results

Raw Data from Evaluation of Sereum Re-Entrancy Detection (NDSS19)

Primary LanguagePython

Sereum Evaluation Data v2

The data in this repository was produced during a research collaboration of NEC Labs Europe and University of Duisburg-Essen, which resulted in the publication of the NDSS19 paper "Sereum: Protecting Existing Smart Contracts Against Re-Entrancy Attacks".

This repository contains raw and processed data of an extended evaluation of Sereum v2. This includes basic unconditional reentrancy detection and covering more blocks of the ethereum mainnet until block number 9069001.

The structure of the repository is:

  • ./raw/ contains the raw data of running Sereum against transactions
  • ./analysis/ contains data generated during analysis including transaction traces, contract sources, etc.
  • contracts.md is a list of contracts, which were flagged vulnerable by Sereum
  • fp_types.md contains short descriptions for the major types of false positives

Note: This repository uses git lfs, be sure to install it! If you have trouble cloning the repository try the zip-file download.

Citing in Academic Work

If you want to refer to this data in academic work, please cite our NDSS paper:

@inproceedings{sereum-ndss19,
  title     = "Sereum: Protecting Existing Smart Contracts Against Re-Entrancy Attacks",
  booktitle = "Proceedings of the Network and Distributed System Security Symposium ({NDSS'19})",
  author    = "Rodler, Michael and Li, Wenting and Karame, Ghassan O and Davi, Lucas",
  year      =  2019
}

Results Summary

TODO

Reporting Re-Entrancy at Call-Depth 0

Any re-entrancy attack always starts with the execution of an attacker contract, i.e., the callchain A -> V -> A with A being the "Attacker" and V being the "Victim". Therefore, a simple heuristic that easily reduces false positives is to not report re-entrancy at call-depth 0, i.e., for call chains like V -> X -> V, where X is some external contract. However, doing this leads to skewed results regarding the quality of the detection methodology. The same false positive would be detected when another contract is involved, i.e., the call chain looks like Y -> V -> X -> V. Here this heuristic wouldn't be valid anymore (Y could be an attacker). Note that in this dataset we report also at re-entrancy at call-depth 0 (i.e., the flagged contract is in the to field of the transaction). We believe this will uncover more false positive patterns and as such give a better insight into the limits of a detection method. If you want to compare Sereum to another analysis tool, you should double check how the other analysis tool works and if it features this simple heuristic, exclude all transactions flagged by Sereum where this is applicable (i.e., externalcalldepth == 0 in the CSVs in this repository).

contracts.limited.md is a list of Sereum's results with this heuristic applied.

Details on the Analysis

The results in this repository were generated by running an improved version of Sereum on all transactions recorded on the Ethereum mainnet. We then further post-processed the reported transactions, such that they are suitable for detailed manual analysis. This includes scraping all related contracts from etherscan.io or applying the eveem.org decompiler if no source is available.

However, there are too many contracts and transaction in this dataset to perform an in-depth investigation on all of them. As such, for most of the contracts there is currently no manual analysis report.

  • analysis/README.md explains the rough directory structure of the analysis data.
  • contracts.yaml is a mapping of smart contract addresses to a human readable name and whether the contract has been verified to be genuinely attacked with a reentrancy attack.