Expand consequences, add examples

SemSEpaper/exercise.bib

@@ -64,9 +64,20 @@
 	note = {\url{https://github.com/Arachnid/uscc/tree/master/submissions-2017/doughoyte} [Accessed: Oct. 27th 2023]}
 }
 
-@misc{CiteDrive2022,
+@article{multilayer,
-	title        = {CiteDrive brings reference management to Overleaf},
+author = {Duan, Li and Sun, Yangyang and Zhang, Ke-Jia and Ding, Yong},
-	author       = {CiteDrive, Inc},
+year = {2022},
-	year         = 2022,
+month = {02},
-	note         = {\url{https://www.citedrive.com/overleaf} [Accessed: (Use the date of access)]}
+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},
 }

SemSEpaper/exercises.bbl

@@ -15,6 +15,17 @@ doughoyte.
   \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

SemSEpaper/exercises.tex

@@ -222,15 +222,57 @@ owner to set them as a manager, which would result in the weakness being exploit
 The consequences of exploiting an arbitrary storage access weakness can be of different types and severity.
 An attacker may gain read-write access to private contract data, which should only be accessible to owners, maintainers etc.
 They may also exploit the contract to circumvent authorization checks and drain the contract funds.
-%TODO: can we expand this?
+According to Li Duan et al.~\cite{multilayer}, an attacker may also be able to destroy the contract storage structure and thus cause
+unexpected program flow, abnormal function execution or contract freeze.
 
 \section{Vulnerable contracts in literature}
 
-collect vulnerable contracts used by different papers to motivate/illustrate the weakness
+One example for vulnerable contracts, which is similar to Algorithm~\ref{alg:pop-incorrect}, is mentioned in the paper by Li Duan et al.~\cite{multilayer}:
+
+\medspace
+
+\lstset{style=mystyle}
+\begin{algorithm}[H]
+	\begin{lstlisting}[language=Octave]
+    function PopBonusCode() public {
+      require(0 <= bonusCodes.length);
+      bonusCodes.length--;
+    }
+
+    function UpdateBonusCodeAt(uint idx, uint c) public {
+      require(idx < bonusCodes.length);
+      bonusCodes[idx] = c;
+    }
+  \end{lstlisting}
+	\caption{Arbitrary write as per Li Duan et al.}
+  \label{alg:multilayer-example}
+\end{algorithm}
+
+We will not go into a detailed explanation, as we already did this in the previous section.
+
+
+A more sophisticated example is presented in the paper by Sukrit Kalra et al.~\cite{Kalra2018ZEUSAS}:
+
+\medspace
+
+\lstset{style=mystyle}
+\begin{algorithm}[H]
+	\begin{lstlisting}[language=Octave]
+    uint payout = balance/participants.length;
+    for (var i = 0; i < participants.length; i++)
+      participants[i].send(payout);
+  \end{lstlisting}
+	\caption{Arbitrary read as per Sukrit Kalra et al.}
+  \label{alg:zeus-example}
+\end{algorithm}
+
+The vulnerability here is an integer overflow - as the variable \texttt{i} is dinamically typed, it will get the smallest possible type that will be able to hold the value 0 - that being \texttt{uint8}, which is able to hold positive integers up to 255.
+
+Because of this, if the length of the \texttt{participants} arrays is greater than 255, the integer overflows on the 256th iteration and instead of moving on to \texttt{participants[255]}, it reverts back to the first element in the array. As a result, the first 255 paricipants will split all the balance of the contract, whereas the rest will get nothing.
 
 \section{Code properties and automatic detection}
 
-Automatic detection tools can be broadly categorized into ones employing static analysis and those who use fuzzing, i.e. application of semi-random inputs. Notable static analysis tools include Securify \cite{securify} and teEther \cite{teether} which both function in a similar manner:
+Automatic detection tools can be broadly categorized into ones employing static analysis and those who use fuzzing, i.e. application of semi-random inputs. Notable static analysis tools include Securify~\cite{securify} and teEther~\cite{teether} which both function in a similar manner:
 
 \medspace
 
@@ -238,15 +280,15 @@ Initially, the given EVM byte-code is disassembled into a control-flow-graph (CF
 
 \medspace
 
-In the case of Securify \cite{securify}, the CFG is translated into what the authors call "semantic facts" to which an elaborate set of so-called security patterns is applied. These patterns consist of building blocks in the form of predicates, which allows the tool to simply generate output based on the (transitively) matched patterns.
+In the case of Securify~\cite{securify}, the CFG is translated into what the authors call "semantic facts" to which an elaborate set of so-called security patterns is applied. These patterns consist of building blocks in the form of predicates, which allows the tool to simply generate output based on the (transitively) matched patterns.
 
 \medspace
 
-teEther \cite{teether} employs a similar approach, but instead the authors opt to build a graph of dependent variables. If the graph arrives at a $sstore(k,v)$ instruction and a path can be found leading to user-controlled inputs, the tool infers a set of constraints which are then used to automatically generate an exploit.
+teEther~\cite{teether} employs a similar approach, but instead the authors opt to build a graph of dependent variables. If the graph arrives at a $sstore(k,v)$ instruction and a path can be found leading to user-controlled inputs, the tool infers a set of constraints which are then used to automatically generate an exploit.
 
 \medspace
 
-The fuzz-driven approach to vulnerability detection is more abstract, as general-purpose fuzzing tools generally don't have knowledge of the analysed program. For the tool SmartFuzzDriverGenerator \cite{fuzzdrivegen}, a multitude of these fuzzing libraries can be used. The problem at hand is, however, that the technique cannot interface with a smart contract out of the box. The "glue" between fuzzer and program is called a driver, hence the name of "driver-generator".
+The fuzz-driven approach to vulnerability detection is more abstract, as general-purpose fuzzing tools generally don't have knowledge of the analysed program. For the tool SmartFuzzDriverGenerator~\cite{fuzzdrivegen}, a multitude of these fuzzing libraries can be used. The problem at hand is, however, that the technique cannot interface with a smart contract out of the box. The "glue" between fuzzer and program is called a driver, hence the name of "driver-generator".
 
 \medspace
 
@@ -254,7 +296,7 @@ SmartFuzzDriverGenerator aims to automatically generate such a driver by %TODO:
 
 \medspace
 
-The Smartian tool \cite{smartian} attempts to find a middle-ground between static and dynamic analysis by first transforming the EVM bytecode into control-flow facts. Based on this information, a set of seed-inputs is generated that are expected to have a high probability of yielding useable results. Should no exploit be found, the seed-inputs are then mutated in order to yield a higher code coverage. %TODO: This is probably extemely inprecise and should be re-written%
+The Smartian tool~\cite{smartian} attempts to find a middle-ground between static and dynamic analysis by first transforming the EVM bytecode into control-flow facts. Based on this information, a set of seed-inputs is generated that are expected to have a high probability of yielding useable results. Should no exploit be found, the seed-inputs are then mutated in order to yield a higher code coverage. %TODO: This is probably extemely inprecise and should be re-written%
 
 \section{Exploit sketch}