Expand consequences, add examples
This commit is contained in:
Ivaylo Ivanov
+19
-8
@@ -1,7 +1,7 @@
|
||||
@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},
|
||||
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={},
|
||||
@@ -64,9 +64,20 @@
|
||||
note = {\url{https://github.com/Arachnid/uscc/tree/master/submissions-2017/doughoyte} [Accessed: Oct. 27th 2023]}
|
||||
}
|
||||
|
||||
@misc{CiteDrive2022,
|
||||
title = {CiteDrive brings reference management to Overleaf},
|
||||
author = {CiteDrive, Inc},
|
||||
year = 2022,
|
||||
note = {\url{https://www.citedrive.com/overleaf} [Accessed: (Use the date of access)]}
|
||||
}
|
||||
@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},
|
||||
}
|
||||
|
||||
+52
-41
@@ -1,41 +1,52 @@
|
||||
\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{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}
|
||||
\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}
|
||||
|
||||
Binary file not shown.
@@ -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}
|
||||
|
||||
|
||||
Reference in New Issue
Block a user