camp2023-57069-eng-DONT_PANIC_opus.srt

1
00:00:00,000 --> 00:00:29,980
 [ Music ]

2
00:00:30,960 --> 00:00:33,780
 >> Ladies and gentlemen, we're going to have an interesting talk

3
00:00:33,780 --> 00:00:38,060
 about bugs in the blockchain brought to you by Louis and Gabi.

4
00:00:38,060 --> 00:00:42,860
 [ Applause ]

5
00:00:42,860 --> 00:00:43,780
 >> Hello everybody.

6
00:00:43,780 --> 00:00:45,540
 Yeah, thanks a lot for coming.

7
00:00:45,540 --> 00:00:47,140
 It's still early.

8
00:00:47,140 --> 00:00:49,020
 I'm glad everyone could make it.

9
00:00:49,020 --> 00:00:53,320
 So our talk is called Don't Panic, Bites, Blocks, Bugs.

10
00:00:53,320 --> 00:00:55,620
 And I'm Louis.

11
00:00:55,620 --> 00:00:57,120
 I'm a security researcher.

12
00:00:57,120 --> 00:01:00,020
 I've been working on this topic of finding bugs in blockchain

13
00:01:00,020 --> 00:01:02,880
 for almost two years now.

14
00:01:02,880 --> 00:01:07,200
 And I also focused a lot in the past two years

15
00:01:07,200 --> 00:01:12,600
 on tool development around our audit efforts.

16
00:01:12,600 --> 00:01:14,940
 >> Yeah. Good morning everyone.

17
00:01:14,940 --> 00:01:15,660
 I'm Gabi.

18
00:01:15,660 --> 00:01:18,060
 Thank you for making it this morning.

19
00:01:18,060 --> 00:01:20,680
 We know it can be a bit difficult after like three,

20
00:01:20,680 --> 00:01:21,960
 four days of camp.

21
00:01:21,960 --> 00:01:24,120
 I'm a security researcher.

22
00:01:24,260 --> 00:01:27,660
 And currently I'm focusing on finding bugs in blockchains.

23
00:01:27,660 --> 00:01:30,620
 >> All right.

24
00:01:30,620 --> 00:01:31,540
 So blockchains.

25
00:01:31,540 --> 00:01:33,640
 They've been in the news quite a lot

26
00:01:33,640 --> 00:01:35,740
 in the past couple of years.

27
00:01:35,740 --> 00:01:38,880
 Not always for the good reasons.

28
00:01:38,880 --> 00:01:41,180
 A lot of times it's because a lot of money gets stolen

29
00:01:41,180 --> 00:01:43,460
 from somewhere or a lot of money gets lost.

30
00:01:43,460 --> 00:01:46,680
 And it seems like a lot

31
00:01:46,680 --> 00:01:50,140
 of attackers have a big advantage in the field.

32
00:01:50,140 --> 00:01:52,920
 So as security researchers we're kind of trying to be proactive.

33
00:01:53,340 --> 00:01:56,680
 And we want to share with you today the knowledge

34
00:01:56,680 --> 00:01:59,920
 of how we find bugs and which kind of bugs we find

35
00:01:59,920 --> 00:02:01,420
 in those blockchain systems.

36
00:02:01,420 --> 00:02:07,940
 So that, you know, everybody can learn from our work.

37
00:02:07,940 --> 00:02:12,480
 So today we'll be going through five common types of bugs

38
00:02:12,480 --> 00:02:14,800
 that we find in a specific framework that we'll talk

39
00:02:14,800 --> 00:02:17,780
 about a bit later and how to find those bugs.

40
00:02:17,780 --> 00:02:21,780
 So this is kind of a small shocker bug that I want

41
00:02:21,780 --> 00:02:26,660
 to quickly present to show you how important this auditing

42
00:02:26,660 --> 00:02:28,200
 process can be for blockchain systems.

43
00:02:28,200 --> 00:02:31,980
 So this was an Ethereum project that because

44
00:02:31,980 --> 00:02:35,620
 of this one line basically crumbled on itself.

45
00:02:35,620 --> 00:02:37,140
 This wasn't a hack per se.

46
00:02:37,140 --> 00:02:38,900
 It wasn't like an attacker stealing money or something.

47
00:02:38,900 --> 00:02:42,920
 It was just one line that made the whole project collapse

48
00:02:42,920 --> 00:02:45,400
 on itself and everybody that had put money

49
00:02:45,400 --> 00:02:48,840
 into the project just basically lost everything.

50
00:02:49,200 --> 00:02:52,760
 And the code was brand new, unaudited.

51
00:02:52,760 --> 00:02:56,160
 The developers said, "Guys, please don't put your money in yet.

52
00:02:56,160 --> 00:02:58,640
 We want to, you know, finish up stuff."

53
00:02:58,640 --> 00:03:02,640
 And people still put way too much money in there

54
00:03:02,640 --> 00:03:04,720
 and basically lost everything.

55
00:03:04,720 --> 00:03:08,480
 So yeah, just because of this one line, which is an overflow

56
00:03:08,480 --> 00:03:11,280
 in a multiplication, that made it so that the developers

57
00:03:11,280 --> 00:03:15,260
 or I mean the community lost control over the governance

58
00:03:15,260 --> 00:03:18,660
 of the contract and yeah, made it impossible to recover.

59
00:03:18,860 --> 00:03:21,920
 Everybody lost funds.

60
00:03:21,920 --> 00:03:27,520
 So as an attacker, what can you gain from blockchains?

61
00:03:27,520 --> 00:03:32,260
 The first obvious way is just like stealing funds.

62
00:03:32,260 --> 00:03:35,940
 If you are able to find some kind of a bug that allows you

63
00:03:35,940 --> 00:03:39,420
 to steal funds from one address or a contract or whatever,

64
00:03:39,420 --> 00:03:42,760
 you can just take those funds or these assets,

65
00:03:42,760 --> 00:03:46,980
 put them on an exchange, exchange them for real money

66
00:03:46,980 --> 00:03:51,480
 and then, you know, walk away with your gains.

67
00:03:51,480 --> 00:03:55,920
 Then the other way that we'll also be looking at today

68
00:03:55,920 --> 00:03:58,680
 is that if you are able to mess with the availability

69
00:03:58,680 --> 00:04:03,200
 of the chain or, you know, mess with people's expectations

70
00:04:03,200 --> 00:04:05,960
 of what the project should act like,

71
00:04:05,960 --> 00:04:09,000
 then you can diminish the overall value of the chain.

72
00:04:09,000 --> 00:04:11,240
 And if as an attacker you knew that in advance

73
00:04:11,240 --> 00:04:13,800
 and you shorted the token in some way,

74
00:04:14,080 --> 00:04:18,060
 then you can also gain some money this way

75
00:04:18,060 --> 00:04:20,680
 and this actually might be even harder to trace

76
00:04:20,680 --> 00:04:23,800
 than the first way.

77
00:04:23,800 --> 00:04:28,460
 There are a few other ways an attacker can gain money

78
00:04:28,460 --> 00:04:29,780
 from attacking blockchains.

79
00:04:29,780 --> 00:04:32,140
 We are not going to cover them today, but these include,

80
00:04:32,140 --> 00:04:34,800
 for example, DeFi attacks, so decentralized finance.

81
00:04:34,800 --> 00:04:38,780
 Also, you know, attacking the underlying IT infrastructure,

82
00:04:38,780 --> 00:04:42,460
 which, you know, can happen of course.

83
00:04:42,460 --> 00:04:44,500
 Social engineering, which has happened a lot

84
00:04:44,500 --> 00:04:45,940
 in the past couple of years.

85
00:04:45,940 --> 00:04:48,240
 And yeah, also just, you know,

86
00:04:48,240 --> 00:04:55,020
 a rock pool from the developers' financial scams.

87
00:04:55,020 --> 00:05:01,980
 So yeah, we'll first be giving you an intro

88
00:05:01,980 --> 00:05:03,500
 of these blockchains.

89
00:05:03,500 --> 00:05:09,220
 Then we'll explain the five types of bugs

90
00:05:09,220 --> 00:05:11,100
 that we wanted to outline to you today.

91
00:05:11,100 --> 00:05:13,340
 These are not exhaustive, it's just five types

92
00:05:13,340 --> 00:05:14,820
 that we find interesting and that we think

93
00:05:14,820 --> 00:05:18,180
 that you might enjoy learning about.

94
00:05:18,180 --> 00:05:21,260
 We'll be showing you examples of real world bugs

95
00:05:21,260 --> 00:05:23,940
 that we found in the past couple of years.

96
00:05:23,940 --> 00:05:26,500
 And then we'll show you how we can use fuzzing

97
00:05:26,500 --> 00:05:30,220
 to actually find those bugs proactively and effectively.

98
00:05:30,220 --> 00:05:33,500
 And yeah, go ahead, Gabi.

99
00:05:33,500 --> 00:05:34,980
 Thank you.

100
00:05:34,980 --> 00:05:37,620
 So today we are going to focus on the latest blockchain

101
00:05:37,620 --> 00:05:41,260
 technology, which is called the third generation.

102
00:05:41,260 --> 00:05:44,700
 But let's just quickly go back and check the other two ones.

103
00:05:44,700 --> 00:05:48,140
 So the first generation, it's the Bitcoin.

104
00:05:48,140 --> 00:05:50,460
 Basically, you all know it.

105
00:05:50,460 --> 00:05:55,140
 It allows you to transfer assets from one party to the other.

106
00:05:55,140 --> 00:05:57,420
 And compared with the other two generations,

107
00:05:57,420 --> 00:06:01,380
 it has quite a simplicity, let's say.

108
00:06:01,380 --> 00:06:03,500
 Also, currently there are not too many bugs

109
00:06:03,500 --> 00:06:05,500
 that are being found in Bitcoin.

110
00:06:05,500 --> 00:06:08,420
 And probably this is also because it's quite simple,

111
00:06:08,420 --> 00:06:09,980
 let's say.

112
00:06:09,980 --> 00:06:12,300
 Then the second generation came out

113
00:06:12,300 --> 00:06:15,100
 and it introduced the concept of smart contracts.

114
00:06:15,100 --> 00:06:19,460
 So basically now you are able to execute code

115
00:06:19,460 --> 00:06:20,500
 on top of the blockchain.

116
00:06:20,500 --> 00:06:24,260
 So you can write your contracts, your agreements,

117
00:06:24,260 --> 00:06:26,580
 and they are going to be executed and stored

118
00:06:26,580 --> 00:06:27,980
 in the blockchain.

119
00:06:27,980 --> 00:06:30,300
 This also introduces the possibility

120
00:06:30,300 --> 00:06:32,180
 of creating business logic.

121
00:06:32,180 --> 00:06:34,420
 So basically, companies actually started

122
00:06:34,420 --> 00:06:38,460
 to develop themselves on the blockchain.

123
00:06:38,460 --> 00:06:40,120
 Now, the idea with the second generation

124
00:06:40,120 --> 00:06:42,540
 is that you have the smart contracts that are all

125
00:06:42,540 --> 00:06:44,780
 being run on the same core.

126
00:06:44,780 --> 00:06:48,180
 The third generation comes out and says, OK,

127
00:06:48,180 --> 00:06:52,300
 instead of having one core and a bunch of smart contracts,

128
00:06:52,300 --> 00:06:56,460
 let's empower the developers to actually create

129
00:06:56,460 --> 00:07:00,980
 their own blockchains so they can define the core themselves.

130
00:07:00,980 --> 00:07:04,580
 And in this case, basically, we are

131
00:07:04,580 --> 00:07:08,220
 going to end up with a bunch of smaller blockchains,

132
00:07:08,220 --> 00:07:11,660
 each one of them targeting a specific use case.

133
00:07:11,660 --> 00:07:14,420
 But now the question is, how do you make all of them

134
00:07:14,420 --> 00:07:19,100
 communicate with each other and actually being an ecosystem?

135
00:07:19,100 --> 00:07:21,340
 So the third generation also introduces

136
00:07:21,340 --> 00:07:25,940
 the interoperability so all of these smaller blockchains

137
00:07:25,940 --> 00:07:29,580
 can communicate with each other.

138
00:07:29,580 --> 00:07:34,380
 Also, there are multiple frameworks

139
00:07:34,380 --> 00:07:37,860
 that are built on the third generation.

140
00:07:37,860 --> 00:07:42,340
 And today, we are actually going to focus on one of them.

141
00:07:42,340 --> 00:07:45,020
 And it is called Substrate.

142
00:07:45,020 --> 00:07:48,300
 And we are going to focus on it because basically, we have--

143
00:07:48,300 --> 00:07:50,460
 our experience is the most with Substrate.

144
00:07:50,460 --> 00:07:54,020
 So it's just easier for us to give you real-life examples

145
00:07:54,020 --> 00:07:56,100
 of bugs and attacks.

146
00:07:56,100 --> 00:07:59,380
 But all the things that we are going to present you here

147
00:07:59,380 --> 00:08:02,980
 can be applied to other blockchains as well.

148
00:08:02,980 --> 00:08:04,520
 The thing that is building Substrate,

149
00:08:04,520 --> 00:08:07,580
 they are also running two blockchains, Polkadot

150
00:08:07,580 --> 00:08:08,260
 and Kusama.

151
00:08:08,260 --> 00:08:12,740
 And probably a lot of you know more about Polkadot

152
00:08:12,740 --> 00:08:15,660
 than the name of Substrate, let's say.

153
00:08:15,660 --> 00:08:19,260
 But besides these two projects, in the ecosystem,

154
00:08:19,260 --> 00:08:23,460
 there are another 150 projects that are using the framework.

155
00:08:23,460 --> 00:08:27,020
 So basically, now we are faced with the research question

156
00:08:27,020 --> 00:08:32,300
 on how do we actually make sure that all these 150 projects are

157
00:08:32,300 --> 00:08:33,820
 actually secure?

158
00:08:33,820 --> 00:08:37,460
 And how can we automate this in a way?

159
00:08:37,460 --> 00:08:40,800
 Because at this scale, basically, you

160
00:08:40,800 --> 00:08:44,300
 need to automate as much as possible.

161
00:08:44,300 --> 00:08:47,900
 Let's have a quick look at the architecture of Substrate.

162
00:08:47,900 --> 00:08:51,620
 It has all the usual components like peer-to-peer networking,

163
00:08:51,620 --> 00:08:53,940
 RPC, telemetry, and so on.

164
00:08:53,940 --> 00:08:59,180
 But today, we are going to focus on the WASM runtime, which

165
00:08:59,180 --> 00:09:03,700
 basically, it's the core of the blockchain.

166
00:09:03,700 --> 00:09:07,660
 And in Substrate-- basically, this runtime,

167
00:09:07,660 --> 00:09:10,580
 it's being built using modules.

168
00:09:10,580 --> 00:09:14,060
 These modules in Substrate are being called palettes.

169
00:09:14,060 --> 00:09:15,520
 Throughout the presentation, we're

170
00:09:15,520 --> 00:09:17,180
 going to try to use the term "modules"

171
00:09:17,180 --> 00:09:20,780
 so we don't introduce too many new terms for you.

172
00:09:20,780 --> 00:09:24,460
 And the idea is that, basically, when a developer wants

173
00:09:24,460 --> 00:09:30,340
 to create a blockchain, they can either use--

174
00:09:30,340 --> 00:09:32,980
 like Cherry Pick, actually-- a bunch of these palettes

175
00:09:32,980 --> 00:09:35,900
 that are already provided by Substrate.

176
00:09:35,900 --> 00:09:37,500
 So you can choose your consensus.

177
00:09:37,500 --> 00:09:39,460
 You can choose if your blockchain

178
00:09:39,460 --> 00:09:42,140
 will be able to run smart contracts or not,

179
00:09:42,140 --> 00:09:44,380
 randomness, and so on.

180
00:09:44,380 --> 00:09:46,220
 And on top of this, you are going to come up

181
00:09:46,220 --> 00:09:50,760
 with your own modules that are going to bring, basically,

182
00:09:50,760 --> 00:09:53,420
 your own business logic.

183
00:09:53,420 --> 00:09:58,820
 OK, so now, let's just quickly look, actually--

184
00:09:58,820 --> 00:10:02,060
 I suppose all of you came here for seeing

185
00:10:02,060 --> 00:10:03,180
 the attacks and the bugs.

186
00:10:03,180 --> 00:10:06,100
 So let's just dive into that.

187
00:10:06,100 --> 00:10:07,660
 Yeah, let's go.

188
00:10:07,660 --> 00:10:10,260
 So we'll be looking at five major classes of bugs

189
00:10:10,260 --> 00:10:12,060
 that we've defined today.

190
00:10:12,060 --> 00:10:17,300
 So bug type A would be wrongly priced transactions.

191
00:10:17,300 --> 00:10:20,660
 So if a transaction doesn't have the right gas associated

192
00:10:20,660 --> 00:10:22,660
 with it, then maybe we can exhaust the resources

193
00:10:22,660 --> 00:10:26,900
 of the chain, causing some kind of a denial of service.

194
00:10:26,900 --> 00:10:30,420
 Bug type B is-- we're going to look at logic bugs

195
00:10:30,420 --> 00:10:33,100
 and unsafe arithmetic to manipulate the actual program

196
00:10:33,100 --> 00:10:33,820
 flow.

197
00:10:33,820 --> 00:10:36,900
 This will hinder, of course, the integrity of the chain,

198
00:10:36,900 --> 00:10:39,980
 because you might be able to tweak a number that you weren't

199
00:10:39,980 --> 00:10:41,380
 supposed to be able to tweak.

200
00:10:41,380 --> 00:10:44,420
 But as we'll see, it can also impact availability,

201
00:10:44,420 --> 00:10:48,140
 because those numbers might be associated with availability,

202
00:10:48,140 --> 00:10:50,420
 the numbers that you tweak.

203
00:10:50,420 --> 00:10:52,940
 Bug type C will be looking at the reachable panics.

204
00:10:52,940 --> 00:10:55,980
 This is a very rust-specific bug type

205
00:10:55,980 --> 00:10:59,020
 that we'll be taking a look at.

206
00:10:59,020 --> 00:11:03,140
 And bug type D, encourage usage of standard patterns,

207
00:11:03,140 --> 00:11:08,020
 so basically misconfigurations in the blockchain code,

208
00:11:08,020 --> 00:11:10,880
 because we said that there were quite a lot of things

209
00:11:10,880 --> 00:11:11,580
 you could import.

210
00:11:11,580 --> 00:11:14,140
 And if you import stuff with the wrong configuration,

211
00:11:14,140 --> 00:11:19,180
 then you might be vulnerable to any kind of misbehavior.

212
00:11:19,180 --> 00:11:21,340
 And bug type E will be looking at storage bloating.

213
00:11:21,340 --> 00:11:24,260
 So that's like inserting a whole lot of data

214
00:11:24,260 --> 00:11:29,100
 into the blockchain storage and cause some availability

215
00:11:29,100 --> 00:11:31,740
 mishaps.

216
00:11:31,740 --> 00:11:34,780
 So first, wrongly priced transactions.

217
00:11:34,780 --> 00:11:38,740
 The idea here is that operations on those substrate-based

218
00:11:38,740 --> 00:11:41,500
 blockchains are benchmarked.

219
00:11:41,500 --> 00:11:44,780
 And then the benchmark time basically

220
00:11:44,780 --> 00:11:50,740
 is translated into a gas fee that you

221
00:11:50,740 --> 00:11:54,500
 have to pay in order to run the operation on the network.

222
00:11:54,500 --> 00:11:56,900
 So whenever I want to run an operation A,

223
00:11:56,900 --> 00:12:00,260
 it has an associated gas fee of N.

224
00:12:00,260 --> 00:12:03,180
 And I have to pay N in order to run A.

225
00:12:03,180 --> 00:12:06,780
 And if A was not well benchmarked,

226
00:12:06,780 --> 00:12:08,980
 then I might be able to spam it.

227
00:12:08,980 --> 00:12:13,860
 And then the node that tries to run the whole block

228
00:12:13,860 --> 00:12:17,020
 might just not finish running it in time,

229
00:12:17,020 --> 00:12:23,060
 because it estimated how much time it would need beforehand.

230
00:12:23,060 --> 00:12:25,580
 And if it wrongly estimated because the benchmark was

231
00:12:25,580 --> 00:12:29,860
 wrong, then you might be able to make it basically--

232
00:12:29,860 --> 00:12:32,040
 it's not a timeout, but at least you're

233
00:12:32,040 --> 00:12:34,100
 going to slow the whole thing down and maybe cause

234
00:12:34,100 --> 00:12:39,820
 some people to be blamed for slowing it down.

235
00:12:39,820 --> 00:12:42,800
 That were not you.

236
00:12:42,800 --> 00:12:47,220
 So I'm going to talk about a very cool bug that

237
00:12:47,220 --> 00:12:49,500
 is related to what I just mentioned,

238
00:12:49,500 --> 00:12:51,800
 but not exactly what I just mentioned.

239
00:12:51,800 --> 00:12:53,980
 Because this bug that we found--

240
00:12:53,980 --> 00:12:56,420
 I mean, our fuzzer found it, actually--

241
00:12:56,420 --> 00:13:01,740
 it applies not during the running of the actual operation,

242
00:13:01,740 --> 00:13:05,300
 but during the computing of the weight of the gas

243
00:13:05,300 --> 00:13:06,620
 cost of the function.

244
00:13:06,620 --> 00:13:11,100
 So you can see on the left, this is the gas computation

245
00:13:11,100 --> 00:13:14,180
 of an operation that's called sudo as.

246
00:13:14,180 --> 00:13:19,940
 And this sudo as takes, as an argument, another operation

247
00:13:19,940 --> 00:13:23,700
 to run as sudo, to run as root.

248
00:13:23,700 --> 00:13:28,060
 And of course, this sudo as can only be run by, for example,

249
00:13:28,060 --> 00:13:30,300
 a governance call.

250
00:13:30,300 --> 00:13:31,740
 It cannot be run just by anybody.

251
00:13:31,740 --> 00:13:34,780
 It's also used for development, for debugging.

252
00:13:34,780 --> 00:13:37,260
 But in real life chains, it also exists,

253
00:13:37,260 --> 00:13:40,380
 and it can only be used by governance, basically.

254
00:13:40,380 --> 00:13:45,980
 But the computation of the gas cost of a sudo as

255
00:13:45,980 --> 00:13:48,860
 has to take into account the computation of the gas

256
00:13:48,860 --> 00:13:51,340
 cost of the child operation.

257
00:13:51,340 --> 00:13:54,940
 And if you look at the way that the computation is done,

258
00:13:54,940 --> 00:14:00,020
 it calls the child computation function twice.

259
00:14:00,020 --> 00:14:01,700
 And that means that you can actually

260
00:14:01,700 --> 00:14:07,460
 get an exponential number of function calls

261
00:14:07,460 --> 00:14:12,620
 just by nesting those sudo as calls or any other call that

262
00:14:12,620 --> 00:14:13,620
 was vulnerable to this.

263
00:14:13,620 --> 00:14:15,340
 And there were a few.

264
00:14:15,340 --> 00:14:16,460
 You can nest them.

265
00:14:16,460 --> 00:14:18,920
 And then, for example, if you nest them 41 times,

266
00:14:18,920 --> 00:14:20,580
 you get more than a trillion leaves.

267
00:14:20,580 --> 00:14:24,340
 And basically, the node that is going to try to run that,

268
00:14:24,340 --> 00:14:27,580
 it's not even going to go to the logic of the code at any point.

269
00:14:27,580 --> 00:14:29,540
 So it's not even going to have time

270
00:14:29,540 --> 00:14:31,500
 to check at any point that you're actually

271
00:14:31,500 --> 00:14:32,580
 who you're claiming to be.

272
00:14:32,580 --> 00:14:34,740
 So you can call this as just anybody.

273
00:14:34,740 --> 00:14:38,660
 And it's just going to time out and completely hang

274
00:14:38,660 --> 00:14:41,540
 during the weight computation.

275
00:14:41,540 --> 00:14:44,500
 So yeah, this was a very cool bug

276
00:14:44,500 --> 00:14:48,460
 that we found a couple of years ago.

277
00:14:48,460 --> 00:14:53,100
 OK, so if we are going to have a criminal that is looking more

278
00:14:53,100 --> 00:14:56,540
 into how to manipulate the flow of the program,

279
00:14:56,540 --> 00:14:58,540
 there are two ways of doing this.

280
00:14:58,540 --> 00:15:00,860
 The first one is taking advantage

281
00:15:00,860 --> 00:15:03,780
 of the usage of unsafe arithmetic.

282
00:15:03,780 --> 00:15:08,820
 And as an example, here it's part of a function

283
00:15:08,820 --> 00:15:11,740
 that can be called by any user.

284
00:15:11,740 --> 00:15:15,380
 Now, this function takes a few arguments, one of them

285
00:15:15,380 --> 00:15:18,060
 being a vector of messages.

286
00:15:18,060 --> 00:15:22,140
 These messages have to be processed by the blockchain.

287
00:15:22,140 --> 00:15:25,140
 So before processing them, the blockchain

288
00:15:25,140 --> 00:15:28,680
 is going to calculate the weight of each message,

289
00:15:28,680 --> 00:15:33,320
 then sum all of the weights up.

290
00:15:33,320 --> 00:15:36,180
 And then it will just check, hey,

291
00:15:36,180 --> 00:15:41,460
 is the sum of the weight smaller than the maximum weight

292
00:15:41,460 --> 00:15:44,420
 that I'm supposed to be able to calculate?

293
00:15:44,420 --> 00:15:47,060
 And in case if it's not, it will return an error.

294
00:15:47,060 --> 00:15:50,860
 Now, the problem in this code is that the sum function,

295
00:15:50,860 --> 00:15:54,500
 it's being used to calculate this weight.

296
00:15:54,500 --> 00:15:57,980
 And the sum function is not using safe arithmetic.

297
00:15:57,980 --> 00:15:59,940
 So it can actually overflow.

298
00:15:59,940 --> 00:16:02,960
 So in this case, an attacker can come in

299
00:16:02,960 --> 00:16:09,380
 and actually execute this function with a large vector.

300
00:16:09,380 --> 00:16:13,700
 So basically, when the sum is going to be called,

301
00:16:13,700 --> 00:16:17,260
 the weight calculation is going to overflow and wrap around.

302
00:16:17,260 --> 00:16:19,820
 And in the end, we are going to end up

303
00:16:19,820 --> 00:16:24,260
 with a very small weight for actually a super large amount

304
00:16:24,260 --> 00:16:25,660
 of work to be done.

305
00:16:25,660 --> 00:16:28,780
 So the node will consider, hey, I can actually

306
00:16:28,780 --> 00:16:31,940
 execute this in the amount of time

307
00:16:31,940 --> 00:16:33,100
 that I'm supposed to.

308
00:16:33,100 --> 00:16:38,020
 But actually, it won't be able, and it will time out.

309
00:16:38,020 --> 00:16:40,840
 Now, in order to fix the previous vulnerability,

310
00:16:40,840 --> 00:16:42,740
 you just consider, hey, I will just

311
00:16:42,740 --> 00:16:46,980
 use safe arithmetic as the checked function.

312
00:16:46,980 --> 00:16:51,020
 But that's not always fixing the issue.

313
00:16:51,020 --> 00:16:55,140
 Because when you use safe arithmetic,

314
00:16:55,140 --> 00:16:57,420
 it will actually return you an option.

315
00:16:57,420 --> 00:17:00,820
 So you have to properly handle the error that

316
00:17:00,820 --> 00:17:05,020
 is going to be returned in case of an overflow.

317
00:17:05,020 --> 00:17:08,180
 In here, the developers are using the checked functions,

318
00:17:08,180 --> 00:17:08,860
 which is fine.

319
00:17:08,860 --> 00:17:11,180
 But they are not properly handling

320
00:17:11,180 --> 00:17:12,620
 the case of an overflow.

321
00:17:12,620 --> 00:17:18,900
 So the function that can be called here by a criminal

322
00:17:18,900 --> 00:17:23,580
 allows you to control the begin and of the message count

323
00:17:23,580 --> 00:17:24,660
 parameters.

324
00:17:24,660 --> 00:17:26,900
 So basically, if you are going to call this function

325
00:17:26,900 --> 00:17:32,980
 with an end value of U64 max and the other two ones as 0,

326
00:17:32,980 --> 00:17:35,500
 in the end, the blockchain will try

327
00:17:35,500 --> 00:17:40,420
 to allocate a vector with the capacity of U64 max, which,

328
00:17:40,420 --> 00:17:43,180
 of course, is going to crash the node.

329
00:17:43,180 --> 00:17:46,500
 And it will end up with availability issues

330
00:17:46,500 --> 00:17:48,940
 in the blockchain.

331
00:17:48,940 --> 00:17:53,500
 Now, looking into the logic box, in here,

332
00:17:53,500 --> 00:17:58,820
 we have an example of a blockchain that basically

333
00:17:58,820 --> 00:18:01,740
 a user comes in and says--

334
00:18:01,740 --> 00:18:05,700
 the user actually has to validate their identity.

335
00:18:05,700 --> 00:18:10,060
 So a user will come in and say, hey, this is my identity.

336
00:18:10,060 --> 00:18:14,620
 Then a registrar will pick up the request from the user,

337
00:18:14,620 --> 00:18:17,500
 will check it, and it will say, yes, your identity

338
00:18:17,500 --> 00:18:20,420
 is legit or not.

339
00:18:20,420 --> 00:18:24,180
 Now, the registrar will specifically say, yes,

340
00:18:24,180 --> 00:18:26,860
 this user provided a valid identity.

341
00:18:26,860 --> 00:18:30,580
 But it won't say that it provided

342
00:18:30,580 --> 00:18:32,460
 this specific identity.

343
00:18:32,460 --> 00:18:35,180
 It will just say that the user provided an identity.

344
00:18:35,180 --> 00:18:37,780
 So in the end, what the hacker can do

345
00:18:37,780 --> 00:18:42,340
 is submit a request for a legit identity,

346
00:18:42,340 --> 00:18:46,380
 then monitor the network and see when the registrar actually

347
00:18:46,380 --> 00:18:49,740
 comes in and says, yes, this identity is legit.

348
00:18:49,740 --> 00:18:54,100
 And execute another transaction very quickly

349
00:18:54,100 --> 00:18:56,460
 with a spoofed identity.

350
00:18:56,460 --> 00:18:56,620
 and the higher tip.

351
00:18:56,620 --> 00:19:01,540
 So basically, in the same block, the hacker

352
00:19:01,540 --> 00:19:05,020
 will change their identity with a spoofed one,

353
00:19:05,020 --> 00:19:06,740
 and the registrar will still consider

354
00:19:06,740 --> 00:19:10,580
 that identity as being valid.

355
00:19:10,580 --> 00:19:12,860
 All right, now moving on to reachable panic

356
00:19:12,860 --> 00:19:14,140
 for availability issues.

357
00:19:14,140 --> 00:19:18,260
 Now, these reachable panics, it's a bit more complicated

358
00:19:18,260 --> 00:19:18,740
 now.

359
00:19:18,740 --> 00:19:20,140
 There are some changes in the code

360
00:19:20,140 --> 00:19:22,340
 that make it not so clear cut.

361
00:19:22,340 --> 00:19:25,400
 The nodes are not just going to panic in most situations,

362
00:19:25,400 --> 00:19:30,300
 but sometimes they do, and we want to include it

363
00:19:30,300 --> 00:19:32,780
 because we think it's still very interesting.

364
00:19:32,780 --> 00:19:36,500
 So in Rust, because all of these blockchains and the code

365
00:19:36,500 --> 00:19:38,700
 snippets you've seen so far are coded in Rust,

366
00:19:38,700 --> 00:19:44,260
 if you can't handle some kind of a result that you did,

367
00:19:44,260 --> 00:19:46,860
 you have the option to unwrap the result.

368
00:19:46,860 --> 00:19:50,780
 And then if the result is valid, then the program flow

369
00:19:50,780 --> 00:19:51,540
 continues.

370
00:19:51,540 --> 00:19:56,660
 If the result is invalid, you decided as a programmer

371
00:19:56,660 --> 00:19:59,740
 that the state of the program was not recoverable,

372
00:19:59,740 --> 00:20:01,100
 and you just panic.

373
00:20:01,100 --> 00:20:05,660
 And this is very useful in a development scenario

374
00:20:05,660 --> 00:20:09,300
 because you just don't care about if the result is

375
00:20:09,300 --> 00:20:11,180
 going to be there or not, and you can just

376
00:20:11,180 --> 00:20:12,820
 put unwrap everywhere as a developer,

377
00:20:12,820 --> 00:20:14,620
 and it's going to speed up your development.

378
00:20:14,620 --> 00:20:17,220
 And you can come back to those unwraps later

379
00:20:17,220 --> 00:20:22,940
 and maybe add some management of these edge cases.

380
00:20:22,940 --> 00:20:25,900
 But sometimes those unwraps get forgotten in the code.

381
00:20:25,900 --> 00:20:28,020
 And this was a situation where in some kind

382
00:20:28,020 --> 00:20:29,940
 of a decentralized exchange, there

383
00:20:29,940 --> 00:20:32,740
 was a conversion function that was

384
00:20:32,740 --> 00:20:34,780
 doing a check multiplication.

385
00:20:34,780 --> 00:20:36,180
 And the programmers had forgotten

386
00:20:36,180 --> 00:20:39,820
 to handle the case where the check multiplication was

387
00:20:39,820 --> 00:20:44,220
 returning a non-valid result, like if it was overflowing.

388
00:20:44,220 --> 00:20:47,100
 And it was just unwrapping, and then basically the whole node

389
00:20:47,100 --> 00:20:51,900
 might just go boom and have to restart its process.

390
00:20:51,900 --> 00:21:01,020
 So these are perfect targets for the fuzzers, by the way.

391
00:21:01,020 --> 00:21:04,060
 That will be showing up in a bit.

392
00:21:04,060 --> 00:21:06,060
 OK, so in the beginning of the presentation,

393
00:21:06,060 --> 00:21:10,380
 I was telling you that you can create your own runtime just

394
00:21:10,380 --> 00:21:13,300
 by cherry picking some modules that are already

395
00:21:13,300 --> 00:21:16,020
 provided by the framework.

396
00:21:16,020 --> 00:21:19,420
 But now when you actually create and import these modules,

397
00:21:19,420 --> 00:21:22,700
 you are also supposed to set some parameters

398
00:21:22,700 --> 00:21:23,780
 for these modules.

399
00:21:23,780 --> 00:21:25,900
 And there might be a bug in there,

400
00:21:25,900 --> 00:21:30,420
 actually, if you don't set these parameters correctly.

401
00:21:30,420 --> 00:21:33,620
 In Substrate, each account has actually--

402
00:21:33,620 --> 00:21:35,500
 it's represented by a structure.

403
00:21:35,500 --> 00:21:38,900
 And inside, we're going to find the balance of the user,

404
00:21:38,900 --> 00:21:40,260
 some internal counters.

405
00:21:40,260 --> 00:21:43,620
 And you can also enhance these structures

406
00:21:43,620 --> 00:21:46,420
 with more parameters that are specific to your project.

407
00:21:46,420 --> 00:21:49,700
 So basically, each account is going

408
00:21:49,700 --> 00:21:54,540
 to take some space in the storage of the blockchain.

409
00:21:54,540 --> 00:21:57,660
 Now the idea is that you should not

410
00:21:57,660 --> 00:22:02,140
 be able to store such data and have such an account if there

411
00:22:02,140 --> 00:22:04,500
 is no token in your account.

412
00:22:04,500 --> 00:22:07,220
 And for this, there is a parameter

413
00:22:07,220 --> 00:22:09,340
 that is called existential deposit.

414
00:22:09,340 --> 00:22:12,500
 And basically, this parameter will say, hey,

415
00:22:12,500 --> 00:22:17,940
 this account is allowed to exist as long as there is at least

416
00:22:17,940 --> 00:22:21,740
 an x amount of tokens in that account.

417
00:22:21,740 --> 00:22:25,580
 Now, it often happens that this existential deposit

418
00:22:25,580 --> 00:22:28,660
 is being set to zero or to a small value,

419
00:22:28,660 --> 00:22:31,380
 such as during the development process,

420
00:22:31,380 --> 00:22:35,140
 it's just easier for the developers to test everything.

421
00:22:35,140 --> 00:22:37,540
 But if this goes into production,

422
00:22:37,540 --> 00:22:42,100
 then a criminal will be able to come in and create

423
00:22:42,100 --> 00:22:46,700
 a super large amount of accounts for a very small fee

424
00:22:46,700 --> 00:22:49,340
 or also for free.

425
00:22:49,340 --> 00:22:51,220
 So basically, in the end, bloating

426
00:22:51,220 --> 00:22:55,180
 the storage of the blockchain and making it run slower

427
00:22:55,180 --> 00:22:58,100
 and slower in the long run.

428
00:22:58,100 --> 00:23:00,340
 All right, now we're going to move to storage bloating

429
00:23:00,340 --> 00:23:01,740
 as a class of issues itself.

430
00:23:01,740 --> 00:23:07,140
 I mean, Gabi already explained most of the issue already.

431
00:23:07,140 --> 00:23:08,560
 The issue with storage bloating is

432
00:23:08,560 --> 00:23:12,060
 that if you, as a random person, try

433
00:23:12,060 --> 00:23:14,100
 to join the network in the future with a full node

434
00:23:14,100 --> 00:23:16,540
 or something, if you have to download terabytes of data

435
00:23:16,540 --> 00:23:20,420
 to actually make the node run, it's not going to be easy.

436
00:23:20,420 --> 00:23:22,980
 It's not going to--

437
00:23:22,980 --> 00:23:28,340
 yeah, it's not going to make it universally available

438
00:23:28,340 --> 00:23:32,660
 to everybody if you have to download terabytes of data.

439
00:23:32,660 --> 00:23:36,820
 So yeah, so we take this class of bugs

440
00:23:36,820 --> 00:23:39,540
 seriously when we review a project.

441
00:23:39,540 --> 00:23:43,420
 If the fee for creating some kind of storage item

442
00:23:43,420 --> 00:23:48,140
 is way too low, then we report that to the teams.

443
00:23:48,140 --> 00:23:51,180
 And here, in this specific situation,

444
00:23:51,180 --> 00:23:54,200
 there was a module under construction

445
00:23:54,200 --> 00:23:57,980
 that was handling bridges to other chains.

446
00:23:57,980 --> 00:24:01,780
 And it was not ready yet, but they wanted still

447
00:24:01,780 --> 00:24:05,300
 to publish the code without the actual bridges part

448
00:24:05,300 --> 00:24:05,820
 implemented.

449
00:24:05,820 --> 00:24:07,900
 So they just had the registration

450
00:24:07,900 --> 00:24:09,660
 of bridges open to the public so that you

451
00:24:09,660 --> 00:24:12,580
 could pre-register your bridges with the identifications

452
00:24:12,580 --> 00:24:13,500
 you wanted.

453
00:24:13,500 --> 00:24:14,900
 And then in the future, you would

454
00:24:14,900 --> 00:24:19,060
 be able to send out those--

455
00:24:19,060 --> 00:24:21,020
 to create those bridges for real.

456
00:24:21,020 --> 00:24:24,900
 The thing is here, they had said the required state for--

457
00:24:24,900 --> 00:24:28,940
 the required amount that you needed for creating a bridge,

458
00:24:28,940 --> 00:24:29,580
 way too low.

459
00:24:29,580 --> 00:24:31,320
 Like, this is 1 million, and it basically

460
00:24:31,320 --> 00:24:36,320
 means 1 million of thousands of a fraction

461
00:24:36,320 --> 00:24:38,680
 of a millionth of a cent.

462
00:24:38,680 --> 00:24:45,280
 So in the end, it's like almost nothing in euro terms.

463
00:24:45,280 --> 00:24:47,300
 So you could just register--

464
00:24:47,300 --> 00:24:49,720
 spam this bridge registering, and it

465
00:24:49,720 --> 00:24:53,040
 would allocate quite a big amount of data on the chain.

466
00:24:53,040 --> 00:24:55,160
 But most importantly, in the future,

467
00:24:55,160 --> 00:24:58,960
 when those bridges would actually be implemented for real,

468
00:24:58,960 --> 00:25:01,220
 this amount of data would actually probably

469
00:25:01,220 --> 00:25:02,840
 also go up.

470
00:25:02,840 --> 00:25:11,000
 So yeah, this is a classic storage bloating issue.

471
00:25:11,000 --> 00:25:15,880
 OK, so now that you are aware of what type of bugs

472
00:25:15,880 --> 00:25:17,440
 are we looking for in the blockchain,

473
00:25:17,440 --> 00:25:19,600
 you might be wondering, how can I actually

474
00:25:19,600 --> 00:25:21,680
 start finding some of this?

475
00:25:21,680 --> 00:25:25,440
 And there are at least three techniques that you can use.

476
00:25:25,440 --> 00:25:28,360
 Two of them are automated, and the third one,

477
00:25:28,360 --> 00:25:30,200
 it's the manual code review.

478
00:25:30,200 --> 00:25:31,860
 We're going to start with the third one.

479
00:25:31,860 --> 00:25:36,540
 So basically, if you are already doing some manual code review,

480
00:25:36,540 --> 00:25:42,000
 it should be quite easy for you to move to the blockchain world.

481
00:25:42,000 --> 00:25:47,100
 But you have to keep in mind that a different threat model

482
00:25:47,100 --> 00:25:49,900
 will be applied here.

483
00:25:49,900 --> 00:25:53,780
 Because, for example, in an Android application,

484
00:25:53,780 --> 00:25:57,380
 let's say, if you have a crash, OK, that's fine.

485
00:25:57,860 --> 00:26:00,580
 The app is going to crash, you just open it again.

486
00:26:00,580 --> 00:26:03,260
 But in a blockchain, if you have a crash,

487
00:26:03,260 --> 00:26:05,360
 that might actually be a critical vulnerability

488
00:26:05,360 --> 00:26:05,860
 in the end.

489
00:26:05,860 --> 00:26:08,260
 So for the manual code review, you just

490
00:26:08,260 --> 00:26:11,440
 need to change a bit the threat modeling

491
00:26:11,440 --> 00:26:14,980
 and look for different stuff.

492
00:26:14,980 --> 00:26:19,860
 Then keeping in mind the five classes of bugs

493
00:26:19,860 --> 00:26:23,460
 that we've showed, you are kind of on a good track

494
00:26:23,460 --> 00:26:29,260
 to actually be able to start finding these bugs as well.

495
00:26:29,260 --> 00:26:33,540
 Mostly using fuzzing, and for this

496
00:26:33,540 --> 00:26:37,860
 we are also going to give you a demo about fuzzing.

497
00:26:37,860 --> 00:26:42,340
 Mostly we are finding a lot of bugs with static analysis

498
00:26:42,340 --> 00:26:44,400
 and fuzzing.

499
00:26:44,400 --> 00:26:46,460
 Mostly all of them, I would say.

500
00:26:46,460 --> 00:26:48,060
 But of course, the manual review,

501
00:26:48,060 --> 00:26:52,300
 it's all the time complementary.

502
00:26:52,300 --> 00:26:55,220
 All right, so very quickly, what's fuzzing

503
00:26:55,220 --> 00:27:00,020
 and how do we apply it to these blockchain projects?

504
00:27:00,020 --> 00:27:01,700
 Fuzzing is when you take a program

505
00:27:01,700 --> 00:27:04,580
 and you feed it a whole bunch of inputs

506
00:27:04,580 --> 00:27:07,740
 and you wait for any kind of misbehavior

507
00:27:07,740 --> 00:27:12,300
 to happen or something that you've aligned to trigger.

508
00:27:12,300 --> 00:27:15,760
 And in this situation, the program

509
00:27:15,760 --> 00:27:17,660
 is the blockchain runtime itself.

510
00:27:17,660 --> 00:27:19,340
 So the part of the blockchain that

511
00:27:19,340 --> 00:27:21,300
 executes transactions one after the other

512
00:27:21,300 --> 00:27:24,380
 and that interacts with the storage and everything else.

513
00:27:24,380 --> 00:27:28,340
 And our fuzzers are coverage-guided fuzzers,

514
00:27:28,340 --> 00:27:30,340
 and they're going to look at the code coverage

515
00:27:30,340 --> 00:27:33,980
 inside of the blockchain application

516
00:27:33,980 --> 00:27:36,060
 to see what's interesting and what's not.

517
00:27:36,060 --> 00:27:40,060
 And yeah, it's going to find really complex stuff quite fast

518
00:27:40,060 --> 00:27:43,740
 and that it really works very well in this situation.

519
00:27:43,740 --> 00:27:46,260
 So to make it really quick, the fuzzer

520
00:27:46,260 --> 00:27:49,580
 is going to have a bunch of potential inputs.

521
00:27:49,580 --> 00:27:52,220
 It's maybe going to apply some mutations to it.

522
00:27:52,220 --> 00:27:56,180
 Then the fuzzing harness will decode these inputs.

523
00:27:56,180 --> 00:27:59,740
 So take one input and split it into a few transactions,

524
00:27:59,740 --> 00:28:02,140
 decode those transactions, and then run them

525
00:28:02,140 --> 00:28:04,820
 one after the other, maybe skipping a few blocks here

526
00:28:04,820 --> 00:28:08,700
 and there for timing purposes.

527
00:28:08,700 --> 00:28:13,220
 And then the target is going to just run the program.

528
00:28:13,220 --> 00:28:16,220
 And if we find some kind of an overflow, some kind of a crash,

529
00:28:16,220 --> 00:28:23,740
 some kind of a timeout, or any other pre-programmed values

530
00:28:23,740 --> 00:28:28,940
 that we've set to trigger, yeah, it's going to report a crash,

531
00:28:28,940 --> 00:28:32,580
 and we'll take a manual look.

532
00:28:32,580 --> 00:28:37,460
 All right, now time for the demo.

533
00:28:37,460 --> 00:28:40,700
 So we launched a fuzzer a bit before the talk.

534
00:28:40,700 --> 00:28:44,780
 We hope it found the crash that we wanted it to find.

535
00:28:44,780 --> 00:28:48,580
 Just to show you, this is one interesting part

536
00:28:48,580 --> 00:28:51,580
 of the runtime code that we're going to fuzz.

537
00:28:51,580 --> 00:28:54,580
 This is the template runtime, so the one

538
00:28:54,580 --> 00:28:56,380
 that you're supposed to start with if you

539
00:28:56,380 --> 00:28:58,660
 want a normal substrate stack.

540
00:28:58,660 --> 00:29:02,420
 And these define the different modules

541
00:29:02,420 --> 00:29:04,080
 that you're going to have in your chain.

542
00:29:04,080 --> 00:29:07,460
 So the interesting one here is the template module,

543
00:29:07,460 --> 00:29:10,060
 which is, as it says, a template module, which

544
00:29:10,060 --> 00:29:11,340
 is defined right there.

545
00:29:11,340 --> 00:29:13,700
 And in this template module, you have two calls.

546
00:29:13,700 --> 00:29:15,620
 The first one is called do something.

547
00:29:15,620 --> 00:29:19,580
 It's going to take a U32 as an input,

548
00:29:19,580 --> 00:29:21,940
 and it's going to put it into a storage item.

549
00:29:21,940 --> 00:29:25,060
 The second one is called cause error.

550
00:29:25,060 --> 00:29:28,780
 It's to show you how an operation can cause an error

551
00:29:28,780 --> 00:29:31,140
 and return an error in a safe way.

552
00:29:31,140 --> 00:29:33,600
 And it's going to take the value that you put into storage.

553
00:29:33,600 --> 00:29:35,860
 If it was nothing, then it's going to return an error.

554
00:29:35,860 --> 00:29:38,140
 If it was something, then it's going to increment it.

555
00:29:38,140 --> 00:29:43,900
 Now, the original code for this is a checked addition.

556
00:29:43,900 --> 00:29:48,220
 And the code that we actually replaced it

557
00:29:48,220 --> 00:29:51,620
 with to find a crash is just new is equal to old plus 1.

558
00:29:51,620 --> 00:29:54,500
 So unchecked math, the classic mistake

559
00:29:54,500 --> 00:29:56,300
 that we see over and over again.

560
00:29:56,300 --> 00:29:59,860
 And then it puts that new value into storage.

561
00:29:59,860 --> 00:30:03,520
 Now, let's look at our fuzzer for a bit.

562
00:30:03,520 --> 00:30:04,780
 It's like 300 lines of code.

563
00:30:04,780 --> 00:30:06,820
 It's open source.

564
00:30:06,820 --> 00:30:10,740
 I'll show you the repo in a bit.

565
00:30:10,740 --> 00:30:14,420
 And yeah, you basically decode stuff and then run the--

566
00:30:14,420 --> 00:30:16,900
 let me show you the running of it.

567
00:30:16,900 --> 00:30:20,780
 You just run the extrinsic here, and the rest

568
00:30:20,780 --> 00:30:25,700
 is basically stuff that we've added over the years

569
00:30:25,700 --> 00:30:27,060
 to make sure that the--

570
00:30:27,060 --> 00:30:34,100
 to make sure the situation is perfect for our fuzzers

571
00:30:34,100 --> 00:30:35,260
 to find a crash.

572
00:30:35,260 --> 00:30:40,900
 So let's look at how the fuzzer has been doing.

573
00:30:40,900 --> 00:30:42,100
 It has found a crash.

574
00:30:42,100 --> 00:30:42,660
 Perfect.

575
00:30:42,660 --> 00:30:44,660
 We are going to be able to show it to you then.

576
00:30:44,660 --> 00:30:49,980
 And this crash hopefully is running the do something

577
00:30:49,980 --> 00:30:53,780
 extrinsic first, the do something operation with U32

578
00:30:53,780 --> 00:30:56,860
 max, and then cause error.

579
00:30:56,860 --> 00:30:59,580
 And this should crash the chain because there was an overflow.

580
00:30:59,580 --> 00:31:01,200
 Oh, yeah, one thing I forgot to mention

581
00:31:01,200 --> 00:31:03,740
 is that the fuzzer has some checks enabled.

582
00:31:03,740 --> 00:31:05,420
 For example, this overflow check,

583
00:31:05,420 --> 00:31:06,860
 because in a real world scenario,

584
00:31:06,860 --> 00:31:09,340
 like the blockchain would just make the value overflow

585
00:31:09,340 --> 00:31:11,580
 and you wouldn't see anything except for the value that

586
00:31:11,580 --> 00:31:12,100
 has overflowed.

587
00:31:12,100 --> 00:31:14,100
 But in our situation, we want to catch those.

588
00:31:14,100 --> 00:31:17,540
 So the fuzzer will actually catch

589
00:31:17,540 --> 00:31:19,980
 those overflows as crashes.

590
00:31:19,980 --> 00:31:22,100
 All right, so this is Ziggy.

591
00:31:22,100 --> 00:31:25,980
 It's our in-house manager of fuzzers.

592
00:31:25,980 --> 00:31:29,180
 It launches an AFL instance, or a few.

593
00:31:29,180 --> 00:31:32,100
 I think there are like 40 of them on this server.

594
00:31:32,100 --> 00:31:34,420
 And also, HongFuzz in parallel, and then they

595
00:31:34,420 --> 00:31:39,140
 share corpus so that they can learn from each other.

596
00:31:39,140 --> 00:31:44,140
 And yeah, let's try to run the crash that we found.

597
00:31:44,140 --> 00:31:46,020
 All right, what does it say?

598
00:31:46,020 --> 00:31:51,260
 It says that it tried to do something

599
00:31:51,260 --> 00:31:54,380
 with a value that looks very much like U32 max,

600
00:31:54,380 --> 00:31:56,300
 and then it ran cause error.

601
00:31:56,300 --> 00:31:59,380
 And yeah, there it crashed to attempt to add with overflow.

602
00:31:59,380 --> 00:32:03,420
 So we found the bug that we had planted there in our template.

603
00:32:03,420 --> 00:32:07,140
 And this is a very easy, or quite easy way

604
00:32:07,140 --> 00:32:12,900
 to find a lot of bugs in many blockchain systems.

605
00:32:12,900 --> 00:32:16,500
 Now, to show you the impact that this have had--

606
00:32:16,500 --> 00:32:18,620
 oh, yeah, first.

607
00:32:18,620 --> 00:32:21,020
 The harness itself is open source.

608
00:32:21,020 --> 00:32:24,580
 Please go check it out in this repo.

609
00:32:24,580 --> 00:32:26,700
 The Ziggy, the tool that you saw that we

610
00:32:26,700 --> 00:32:30,620
 used to manage the fuzzers is also open source,

611
00:32:30,620 --> 00:32:32,540
 and you can find it there.

612
00:32:32,540 --> 00:32:34,860
 And now, back to Gabi.

613
00:32:34,860 --> 00:32:40,420
 OK, so now you are aware of what kind of bugs we can find them.

614
00:32:40,420 --> 00:32:43,380
 Louis just showed you that the fuzzer that we are using,

615
00:32:43,380 --> 00:32:44,300
 it's also open source.

616
00:32:44,300 --> 00:32:47,700
 So with these two, you are kind of on a good track

617
00:32:47,700 --> 00:32:51,540
 to actually start finding bugs by yourself.

618
00:32:51,540 --> 00:32:53,780
 And in the past one year and a half,

619
00:32:53,780 --> 00:32:58,340
 we analyzed 45 projects in the ecosystem.

620
00:32:58,340 --> 00:33:00,060
 And most of the bugs that we found

621
00:33:00,060 --> 00:33:04,540
 were actually found in a semi-automated way, most of them

622
00:33:04,540 --> 00:33:08,420
 using the fuzzer harness that we've showed before.

623
00:33:08,420 --> 00:33:12,540
 So the idea is that you can actually start

624
00:33:12,540 --> 00:33:14,340
 and playing around with this.

625
00:33:14,340 --> 00:33:17,500
 You can contribute to the ecosystem.

626
00:33:17,500 --> 00:33:21,420
 And you can do this out of curiosity, of course.

627
00:33:21,420 --> 00:33:24,540
 Or you can even look into some of the projects

628
00:33:24,540 --> 00:33:27,660
 in the ecosystem that are running bug bounties programs.

629
00:33:27,660 --> 00:33:33,700
 So in the end, while we--

630
00:33:33,700 --> 00:33:36,900
 like in the past one year and a half, two years,

631
00:33:36,900 --> 00:33:39,780
 we developed our tooling all the time

632
00:33:39,780 --> 00:33:42,780
 in order to be able to automate as much as possible

633
00:33:42,780 --> 00:33:46,500
 and cover as many projects as we could.

634
00:33:46,500 --> 00:33:48,380
 But of course, as I said in the beginning,

635
00:33:48,380 --> 00:33:51,340
 there are over 150 projects in the ecosystem.

636
00:33:51,340 --> 00:33:53,300
 We covered only 45 so far.

637
00:33:53,300 --> 00:33:57,220
 So we are kind of aware that in order to have an impact,

638
00:33:57,220 --> 00:34:01,340
 we need the help of the community for this.

639
00:34:01,340 --> 00:34:04,460
 And this is why we also open sourced the fuzzer.

640
00:34:04,460 --> 00:34:08,180
 And we encourage you to start playing around with that.

641
00:34:08,180 --> 00:34:11,660
 You can consider it a new game, a new puzzle, whatever

642
00:34:11,660 --> 00:34:14,460
 gets you excited about it.

643
00:34:14,460 --> 00:34:18,220
 Also, as I was saying about the manual code review,

644
00:34:18,220 --> 00:34:22,620
 the ecosystem itself kind of needs a different threat

645
00:34:22,620 --> 00:34:28,900
 modeling than the usual security reviews that we are doing.

646
00:34:28,900 --> 00:34:31,420
 So the entire ecosystem would benefit

647
00:34:31,420 --> 00:34:36,740
 if both the developers and the security researchers

648
00:34:36,740 --> 00:34:40,940
 will start to collaborate more and share this new threat

649
00:34:40,940 --> 00:34:42,860
 modeling with everyone.

650
00:34:42,860 --> 00:34:46,900
 So with that being said, thank you very much for making it

651
00:34:46,900 --> 00:34:49,300
 to our talk this morning.

652
00:34:49,300 --> 00:34:53,180
 And we are waiting for your PRs, comments, or anything

653
00:34:53,180 --> 00:34:55,220
 on the open source fuzzer.

654
00:34:55,220 --> 00:34:56,220
 Thank you.

655
00:34:56,220 --> 00:34:59,700
 [APPLAUSE]

656
00:34:59,700 --> 00:35:09,660
 We still have some time for a few questions.

657
00:35:09,660 --> 00:35:12,940
 If you have a question, please line up at the microphone

658
00:35:12,940 --> 00:35:13,820
 over there.

659
00:35:13,820 --> 00:35:16,580
 Signal Angel, is the internet already awake?

660
00:35:16,580 --> 00:35:17,980
 No, the internet is still asleep.

661
00:35:17,980 --> 00:35:20,020
 They do not have any questions.

662
00:35:20,020 --> 00:35:21,980
 Anyone else from the audience with a question?

663
00:35:21,980 --> 00:35:30,940
 I didn't understand the incentives

664
00:35:30,940 --> 00:35:39,020
 for paying $25,000 to use one gigabyte of storage

665
00:35:39,020 --> 00:35:41,060
 on the blockchain.

666
00:35:41,060 --> 00:35:42,540
 What's the attacker model?

667
00:35:42,540 --> 00:35:44,820
 Who would want to do that?

668
00:35:44,820 --> 00:35:46,380
 That's a good point.

669
00:35:46,380 --> 00:35:48,300
 Yeah, I heard other blockchains right there.

670
00:35:48,300 --> 00:35:50,020
 I guess, yeah, you have an incentive

671
00:35:50,020 --> 00:35:54,460
 to make your competitor project as hard to get into as

672
00:35:54,460 --> 00:35:55,260
 possible.

673
00:35:55,260 --> 00:35:59,300
 And it is a lot of money, this $25,000 for one gigabyte.

674
00:35:59,300 --> 00:36:02,660
 But if you compare it to other blockchains,

675
00:36:02,660 --> 00:36:05,100
 for example, Ethereum, you would need

676
00:36:05,100 --> 00:36:06,820
 to pay tens of millions of dollars

677
00:36:06,820 --> 00:36:10,820
 to actually put a gigabyte on that blockchain.

678
00:36:10,820 --> 00:36:14,460
 Then the idea is that you make it harder for other people

679
00:36:14,460 --> 00:36:16,860
 to get into the ecosystem.

680
00:36:16,860 --> 00:36:20,540
 And I mean, this issue was probably low,

681
00:36:20,540 --> 00:36:23,780
 or maybe medium severity, probably low.

682
00:36:23,780 --> 00:36:25,540
 But potentially, you could find something

683
00:36:25,540 --> 00:36:28,860
 that scales even better, where you can actually

684
00:36:28,860 --> 00:36:31,700
 go hard on the storage.

685
00:36:31,700 --> 00:36:36,980
 So don't asynchronous programming paradigms

686
00:36:36,980 --> 00:36:40,660
 and things like this usually say that you should embrace panics?

687
00:36:41,100 --> 00:36:47,500
 And isn't it a major failure to try and exclude all the panics?

688
00:36:47,500 --> 00:36:49,940
 Yeah, that's an interesting idea.

689
00:36:49,940 --> 00:36:56,380
 I guess in that scenario, some nodes

690
00:36:56,380 --> 00:36:59,300
 are incentivized to publish blocks,

691
00:36:59,300 --> 00:37:01,860
 because they will get some reward out of it.

692
00:37:01,860 --> 00:37:06,580
 And if an attacker can make them unable to produce them,

693
00:37:06,580 --> 00:37:08,500
 they might even get punished for it.

694
00:37:08,500 --> 00:37:15,420
 So yeah, I guess in a theoretical way, I agree.

695
00:37:15,420 --> 00:37:17,780
 But the incentives are aligned so

696
00:37:17,780 --> 00:37:21,020
 that an attacker wanting to make a node panic

697
00:37:21,020 --> 00:37:26,980
 will actually cause a bit of mayhem in the process.

698
00:37:26,980 --> 00:37:34,380
 Thank you for your talk.

699
00:37:34,380 --> 00:37:37,220
 Let's give another round of applause to Louis and Gabi.

700
00:37:37,220 --> 00:37:40,580
 [APPLAUSE]

701
00:37:40,580 --> 00:37:43,940
 [MUSIC PLAYING]

702
00:37:44,900 --> 00:37:48,260
 [MUSIC PLAYING]

703
00:37:48,260 --> 00:37:52,500
 [Music]