|
@@ -0,0 +1,227 @@
|
|
1
|
+\documentclass [10pt]{article}
|
|
2
|
+
|
|
3
|
+
|
|
4
|
+\usepackage{latexsym}
|
|
5
|
+\usepackage{amssymb}
|
|
6
|
+\usepackage{epsfig}
|
|
7
|
+\usepackage{fullpage}
|
|
8
|
+\usepackage{enumerate}
|
|
9
|
+\usepackage{xspace}
|
|
10
|
+\usepackage{todonotes}
|
|
11
|
+\usepackage{listings}
|
|
12
|
+\usepackage{url}
|
|
13
|
+\usepackage[ruled,linesnumbered]{algorithm2e} % Enables the writing of pseudo code.
|
|
14
|
+\usepackage{float}% http://ctan.org/pkg/float
|
|
15
|
+
|
|
16
|
+\newcommand{\true}{true}
|
|
17
|
+\newcommand{\false}{false}
|
|
18
|
+\pagestyle{plain}
|
|
19
|
+\bibliographystyle{plain}
|
|
20
|
+
|
|
21
|
+
|
|
22
|
+\title{192.127 Seminar in Software Engineering (Smart Contracts) \\
|
|
23
|
+ SWC-124: Write to Arbitrary Storage Location \\
|
|
24
|
+ Report Exploits }
|
|
25
|
+\author{Exercises}
|
|
26
|
+
|
|
27
|
+\date{WT 2023/24}
|
|
28
|
+
|
|
29
|
+\author{\textbf{Ivanov, Ivaylo (11777707) \& Millauer, Peter (01350868)}}
|
|
30
|
+
|
|
31
|
+\newtheorem{theorem}{Theorem}
|
|
32
|
+\newtheorem{lemma}[theorem]{Lemma}
|
|
33
|
+\newtheorem{corollary}[theorem]{Corollary}
|
|
34
|
+\newtheorem{proposition}[theorem]{Proposition}
|
|
35
|
+\newtheorem{conjecture}[theorem]{Conjecture}
|
|
36
|
+\newtheorem{definition}[theorem]{Definition}
|
|
37
|
+\newtheorem{example}[theorem]{Example}
|
|
38
|
+\newtheorem{remark}[theorem]{Remark}
|
|
39
|
+\newtheorem{exercise}[theorem]{Exercise}
|
|
40
|
+
|
|
41
|
+
|
|
42
|
+\renewcommand{\labelenumi}{(\alph{enumi})}
|
|
43
|
+
|
|
44
|
+\usepackage{xcolor}
|
|
45
|
+
|
|
46
|
+\definecolor{codegreen}{rgb}{0,0.6,0}
|
|
47
|
+\definecolor{codegray}{rgb}{0.5,0.5,0.5}
|
|
48
|
+\definecolor{codepurple}{rgb}{0.58,0,0.82}
|
|
49
|
+\definecolor{backcolour}{rgb}{0.95,0.95,0.92}
|
|
50
|
+\definecolor{verylightgray}{rgb}{.97,.97,.97}
|
|
51
|
+
|
|
52
|
+\lstdefinelanguage{Solidity}{
|
|
53
|
+ keywords=[1]{anonymous, assembly, assert, balance, break, call, callcode, case, catch, class, constant, continue, constructor, contract, debugger, default, delegatecall, delete, do, else, emit, event, experimental, export, external, false, finally, for, function, gas, if, implements, import, in, indexed, instanceof, interface, internal, is, length, library, log0, log1, log2, log3, log4, memory, modifier, new, payable, pragma, private, protected, public, pure, push, require, return, returns, revert, selfdestruct, send, solidity, storage, struct, suicide, super, switch, then, this, throw, transfer, true, try, typeof, using, value, view, while, with, addmod, ecrecover, keccak256, mulmod, ripemd160, sha256, sha3}, % generic keywords including crypto operations
|
|
54
|
+ keywordstyle=[1]\color{blue}\bfseries,
|
|
55
|
+ keywords=[2]{address, bool, byte, bytes, bytes1, bytes2, bytes3, bytes4, bytes5, bytes6, bytes7, bytes8, bytes9, bytes10, bytes11, bytes12, bytes13, bytes14, bytes15, bytes16, bytes17, bytes18, bytes19, bytes20, bytes21, bytes22, bytes23, bytes24, bytes25, bytes26, bytes27, bytes28, bytes29, bytes30, bytes31, bytes32, enum, int, int8, int16, int24, int32, int40, int48, int56, int64, int72, int80, int88, int96, int104, int112, int120, int128, int136, int144, int152, int160, int168, int176, int184, int192, int200, int208, int216, int224, int232, int240, int248, int256, mapping, string, uint, uint8, uint16, uint24, uint32, uint40, uint48, uint56, uint64, uint72, uint80, uint88, uint96, uint104, uint112, uint120, uint128, uint136, uint144, uint152, uint160, uint168, uint176, uint184, uint192, uint200, uint208, uint216, uint224, uint232, uint240, uint248, uint256, var, void, ether, finney, szabo, wei, days, hours, minutes, seconds, weeks, years}, % types; money and time units
|
|
56
|
+ keywordstyle=[2]\color{teal}\bfseries,
|
|
57
|
+ keywords=[3]{block, blockhash, coinbase, difficulty, gaslimit, number, timestamp, msg, data, gas, sender, sig, value, now, tx, gasprice, origin}, % environment variables
|
|
58
|
+ keywordstyle=[3]\color{violet}\bfseries,
|
|
59
|
+ identifierstyle=\color{black},
|
|
60
|
+ sensitive=true,
|
|
61
|
+ comment=[l]{//},
|
|
62
|
+ morecomment=[s]{/*}{*/},
|
|
63
|
+ commentstyle=\color{gray}\ttfamily,
|
|
64
|
+ stringstyle=\color{red}\ttfamily,
|
|
65
|
+ morestring=[b]',
|
|
66
|
+ morestring=[b]"
|
|
67
|
+}
|
|
68
|
+
|
|
69
|
+\lstset{
|
|
70
|
+ language=Solidity,
|
|
71
|
+ backgroundcolor=\color{verylightgray},
|
|
72
|
+ extendedchars=true,
|
|
73
|
+ basicstyle=\footnotesize\ttfamily,
|
|
74
|
+ showstringspaces=false,
|
|
75
|
+ showspaces=false,
|
|
76
|
+ numbers=left,
|
|
77
|
+ numberstyle=\footnotesize,
|
|
78
|
+ numbersep=9pt,
|
|
79
|
+ tabsize=2,
|
|
80
|
+ breaklines=true,
|
|
81
|
+ showtabs=false,
|
|
82
|
+ captionpos=b
|
|
83
|
+}
|
|
84
|
+
|
|
85
|
+\lstdefinestyle{mystyle}{
|
|
86
|
+ backgroundcolor=\color{backcolour},
|
|
87
|
+ commentstyle=\color{codegreen},
|
|
88
|
+ keywordstyle=\color{magenta},
|
|
89
|
+ numberstyle=\tiny\color{codegray},
|
|
90
|
+ stringstyle=\color{codepurple},
|
|
91
|
+ basicstyle=\ttfamily\footnotesize,
|
|
92
|
+ breakatwhitespace=false,
|
|
93
|
+ breaklines=true,
|
|
94
|
+ captionpos=b,
|
|
95
|
+ keepspaces=true,
|
|
96
|
+ numbers=left,
|
|
97
|
+ numbersep=5pt,
|
|
98
|
+ showspaces=false,
|
|
99
|
+ showstringspaces=false,
|
|
100
|
+ showtabs=false,
|
|
101
|
+ tabsize=2
|
|
102
|
+}
|
|
103
|
+
|
|
104
|
+
|
|
105
|
+
|
|
106
|
+\begin{document}
|
|
107
|
+
|
|
108
|
+
|
|
109
|
+\maketitle
|
|
110
|
+
|
|
111
|
+
|
|
112
|
+%\begin{abstract}
|
|
113
|
+% This paper outlines different forms of the common smart contract weakness with the SWC number 124, commonly referred to as "Write to Arbitrary Storage Location". While this paper focuses on applications within the context of Ethereum's EVM and higher-level language Solidity, we will also briefly touch on other research that deals with the Hyperledger Fabric environment. We will begin with a gentle introduction to the Solidity storage layout design that allows this weakness to occur, followed by common forms of exploit, alongside their associated consequences. Finally, we will outline the code characteristics that are detectable by automated tools as well as an exploit sketch.
|
|
114
|
+%\end{abstract}
|
|
115
|
+
|
|
116
|
+\section{Introduction}
|
|
117
|
+
|
|
118
|
+\subsection{Precautions}
|
|
119
|
+
|
|
120
|
+\subsection{Preprocessing}
|
|
121
|
+
|
|
122
|
+\subsection{Setup}
|
|
123
|
+
|
|
124
|
+We attempted to implement an automatic weakness detection pipeline by using a multitude of tools. The software used includes:
|
|
125
|
+
|
|
126
|
+\begin{itemize}
|
|
127
|
+ \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.
|
|
128
|
+ \item \textbf{Mythril}: %TODO% Mythril also does something
|
|
129
|
+ \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.
|
|
130
|
+ \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.
|
|
131
|
+\end{itemize}
|
|
132
|
+
|
|
133
|
+
|
|
134
|
+\section{Exploit Creation}
|
|
135
|
+
|
|
136
|
+\subsection{extra short recap of weakness definitions}
|
|
137
|
+
|
|
138
|
+SWC-124 attempts to use the underlying mechanisms that govern dynamic array allocation to deterministically overwrite arbitrary data in smart contracts. An analogous weakness can be created by employing unchecked assembly instructions, although this is a less common attack vector due to its unusual structure.
|
|
139
|
+
|
|
140
|
+\subsection{exploit idea(s)}
|
|
141
|
+
|
|
142
|
+The workflow of determining the vulnerability of a given contract is straight forward and follows the general approach of automatic detection mechanisms from our last paper. Since SWC-124 requires the presence of very specific code, it is relatively easy to exclude non-vulnerable contracts. Namely any contract without dynamic arrays or raw assembly including a SSTORE instruction can immediately be considered non-vulnerable. The presence of dynamic arrays can be determined using \textbf{slither --print variable-order}. A sample output looks as follows:
|
|
143
|
+
|
|
144
|
+\begin{verbatim}
|
|
145
|
+$slither cans.sol --print variable-order
|
|
146
|
+
|
|
147
|
+Cans:
|
|
148
|
++----------------------------+----------------------------------------------+------+--------+
|
|
149
|
+| Name | Type | Slot | Offset |
|
|
150
|
++----------------------------+----------------------------------------------+------+--------+
|
|
151
|
+| ERC1155._balances | mapping(address => uint32[7]) | 0 | 0 |
|
|
152
|
+| ERC1155.tokens | uint256[] | 1 | 0 |
|
|
153
|
+| ERC1155._operatorApprovals | mapping(address => mapping(address => bool)) | 2 | 0 |
|
|
154
|
+| ERC1155._uri | string | 3 | 0 |
|
|
155
|
+| Ownable._owner | address | 4 | 0 |
|
|
156
|
+| Functional._reentryKey | bool | 4 | 20 |
|
|
157
|
+| Cans.START_TIME | uint256 | 5 | 0 |
|
|
158
|
+| Cans.END_TIME | uint256 | 6 | 0 |
|
|
159
|
+| Cans.amountClaimed | uint8[9998] | 7 | 0 |
|
|
160
|
+| Cans.CLAIM_ENABLED | bool | 320 | 0 |
|
|
161
|
+| Cans.soda | SODAContract | 320 | 1 |
|
|
162
|
+| Cans.SODA_CONTRACT | address | 321 | 0 |
|
|
163
|
+| Cans.baseURI | string | 322 | 0 |
|
|
164
|
++----------------------------+----------------------------------------------+------+--------+
|
|
165
|
+
|
|
166
|
+\end{verbatim}
|
|
167
|
+
|
|
168
|
+In this example the \textbf{ERC1155.tokens} array is the only potential weakess present. We would then look for the presence of what-where writes to this array in order to confirm the potential presence of SWC-124. What-where writes are of the form
|
|
169
|
+
|
|
170
|
+\begin{verbatim}
|
|
171
|
+ someArray[where] = what;
|
|
172
|
+\end{verbatim}
|
|
173
|
+
|
|
174
|
+\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.
|
|
175
|
+
|
|
176
|
+\section{Results}
|
|
177
|
+
|
|
178
|
+\subsection{vulnerable contracts}
|
|
179
|
+
|
|
180
|
+None.
|
|
181
|
+
|
|
182
|
+\subsection{non-exploitable contracts}
|
|
183
|
+
|
|
184
|
+\noindent Solidity files that contained no contracts:
|
|
185
|
+
|
|
186
|
+\begin{itemize}
|
|
187
|
+ \item AuctionLib.sol
|
|
188
|
+ \item LibRegion.sol
|
|
189
|
+ \item LToken.sol
|
|
190
|
+
|
|
191
|
+\end{itemize}
|
|
192
|
+
|
|
193
|
+\noindent Contracts that were discarded due to the non-presence of dynamic arrays or assembly using SSTORE:
|
|
194
|
+
|
|
195
|
+\begin{itemize}
|
|
196
|
+ \item DCU.sol
|
|
197
|
+ \item ERC20\_Asset\_Pool.sol
|
|
198
|
+ \item FacelessNFT.sol
|
|
199
|
+ \item GElasticTokenManager.sol
|
|
200
|
+ \item GoldToken.sol
|
|
201
|
+ \item GovernmentAlpha.sol
|
|
202
|
+ \item HedgeSwap.sol
|
|
203
|
+ \item HermesImplementation.sol
|
|
204
|
+ \item IMETACoin223Token\_13.sol
|
|
205
|
+ \item UniswapV3PoolAdapter.sol
|
|
206
|
+ \item UserDeposit.sol
|
|
207
|
+ \item WPCMainnetBridge.sol
|
|
208
|
+\end{itemize}
|
|
209
|
+
|
|
210
|
+\subsection{undecidable contracts}
|
|
211
|
+
|
|
212
|
+\subsection{optionally fixes}
|
|
213
|
+
|
|
214
|
+\section{Discussion}
|
|
215
|
+
|
|
216
|
+\subsection{conclusions}
|
|
217
|
+
|
|
218
|
+\subsection{lessons learned: what works, what doesn't}
|
|
219
|
+
|
|
220
|
+\subsection{open challenges}
|
|
221
|
+
|
|
222
|
+
|
|
223
|
+\bibliography{exercise.bib}
|
|
224
|
+
|
|
225
|
+\end{document}
|
|
226
|
+
|
|
227
|
+
|