Browse Source

Expand introduction, add lessons, clear bibliography

master
Ivaylo Ivanov 11 months ago
parent
commit
658bfa32d1
4 changed files with 12 additions and 138 deletions
  1. 0
    82
      SemSEreport/exercise.bib
  2. 0
    51
      SemSEreport/exercises.bbl
  3. BIN
      SemSEreport/exercises.pdf
  4. 12
    5
      SemSEreport/exercises.tex

+ 0
- 82
SemSEreport/exercise.bib View File

1
-@INPROCEEDINGS{smartian,
2
-	author={Choi, Jaeseung and Kim, Doyeon and Kim, Soomin and Grieco, Gustavo and Groce, Alex and Cha, Sang Kil},
3
-	booktitle={2021 36th IEEE/ACM International Conference on Automated Software Engineering (ASE)},
4
-	title={SMARTIAN: Enhancing Smart Contract Fuzzing with Static and Dynamic Data-Flow Analyses},
5
-	year={2021},
6
-	volume={},
7
-	number={},
8
-	pages={227-239},
9
-	doi={10.1109/ASE51524.2021.9678888}}
10
 
1
 
11
-@inproceedings{fuzzdrivegen,
12
-	author = {Pani, Siddhasagar and Nallagonda, Harshita Vani and Vigneswaran and Medicherla, Raveendra Kumar and Rajan M},
13
-	title = {SmartFuzzDriverGen: Smart Contract Fuzzing Automation for Golang},
14
-	year = {2023},
15
-	isbn = {9798400700644},
16
-	publisher = {Association for Computing Machinery},
17
-	address = {New York, NY, USA},
18
-	url = {https://doi.org/10.1145/3578527.3578538},
19
-	doi = {10.1145/3578527.3578538},
20
-	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.},
21
-	booktitle = {Proceedings of the 16th Innovations in Software Engineering Conference},
22
-	articleno = {14},
23
-	numpages = {11},
24
-	keywords = {smart contracts, vulnerability detection, automated driver generation, blockchain, fuzzing, sequencing},
25
-	location = {Allahabad, India},
26
-	series = {ISEC '23}
27
-}
28
-
29
-@inproceedings {teether,
30
-	author = {Johannes Krupp and Christian Rossow},
31
-	title = {{teEther}: Gnawing at Ethereum to Automatically Exploit Smart Contracts},
32
-	booktitle = {27th USENIX Security Symposium (USENIX Security 18)},
33
-	year = {2018},
34
-	isbn = {978-1-939133-04-5},
35
-	address = {Baltimore, MD},
36
-	pages = {1317--1333},
37
-	url = {https://www.usenix.org/conference/usenixsecurity18/presentation/krupp},
38
-	publisher = {USENIX Association},
39
-	month = aug
40
-}
41
-
42
-@inproceedings{securify,
43
-	author = {Tsankov, Petar and Dan, Andrei and Drachsler-Cohen, Dana and Gervais, Arthur and B\"{u}nzli, Florian and Vechev, Martin},
44
-	title = {Securify: Practical Security Analysis of Smart Contracts},
45
-	year = {2018},
46
-	isbn = {9781450356930},
47
-	publisher = {Association for Computing Machinery},
48
-	address = {New York, NY, USA},
49
-	url = {https://doi.org/10.1145/3243734.3243780},
50
-	doi = {10.1145/3243734.3243780},
51
-	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.},
52
-	booktitle = {Proceedings of the 2018 ACM SIGSAC Conference on Computer and Communications Security},
53
-	pages = {67–82},
54
-	numpages = {16},
55
-	keywords = {smart contracts, stratified datalog, verification, security analysis},
56
-	location = {Toronto, Canada},
57
-	series = {CCS '18}
58
-}
59
-
60
-@MISC{
61
-	doughoyte,
62
-	author = {doughoyte},
63
-	title = {MerdeToken: It's Some Hot Shit},
64
-	note = {\url{https://github.com/Arachnid/uscc/tree/master/submissions-2017/doughoyte} [Accessed: Oct. 27th 2023]}
65
-}
66
-
67
-@article{multilayer,
68
-author = {Duan, Li and Sun, Yangyang and Zhang, Ke-Jia and Ding, Yong},
69
-year = {2022},
70
-month = {02},
71
-pages = {},
72
-title = {Multiple-Layer Security Threats on the Ethereum Blockchain and Their Countermeasures},
73
-volume = {2022},
74
-journal = {Security and Communication Networks},
75
-doi = {10.1155/2022/5307697}
76
-}
77
-
78
-@inproceedings{Kalra2018ZEUSAS,
79
-  title={ZEUS: Analyzing Safety of Smart Contracts},
80
-  author={Sukrit Kalra and Seep Goel and Mohan Dhawan and Subodh Sharma},
81
-  booktitle={Network and Distributed System Security Symposium},
82
-  year={2018},
83
-}

+ 0
- 51
SemSEreport/exercises.bbl View File

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

BIN
SemSEreport/exercises.pdf View File


+ 12
- 5
SemSEreport/exercises.tex View File

116
 
116
 
117
 \section{Introduction}
117
 \section{Introduction}
118
 
118
 
119
-\subsection{Precautions}
119
+\subsection{Paper introduction}
120
 
120
 
121
-\subsection{Preprocessing}
121
+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.
122
+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
123
+of the security analysis of the assigned contracts\footnote{\url{https://git.logic.at/ethereum/vulnerabilities_23w/-/tree/swc-124?ref_type=heads}}
124
+and finally, in section~\ref{sec:discussion} we will wrap up, give an overview about what we learned and provide future research questions.
122
 
125
 
123
 \subsection{Setup}
126
 \subsection{Setup}
124
 
127
 
128
 	\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.
131
 	\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.
129
   \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.
132
   \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.
130
 	\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.
133
 	\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.
134
+  \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.
131
 	\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.
135
 	\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.
132
 \end{itemize}
136
 \end{itemize}
133
 
137
 
182
 \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.
186
 \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.
183
 
187
 
184
 
188
 
185
-\section{Results}
189
+\section{Results}\label{sec:results}
186
 
190
 
187
 Applying the heuristics, mentioned in the previous section, we gathered the following data about the contracts.
191
 Applying the heuristics, mentioned in the previous section, we gathered the following data about the contracts.
188
 
192
 
218
 	\item WPCMainnetBridge.sol
222
 	\item WPCMainnetBridge.sol
219
 \end{itemize}
223
 \end{itemize}
220
 
224
 
221
-\section{Discussion}
225
+\section{Discussion}\label{sec:discussion}
222
 
226
 
223
 \subsection{Conclusions}
227
 \subsection{Conclusions}
224
 
228
 
228
 
232
 
229
 \subsection{Lessons learned: what works, what doesn't}
233
 \subsection{Lessons learned: what works, what doesn't}
230
 
234
 
231
-% TODO: Do we have something to add?
235
+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.
236
+Because of this, currently the only way of detecting this vulnerability is the application of the heuristics from section~\ref{sec:exploit-creation}.
237
+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),
238
+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.
232
 
239
 
233
 \subsection{Open challenges}
240
 \subsection{Open challenges}
234
 
241
 

Loading…
Cancel
Save