Expand introduction, add lessons, clear bibliography

SemSEreport/exercise.bib

@@ -1,83 +1 @@
-@INPROCEEDINGS{smartian,
-	author={Choi, Jaeseung and Kim, Doyeon and Kim, Soomin and Grieco, Gustavo and Groce, Alex and Cha, Sang Kil},
-	booktitle={2021 36th IEEE/ACM International Conference on Automated Software Engineering (ASE)},
-	title={SMARTIAN: Enhancing Smart Contract Fuzzing with Static and Dynamic Data-Flow Analyses},
-	year={2021},
-	volume={},
-	number={},
-	pages={227-239},
-	doi={10.1109/ASE51524.2021.9678888}}
 
-@inproceedings{fuzzdrivegen,
-	author = {Pani, Siddhasagar and Nallagonda, Harshita Vani and Vigneswaran and Medicherla, Raveendra Kumar and Rajan M},
-	title = {SmartFuzzDriverGen: Smart Contract Fuzzing Automation for Golang},
-	year = {2023},
-	isbn = {9798400700644},
-	publisher = {Association for Computing Machinery},
-	address = {New York, NY, USA},
-	url = {https://doi.org/10.1145/3578527.3578538},
-	doi = {10.1145/3578527.3578538},
-	abstract = {Greybox fuzzers require intermediate programs called fuzz drivers to test smart contract APIs. These fuzz drivers use the semi-random inputs (bytes) generated by fuzzers to prepare suitable inputs required to test APIs. Further, fuzz driver also uses this input to decide sequence in which APIs to be invoked and enables the fuzzer to execute the APIs in that sequence to find the vulnerabilities, if any. Manually writing such complex and intelligent fuzz drivers is laborious, requires deep technical skills, hence can be cumbersome and error prone. In this paper, we propose SmartFuzzDriverGen framework to automatically generate fuzz drivers which invoke smart contract APIs using different strategies: unit-level, sequence-based (random, user-defined), and heuristics based. We evaluate the proposed framework by testing a prototype implementation of it with Golang smart contracts (targeted for Hyperledger Fabric platform) and study the effectiveness of the generated fuzz drivers in terms of code coverage as well as bug finding abilities. We observed that fuzzing of APIs in random sequences performed better than the other methods.},
-	booktitle = {Proceedings of the 16th Innovations in Software Engineering Conference},
-	articleno = {14},
-	numpages = {11},
-	keywords = {smart contracts, vulnerability detection, automated driver generation, blockchain, fuzzing, sequencing},
-	location = {Allahabad, India},
-	series = {ISEC '23}
-}
-
-@inproceedings {teether,
-	author = {Johannes Krupp and Christian Rossow},
-	title = {{teEther}: Gnawing at Ethereum to Automatically Exploit Smart Contracts},
-	booktitle = {27th USENIX Security Symposium (USENIX Security 18)},
-	year = {2018},
-	isbn = {978-1-939133-04-5},
-	address = {Baltimore, MD},
-	pages = {1317--1333},
-	url = {https://www.usenix.org/conference/usenixsecurity18/presentation/krupp},
-	publisher = {USENIX Association},
-	month = aug
-}
-
-@inproceedings{securify,
-	author = {Tsankov, Petar and Dan, Andrei and Drachsler-Cohen, Dana and Gervais, Arthur and B\"{u}nzli, Florian and Vechev, Martin},
-	title = {Securify: Practical Security Analysis of Smart Contracts},
-	year = {2018},
-	isbn = {9781450356930},
-	publisher = {Association for Computing Machinery},
-	address = {New York, NY, USA},
-	url = {https://doi.org/10.1145/3243734.3243780},
-	doi = {10.1145/3243734.3243780},
-	abstract = {Permissionless blockchains allow the execution of arbitrary programs (called smart contracts), enabling mutually untrusted entities to interact without relying on trusted third parties. Despite their potential, repeated security concerns have shaken the trust in handling billions of USD by smart contracts. To address this problem, we present Securify, a security analyzer for Ethereum smart contracts that is scalable, fully automated, and able to prove contract behaviors as safe/unsafe with respect to a given property. Securify's analysis consists of two steps. First, it symbolically analyzes the contract's dependency graph to extract precise semantic information from the code. Then, it checks compliance and violation patterns that capture sufficient conditions for proving if a property holds or not. To enable extensibility, all patterns are specified in a designated domain-specific language. Securify is publicly released, it has analyzed >18K contracts submitted by its users, and is regularly used to conduct security audits by experts. We present an extensive evaluation of Securify over real-world Ethereum smart contracts and demonstrate that it can effectively prove the correctness of smart contracts and discover critical violations.},
-	booktitle = {Proceedings of the 2018 ACM SIGSAC Conference on Computer and Communications Security},
-	pages = {67–82},
-	numpages = {16},
-	keywords = {smart contracts, stratified datalog, verification, security analysis},
-	location = {Toronto, Canada},
-	series = {CCS '18}
-}
-
-@MISC{
-	doughoyte,
-	author = {doughoyte},
-	title = {MerdeToken: It's Some Hot Shit},
-	note = {\url{https://github.com/Arachnid/uscc/tree/master/submissions-2017/doughoyte} [Accessed: Oct. 27th 2023]}
-}
-
-@article{multilayer,
-author = {Duan, Li and Sun, Yangyang and Zhang, Ke-Jia and Ding, Yong},
-year = {2022},
-month = {02},
-pages = {},
-title = {Multiple-Layer Security Threats on the Ethereum Blockchain and Their Countermeasures},
-volume = {2022},
-journal = {Security and Communication Networks},
-doi = {10.1155/2022/5307697}
-}
-
-@inproceedings{Kalra2018ZEUSAS,
-  title={ZEUS: Analyzing Safety of Smart Contracts},
-  author={Sukrit Kalra and Seep Goel and Mohan Dhawan and Subodh Sharma},
-  booktitle={Network and Distributed System Security Symposium},
-  year={2018},
-}

SemSEreport/exercises.bbl

@@ -1,52 +1 @@
-\begin{thebibliography}{1}
 
-\bibitem{smartian}
-Jaeseung Choi, Doyeon Kim, Soomin Kim, Gustavo Grieco, Alex Groce, and Sang~Kil
-  Cha.
-\newblock Smartian: Enhancing smart contract fuzzing with static and dynamic
-  data-flow analyses.
-\newblock In {\em 2021 36th IEEE/ACM International Conference on Automated
-  Software Engineering (ASE)}, pages 227--239, 2021.
-
-\bibitem{doughoyte}
-doughoyte.
-\newblock Merdetoken: It's some hot shit.
-\newblock
-  \url{https://github.com/Arachnid/uscc/tree/master/submissions-2017/doughoyte}
-  [Accessed: Oct. 27th 2023].
-
-\bibitem{multilayer}
-Li~Duan, Yangyang Sun, Ke-Jia Zhang, and Yong Ding.
-\newblock Multiple-layer security threats on the ethereum blockchain and their
-  countermeasures.
-\newblock {\em Security and Communication Networks}, 2022, 02 2022.
-
-\bibitem{Kalra2018ZEUSAS}
-Sukrit Kalra, Seep Goel, Mohan Dhawan, and Subodh Sharma.
-\newblock Zeus: Analyzing safety of smart contracts.
-\newblock In {\em Network and Distributed System Security Symposium}, 2018.
-
-\bibitem{teether}
-Johannes Krupp and Christian Rossow.
-\newblock {teEther}: Gnawing at ethereum to automatically exploit smart
-  contracts.
-\newblock In {\em 27th USENIX Security Symposium (USENIX Security 18)}, pages
-  1317--1333, Baltimore, MD, August 2018. USENIX Association.
-
-\bibitem{fuzzdrivegen}
-Siddhasagar Pani, Harshita~Vani Nallagonda, Vigneswaran, Raveendra~Kumar
-  Medicherla, and Rajan M.
-\newblock Smartfuzzdrivergen: Smart contract fuzzing automation for golang.
-\newblock In {\em Proceedings of the 16th Innovations in Software Engineering
-  Conference}, ISEC '23, New York, NY, USA, 2023. Association for Computing
-  Machinery.
-
-\bibitem{securify}
-Petar Tsankov, Andrei Dan, Dana Drachsler-Cohen, Arthur Gervais, Florian
-  B\"{u}nzli, and Martin Vechev.
-\newblock Securify: Practical security analysis of smart contracts.
-\newblock In {\em Proceedings of the 2018 ACM SIGSAC Conference on Computer and
-  Communications Security}, CCS '18, page 67–82, New York, NY, USA, 2018.
-  Association for Computing Machinery.
-
-\end{thebibliography}

SemSEreport/exercises.tex

@@ -116,9 +116,12 @@
 
 \section{Introduction}
 
-\subsection{Precautions}
+\subsection{Paper introduction}
 
-\subsection{Preprocessing}
+The aim of this report is to present an analysis of the SWC-124 weakness and its detection. First, we will decribe the setup we did for performing the analysis.
+Then, in section~\ref{sec:exploit-creation} we will give a brief overview of the weakness and present heuristics for detecting it. Afterwards, in section~\ref{sec:results} we will present the results
+of the security analysis of the assigned contracts\footnote{\url{https://git.logic.at/ethereum/vulnerabilities_23w/-/tree/swc-124?ref_type=heads}}
+and finally, in section~\ref{sec:discussion} we will wrap up, give an overview about what we learned and provide future research questions.
 
 \subsection{Setup}
 
@@ -128,6 +131,7 @@ We attempted to implement an automatic weakness detection pipeline by using a mu
 	\item \textbf{solc}: Using \textbf{solc-select} we select the correct solc version and compile the associated *.sol file. This way we gather compiler hints and warnings.
   \item \textbf{Mythril}: A tool used for analysis of EVM bytecode, one of the de-facto standards for such work. It is unfortunately not able to detect SWC-124, but there is an existing feature request\footnote{\url{https://github.com/Consensys/mythril/issues/861}} for support available.
 	\item \textbf{teEther}: A tool we found in the last research step of this seminar, teether is a dynamic analysis tool for smart contracts. It is unfortunately hardly documented and has been unmaintained for several years. We were unable to generate usable results with it.
+  \item \textbf{Securify v2.0}: Another tool we found that could theoretically detect SWC-124. Unfortunately, it works only with old solidity versions and we were not able to start it.
 	\item \textbf{Slither}: A highly useful tool that offers a large static analysis toolkit for solidity, it not only allows the extraction of contract data like storage layouts but also automatic scanning for common weaknesses. Although it did not seem to be able to detect SWC-124, the storage layout functionality was used extensively by our team.
 \end{itemize}
 
@@ -182,7 +186,7 @@ In this example the \textbf{ERC1155.tokens} array is the only potential weakess
 \noindent and are a necessary code snippet for SWC-124. If such an instruction is present, we then attempt to reverse engineer a sequence of inputs to trigger the exploit, or formulate a reason why we believe this not to be possible.
 
 
-\section{Results}
+\section{Results}\label{sec:results}
 
 Applying the heuristics, mentioned in the previous section, we gathered the following data about the contracts.
 
@@ -218,7 +222,7 @@ Using the heuristics above, we were not able to find a contract that is vulnerab
 	\item WPCMainnetBridge.sol
 \end{itemize}
 
-\section{Discussion}
+\section{Discussion}\label{sec:discussion}
 
 \subsection{Conclusions}
 
@@ -228,7 +232,10 @@ vulnerable specimen from the examples provided.
 
 \subsection{Lessons learned: what works, what doesn't}
 
-% TODO: Do we have something to add?
+During the analysis that we performed, we were able to learn that none of the state-of-the-art tools have support for SWC-124 as of the time of writing.
+Because of this, currently the only way of detecting this vulnerability is the application of the heuristics from section~\ref{sec:exploit-creation}.
+The easiest way to protect yourself from this vulnerability is to use solidity 0.8.0+ and its built-in under- and overflow protection whenever using dynamic arrays (and in general),
+to avoid using assembly for trivial tasks and, if the need arises, to make sure that the assembly calls that modify the storage are formally correct and non-exploitable.
 
 \subsection{Open challenges}