WEBVTT

1
00:00:00.120 --> 00:00:04.400
<v Speaker 1>Welcome back to the deep Dive. Today we are we're

2
00:00:04.440 --> 00:00:07.440
<v Speaker 1>not just looking at a technical glitch. We are staring

3
00:00:07.480 --> 00:00:10.679
<v Speaker 1>into the abyss of one of the most enduring, dangerous,

4
00:00:10.720 --> 00:00:14.439
<v Speaker 1>and honestly philosophically fascinating concepts in computer security.

5
00:00:14.599 --> 00:00:17.839
<v Speaker 2>It really is it's the vulnerability that just refuses to die,

6
00:00:18.280 --> 00:00:19.399
<v Speaker 2>the classic boogeyman.

7
00:00:19.760 --> 00:00:23.399
<v Speaker 1>We are talking about buffer overflows. And if that term

8
00:00:23.480 --> 00:00:25.640
<v Speaker 1>makes you think of, I don't know, a plumbing disaster,

9
00:00:26.239 --> 00:00:27.559
<v Speaker 1>You're not entirely.

10
00:00:27.239 --> 00:00:29.640
<v Speaker 2>Wrong, not at all. It's just that the pipes are

11
00:00:29.679 --> 00:00:33.640
<v Speaker 2>memory and the water is malicious coat. And to guide

12
00:00:33.719 --> 00:00:36.560
<v Speaker 2>us through this, we're digging into a really foundational.

13
00:00:36.039 --> 00:00:40.200
<v Speaker 1>Text, right the book Buffer Overflow Attacks, Detect, Exploit, Prevent

14
00:00:40.280 --> 00:00:41.439
<v Speaker 1>by James C. Foster.

15
00:00:41.719 --> 00:00:44.280
<v Speaker 2>It's a technical book, for sure, but it gets surprisingly

16
00:00:44.359 --> 00:00:45.840
<v Speaker 2>deep on the why of it all.

17
00:00:46.039 --> 00:00:48.479
<v Speaker 1>And we're pairing that with a really striking forward by

18
00:00:48.560 --> 00:00:51.240
<v Speaker 1>Dave Tell, who frames this whole topic in a way

19
00:00:51.280 --> 00:00:54.200
<v Speaker 1>I just did not expect. It's less like computer science

20
00:00:54.200 --> 00:00:55.679
<v Speaker 1>and more like a martial art, and.

21
00:00:55.560 --> 00:00:57.840
<v Speaker 2>That's exactly where we're talking about this. It's so easy

22
00:00:57.840 --> 00:01:01.200
<v Speaker 2>to dismiss buffer overflows as the you know, old school

23
00:01:01.200 --> 00:01:02.840
<v Speaker 2>bug from the nineties.

24
00:01:02.560 --> 00:01:04.519
<v Speaker 1>Yeah, something we should have solved by now.

25
00:01:04.760 --> 00:01:07.519
<v Speaker 2>But the source material makes this compelling case. If you

26
00:01:07.560 --> 00:01:10.840
<v Speaker 2>want to understand security, you have to understand the overflow.

27
00:01:11.519 --> 00:01:15.560
<v Speaker 2>It is the fundamental proof that the software community still

28
00:01:15.599 --> 00:01:18.239
<v Speaker 2>doesn't fully get how to design secure code.

29
00:01:18.599 --> 00:01:21.159
<v Speaker 1>That is a heavy statement, proof we don't know how

30
00:01:21.159 --> 00:01:24.439
<v Speaker 1>to write secure code. It is so our mission today

31
00:01:24.519 --> 00:01:26.280
<v Speaker 1>is to dig into that. We want to move past

32
00:01:26.280 --> 00:01:31.000
<v Speaker 1>the buzzwords and really understand the mechanics, the stack, the heap,

33
00:01:31.239 --> 00:01:33.120
<v Speaker 1>the shell code, and figure out.

34
00:01:33.000 --> 00:01:36.680
<v Speaker 2>Why on earth writing an exploit is described as a

35
00:01:36.760 --> 00:01:37.719
<v Speaker 2>statement of truth.

36
00:01:37.920 --> 00:01:40.640
<v Speaker 1>Okay, but before we get into the you know, truth

37
00:01:40.760 --> 00:01:43.280
<v Speaker 1>and beauty of it all, let's ground this in reality,

38
00:01:43.319 --> 00:01:46.040
<v Speaker 1>because when these things go wrong, they go wrong in public.

39
00:01:46.560 --> 00:01:49.120
<v Speaker 1>And my favorite example from the book involves Madonna.

40
00:01:49.239 --> 00:01:52.599
<v Speaker 2>Oh, this story is incredible. It's this perfect collision of celebrity,

41
00:01:52.680 --> 00:01:55.760
<v Speaker 2>copyright and hackers with way too much time on their hands.

42
00:01:55.799 --> 00:01:57.920
<v Speaker 1>So let's set the scene. It's April two thousand and

43
00:01:57.920 --> 00:02:01.120
<v Speaker 1>three and napster is gone, but file sharing is just exploding.

44
00:02:01.359 --> 00:02:03.840
<v Speaker 1>Everyone's on Khaza LimeWire.

45
00:02:03.439 --> 00:02:05.640
<v Speaker 2>Right, and Madonna is about to release her new album,

46
00:02:05.760 --> 00:02:08.800
<v Speaker 2>American Life, and she decides no, the parrots are not

47
00:02:08.840 --> 00:02:09.240
<v Speaker 2>gonna win.

48
00:02:09.520 --> 00:02:12.680
<v Speaker 1>She's taking a stand, so her team floods these networks

49
00:02:12.680 --> 00:02:13.599
<v Speaker 1>with decoy files.

50
00:02:13.680 --> 00:02:16.800
<v Speaker 2>Exactly, you think you're downloading her new single, you wait

51
00:02:16.840 --> 00:02:19.800
<v Speaker 2>an hour on your dial up modem, I remember that pain,

52
00:02:20.080 --> 00:02:22.479
<v Speaker 2>and when you finally play it, it's not the song.

53
00:02:23.240 --> 00:02:26.520
<v Speaker 2>It's just a loop of Madonna's voice saying what the

54
00:02:26.560 --> 00:02:27.960
<v Speaker 2>fuck do you think you're doing.

55
00:02:28.120 --> 00:02:30.520
<v Speaker 1>Which honestly is a pretty punk rock move for a

56
00:02:30.560 --> 00:02:33.240
<v Speaker 1>pop star. What do you think you're doing? It's so direct,

57
00:02:33.400 --> 00:02:33.719
<v Speaker 1>it is.

58
00:02:34.319 --> 00:02:36.520
<v Speaker 2>But you just don't poke the internet bear like that

59
00:02:36.560 --> 00:02:37.759
<v Speaker 2>and expect nothing to happen.

60
00:02:37.879 --> 00:02:40.280
<v Speaker 1>No, the retaliation was swift.

61
00:02:40.479 --> 00:02:42.680
<v Speaker 2>A group of hackers, rumored to be the editors of

62
00:02:42.680 --> 00:02:46.560
<v Speaker 2>Frag magazine, though they denied it, decided to target Madonna

63
00:02:46.599 --> 00:02:47.560
<v Speaker 2>dot com itself.

64
00:02:47.680 --> 00:02:50.159
<v Speaker 1>And this wasn't social engineering, right. They didn't just guess

65
00:02:50.159 --> 00:02:51.000
<v Speaker 1>her pastorng No.

66
00:02:50.759 --> 00:02:53.960
<v Speaker 2>No, no, this is a pure technical takedown. They found

67
00:02:54.080 --> 00:02:57.759
<v Speaker 2>a buffer overflow of vulnerability in her web server software.

68
00:02:57.759 --> 00:03:00.240
<v Speaker 2>They didn't just crash the site, They exploited it, took

69
00:03:00.280 --> 00:03:04.199
<v Speaker 2>it over, and the defacement was so personal, extremely They

70
00:03:04.240 --> 00:03:07.280
<v Speaker 2>wiped the site and posted the actual MP three's of

71
00:03:07.280 --> 00:03:09.000
<v Speaker 2>her new album for free download.

72
00:03:09.080 --> 00:03:10.840
<v Speaker 1>Basically saying you want to hide it here It is

73
00:03:10.879 --> 00:03:12.479
<v Speaker 1>for everybody but the kicker.

74
00:03:13.080 --> 00:03:16.120
<v Speaker 2>The real chef's kiss was the message they left on

75
00:03:16.159 --> 00:03:16.800
<v Speaker 2>the homepage.

76
00:03:16.879 --> 00:03:17.680
<v Speaker 1>This is the best part.

77
00:03:17.840 --> 00:03:21.159
<v Speaker 2>They changed the headline to mimic her decoy file. It

78
00:03:21.280 --> 00:03:24.439
<v Speaker 2>just read this is what the fuck I think I'm doing.

79
00:03:24.639 --> 00:03:27.759
<v Speaker 1>That is brutal, such a specific clap back.

80
00:03:27.919 --> 00:03:30.120
<v Speaker 2>And then, just for good measure, they added a marriage

81
00:03:30.159 --> 00:03:31.960
<v Speaker 2>proposal to Morgan Webb from tech TV.

82
00:03:32.240 --> 00:03:35.120
<v Speaker 1>It was just this perfect storm of technical skill and

83
00:03:35.199 --> 00:03:36.039
<v Speaker 1>internet trolling.

84
00:03:36.120 --> 00:03:38.759
<v Speaker 2>But the real takeaway for us is the access. This

85
00:03:38.919 --> 00:03:42.400
<v Speaker 2>wasn't a glitch. This was total control. They owned that machine.

86
00:03:42.439 --> 00:03:45.879
<v Speaker 1>That distinction is so key. So let's peel back the layers.

87
00:03:45.919 --> 00:03:48.319
<v Speaker 1>How do you get from sending too much data to

88
00:03:48.840 --> 00:03:52.759
<v Speaker 1>owning the machine? Let's define the beast. What is actually overflowing?

89
00:03:52.960 --> 00:03:55.919
<v Speaker 2>Okay, so let's break this down. A buffer is really

90
00:03:55.960 --> 00:03:58.280
<v Speaker 2>just a fancy name for a container in the computer's memory.

91
00:03:58.680 --> 00:04:01.000
<v Speaker 2>Think of it like a bucket and ram set aside

92
00:04:01.039 --> 00:04:02.479
<v Speaker 2>to hold say a username.

93
00:04:02.520 --> 00:04:06.039
<v Speaker 1>Okay, so a bucket designed to hold ten characters exactly.

94
00:04:05.599 --> 00:04:07.960
<v Speaker 2>And overflow is just trying to pour one hundred characters

95
00:04:07.960 --> 00:04:10.240
<v Speaker 2>into that ten character bucket. In the real world, it

96
00:04:10.280 --> 00:04:14.039
<v Speaker 2>spills on the floor. In computer memory, there is no floor.

97
00:04:14.120 --> 00:04:15.159
<v Speaker 1>There's no empty space.

98
00:04:15.520 --> 00:04:18.879
<v Speaker 2>No, everything is packed in right next to everything else.

99
00:04:19.160 --> 00:04:21.959
<v Speaker 2>When you spill over, you're not spilling onto the floor.

100
00:04:22.160 --> 00:04:25.720
<v Speaker 2>You're spilling into the next bucket over. You're physically overriding

101
00:04:25.839 --> 00:04:27.240
<v Speaker 2>whatever data was sitting there.

102
00:04:27.639 --> 00:04:29.680
<v Speaker 1>And that data could be anything. It could be part

103
00:04:29.720 --> 00:04:32.519
<v Speaker 1>of a picture, or it could be a critical system instruction.

104
00:04:32.759 --> 00:04:36.759
<v Speaker 2>Precisely, and this is where the geography of memory really matters.

105
00:04:37.240 --> 00:04:40.160
<v Speaker 2>The source breaks it down into two main types, stack

106
00:04:40.199 --> 00:04:42.319
<v Speaker 2>overflows and heap corruption.

107
00:04:43.079 --> 00:04:44.879
<v Speaker 1>Let's start with the stack. That's the one you always

108
00:04:44.879 --> 00:04:45.600
<v Speaker 1>hear about movies.

109
00:04:45.680 --> 00:04:48.639
<v Speaker 2>It is because it's the most common. The stack is

110
00:04:48.680 --> 00:04:52.839
<v Speaker 2>this very neat organized part of memory for temporary stuff

111
00:04:53.279 --> 00:04:56.120
<v Speaker 2>like a stack of plates. But buried in that stack

112
00:04:56.120 --> 00:04:59.759
<v Speaker 2>of plates is something incredibly important called the return address.

113
00:05:00.120 --> 00:05:02.639
<v Speaker 1>The return address that's the bookmark, right. It tells the

114
00:05:02.680 --> 00:05:03.879
<v Speaker 1>program where to go back to.

115
00:05:04.759 --> 00:05:07.759
<v Speaker 2>That's a perfect analogy. When a program runs a little

116
00:05:07.800 --> 00:05:10.959
<v Speaker 2>side task like check password, it needs to know where

117
00:05:10.959 --> 00:05:13.920
<v Speaker 2>to return to. When it's done, it writes that location,

118
00:05:14.040 --> 00:05:16.000
<v Speaker 2>that return address, onto the stack.

119
00:05:16.079 --> 00:05:17.519
<v Speaker 1>So it's like, okay, I'm going to go do this,

120
00:05:17.720 --> 00:05:19.480
<v Speaker 1>and when I'm finished. I'll come right back to this

121
00:05:19.560 --> 00:05:21.040
<v Speaker 1>line of code exactly.

122
00:05:21.279 --> 00:05:24.000
<v Speaker 2>Now, imagine your buffer, your bucket is sitting right next

123
00:05:24.000 --> 00:05:26.560
<v Speaker 2>to that return address on the stack. If you pour

124
00:05:26.639 --> 00:05:30.600
<v Speaker 2>too much data in, you overflow and physically overwrite that bookmark.

125
00:05:30.680 --> 00:05:32.639
<v Speaker 1>You're erasing their map and drawing your own.

126
00:05:32.759 --> 00:05:36.120
<v Speaker 2>Yes, you replace the go back to the main program

127
00:05:36.160 --> 00:05:40.120
<v Speaker 2>instruction with go to this specific address where I've hidden

128
00:05:40.160 --> 00:05:44.360
<v Speaker 2>my own malicious code. The function finishes. The computer blindly

129
00:05:44.399 --> 00:05:47.040
<v Speaker 2>follows your new map and executes your code.

130
00:05:47.480 --> 00:05:50.399
<v Speaker 1>That's the hijack. You've turned the program into your puppet.

131
00:05:50.600 --> 00:05:54.319
<v Speaker 2>That's it. Now the heap is different. It's messier, more

132
00:05:54.360 --> 00:05:57.480
<v Speaker 2>dynamic exploiting. It is harder because it's not as predictable,

133
00:05:58.120 --> 00:05:59.079
<v Speaker 2>but still possible.

134
00:05:59.560 --> 00:06:01.800
<v Speaker 1>And the book it also mentions format strings. Is that

135
00:06:01.839 --> 00:06:02.399
<v Speaker 1>the same thing.

136
00:06:02.560 --> 00:06:04.959
<v Speaker 2>It's related. It comes from lazy programming. If you let

137
00:06:05.000 --> 00:06:08.040
<v Speaker 2>a user type in special characters like a PRESANX into

138
00:06:08.040 --> 00:06:10.399
<v Speaker 2>a function that prints text, you can trick it into

139
00:06:10.439 --> 00:06:12.480
<v Speaker 2>reading from memory or even writing to it. It's a

140
00:06:12.480 --> 00:06:13.639
<v Speaker 2>different door to the same room.

141
00:06:13.839 --> 00:06:16.040
<v Speaker 1>Okay, so we've got the mechanism, But I want to

142
00:06:16.040 --> 00:06:18.000
<v Speaker 1>go back to what Davi Tell said in the forward.

143
00:06:18.639 --> 00:06:21.160
<v Speaker 1>He talks about this whole process like it's almost spiritual.

144
00:06:21.199 --> 00:06:22.279
<v Speaker 1>He compares it to judo.

145
00:06:22.680 --> 00:06:26.399
<v Speaker 2>He does, and it fits so well. In judo, you

146
00:06:26.519 --> 00:06:29.519
<v Speaker 2>use your opponent's weight against them in a buffer overflow.

147
00:06:29.560 --> 00:06:32.079
<v Speaker 2>You're not breaking the system from the outside. You are

148
00:06:32.199 --> 00:06:35.680
<v Speaker 2>using its own software, its own memory, its own rules

149
00:06:35.720 --> 00:06:38.800
<v Speaker 2>against it. You're flipping the system with its own momentum.

150
00:06:38.839 --> 00:06:41.199
<v Speaker 1>He also says it's like weightlifting, something you have to

151
00:06:41.199 --> 00:06:42.519
<v Speaker 1>constantly practice.

152
00:06:42.680 --> 00:06:46.360
<v Speaker 2>Right. You can't just learn this once. The whole landscape

153
00:06:46.399 --> 00:06:50.360
<v Speaker 2>is a treadmill. Microsoft adds a protection hackers find a bypass,

154
00:06:50.680 --> 00:06:53.759
<v Speaker 2>a new protection, a new bypass. ATel says, if you

155
00:06:53.759 --> 00:06:57.279
<v Speaker 2>stop writing exploits for three months, your skills are basically

156
00:06:57.360 --> 00:06:58.240
<v Speaker 2>ancient history.

157
00:06:58.480 --> 00:07:01.439
<v Speaker 1>That's intense. It's not just notledge, it's performance. You have

158
00:07:01.519 --> 00:07:02.360
<v Speaker 1>to stay fit.

159
00:07:02.439 --> 00:07:05.959
<v Speaker 2>And that leads to the mindset. He describes never be afraid.

160
00:07:06.839 --> 00:07:09.120
<v Speaker 2>It sound like a motivational poster, but he means it.

161
00:07:09.560 --> 00:07:12.519
<v Speaker 2>When you're deep in assembly, code and memory addresses, it's

162
00:07:12.519 --> 00:07:15.399
<v Speaker 2>easy to get lost. He says, you have to fantasize

163
00:07:15.439 --> 00:07:18.839
<v Speaker 2>about the success, visualize getting that rootshell to push through.

164
00:07:18.959 --> 00:07:21.519
<v Speaker 1>I love that quote, and exploit is a complex statement

165
00:07:21.560 --> 00:07:22.040
<v Speaker 1>of truth.

166
00:07:22.199 --> 00:07:25.639
<v Speaker 2>What you're saying, is this is possible, and saying it

167
00:07:25.680 --> 00:07:27.160
<v Speaker 2>truthfully makes it beautiful.

168
00:07:27.399 --> 00:07:30.639
<v Speaker 1>That completely reframes it. The hacker isn't a vandal, they're

169
00:07:30.639 --> 00:07:34.439
<v Speaker 1>a realist. They're proving that the code as it exists

170
00:07:34.639 --> 00:07:36.879
<v Speaker 1>isn't what the developer imagined exactly.

171
00:07:37.240 --> 00:07:40.079
<v Speaker 2>It's the code as imagined versus the code as it

172
00:07:40.120 --> 00:07:44.199
<v Speaker 2>actually is. In silicon, the exploit proves the reality.

173
00:07:44.560 --> 00:07:47.160
<v Speaker 1>So let's get into that truth. We've overslowed the buffer,

174
00:07:47.160 --> 00:07:49.759
<v Speaker 1>we've hijacked the return address. Now we need to actually

175
00:07:49.839 --> 00:07:52.560
<v Speaker 1>do something. We need a payload and or shell code.

176
00:07:52.879 --> 00:07:54.560
<v Speaker 1>This was the part of the book that really just

177
00:07:54.600 --> 00:07:57.480
<v Speaker 1>blew my mind. Shell code is the actual set of

178
00:07:57.519 --> 00:07:58.759
<v Speaker 1>instructions you inject.

179
00:07:58.879 --> 00:08:01.759
<v Speaker 2>Yeah, the goal is usually to launch a shell a

180
00:08:01.800 --> 00:08:04.879
<v Speaker 2>command prompt so you can take over. But writing shell

181
00:08:04.920 --> 00:08:07.439
<v Speaker 2>code is like building a ship in a bottle while

182
00:08:07.480 --> 00:08:10.800
<v Speaker 2>wearing ofnmits. The constraints are just insane, And.

183
00:08:10.759 --> 00:08:13.079
<v Speaker 1>The biggest one is the addressing problem. Can you break

184
00:08:13.120 --> 00:08:13.480
<v Speaker 1>that down?

185
00:08:13.600 --> 00:08:16.199
<v Speaker 2>Sure? So, imagine you're dropped into a forest with a map,

186
00:08:16.399 --> 00:08:18.519
<v Speaker 2>but you have no idea where you are on that map.

187
00:08:18.759 --> 00:08:20.800
<v Speaker 2>The shell code is injected into memory, but it doesn't

188
00:08:20.800 --> 00:08:21.560
<v Speaker 2>know its own address.

189
00:08:21.600 --> 00:08:23.680
<v Speaker 1>It doesn't know where it lives right, and.

190
00:08:23.680 --> 00:08:26.279
<v Speaker 2>To run it needs to find its own data, like

191
00:08:26.319 --> 00:08:30.439
<v Speaker 2>the text string binch to start the command line. But

192
00:08:30.519 --> 00:08:32.440
<v Speaker 2>how can it point to its own feet if it

193
00:08:32.440 --> 00:08:33.600
<v Speaker 2>doesn't know where it's standing?

194
00:08:34.080 --> 00:08:35.440
<v Speaker 1>So how does it find itself?

195
00:08:35.840 --> 00:08:39.519
<v Speaker 2>There's this brilliant, almost beautiful trick mentioned in the text,

196
00:08:40.120 --> 00:08:41.399
<v Speaker 2>the jmpcl trick.

197
00:08:41.440 --> 00:08:42.480
<v Speaker 1>Okay, walk me through it.

198
00:08:42.519 --> 00:08:46.639
<v Speaker 2>The code starts, the very first instruction is jump. It

199
00:08:46.720 --> 00:08:49.039
<v Speaker 2>jumps all the way to the very end of its own.

200
00:08:48.879 --> 00:08:50.519
<v Speaker 1>Code, skips everything, goes to the end.

201
00:08:50.600 --> 00:08:52.720
<v Speaker 2>At the end is a calible instruction which says go

202
00:08:52.799 --> 00:08:53.600
<v Speaker 2>back to the beginning.

203
00:08:53.720 --> 00:08:55.840
<v Speaker 1>Wait, why jump to the end just to call back

204
00:08:55.840 --> 00:08:58.039
<v Speaker 1>to the start? That sounds pointless.

205
00:08:58.279 --> 00:09:01.200
<v Speaker 2>It's all about the side effects assembly language. When you

206
00:09:01.320 --> 00:09:04.879
<v Speaker 2>use the call instruction, the CPU automatically does something helpful.

207
00:09:04.879 --> 00:09:07.360
<v Speaker 2>It pushes the return address onto the stack.

208
00:09:07.639 --> 00:09:11.600
<v Speaker 1>Ah. So by calling itself, the code forces the CPU

209
00:09:11.639 --> 00:09:14.039
<v Speaker 1>to write down I was just here exactly.

210
00:09:14.120 --> 00:09:16.480
<v Speaker 2>The shell code then just pops that address off the

211
00:09:16.519 --> 00:09:20.080
<v Speaker 2>stack and boom. It now knows its own location in memory.

212
00:09:20.200 --> 00:09:24.080
<v Speaker 2>It located itself by using the CPU's own bookmarking system

213
00:09:24.120 --> 00:09:24.639
<v Speaker 2>against it.

214
00:09:24.840 --> 00:09:27.919
<v Speaker 1>That is unbelievably clever. It's like throwing a boomerang just

215
00:09:27.960 --> 00:09:29.320
<v Speaker 1>to see where it comes back from.

216
00:09:29.399 --> 00:09:32.960
<v Speaker 2>It's elegant. But that's not even the hardest part. You

217
00:09:33.000 --> 00:09:34.960
<v Speaker 2>also have the NLL byte problem.

218
00:09:35.120 --> 00:09:38.360
<v Speaker 1>The nl byte. This sounded like the absolute villain of

219
00:09:38.399 --> 00:09:38.879
<v Speaker 1>the story.

220
00:09:38.960 --> 00:09:42.559
<v Speaker 2>It's the nemesis. Remember we're injecting our code through a

221
00:09:42.600 --> 00:09:46.320
<v Speaker 2>function that handles text strings. In the C programming language,

222
00:09:46.360 --> 00:09:49.399
<v Speaker 2>a string ends with the NLL byte. The value zero.

223
00:09:49.600 --> 00:09:51.720
<v Speaker 1>It's the period at the end of the sentence tells

224
00:09:51.720 --> 00:09:53.000
<v Speaker 1>the program to stop reading.

225
00:09:53.120 --> 00:09:56.440
<v Speaker 2>Correct. So if your malicious shell code has a single

226
00:09:56.519 --> 00:10:00.240
<v Speaker 2>zero byte anywhere in it, the copy function just stopped ops.

227
00:10:00.240 --> 00:10:02.600
<v Speaker 2>It cuts your attack off before it's even fully loaded.

228
00:10:02.720 --> 00:10:04.559
<v Speaker 1>But zeros have to be everywhere in code. If I

229
00:10:04.559 --> 00:10:06.960
<v Speaker 1>want to set a register to zero, then instruction contains

230
00:10:07.120 --> 00:10:08.080
<v Speaker 1>zero exactly.

231
00:10:08.200 --> 00:10:09.960
<v Speaker 2>So you have to figure out how to command the

232
00:10:10.120 --> 00:10:13.919
<v Speaker 2>processor to use the value zero without ever actually writing

233
00:10:13.919 --> 00:10:16.440
<v Speaker 2>a zero in your code. It's like writing a novel

234
00:10:16.679 --> 00:10:17.919
<v Speaker 2>without using the letter E.

235
00:10:18.200 --> 00:10:19.679
<v Speaker 1>How is that even possible?

236
00:10:19.879 --> 00:10:22.960
<v Speaker 2>Use math, specifically the xor.

237
00:10:22.639 --> 00:10:24.600
<v Speaker 1>Operation xor exclusive or R.

238
00:10:24.720 --> 00:10:27.440
<v Speaker 2>Right, it's a basic logic gate. If you xr any

239
00:10:27.519 --> 00:10:31.720
<v Speaker 2>value with itself, the result is always zero. Everything cancels out.

240
00:10:31.840 --> 00:10:34.960
<v Speaker 1>So instead of telling the computer move zero into register A,

241
00:10:35.399 --> 00:10:39.360
<v Speaker 1>you tell it xor register A with register A and

242
00:10:39.399 --> 00:10:40.639
<v Speaker 1>the result is zero.

243
00:10:40.960 --> 00:10:43.759
<v Speaker 2>The result is zero, but the instruction itself, the actual

244
00:10:43.799 --> 00:10:47.720
<v Speaker 2>bytes you injected, contains no zeros. You've completely bypassed the filter.

245
00:10:47.879 --> 00:10:50.480
<v Speaker 1>That is the art form, that's the Judo move. It's

246
00:10:50.519 --> 00:10:53.639
<v Speaker 1>this incredible constraint based creativity.

247
00:10:53.799 --> 00:10:56.879
<v Speaker 2>It really is. You're navigating this minefield where one wrong

248
00:10:56.960 --> 00:10:59.919
<v Speaker 2>bite just crashes everything before you can get control.

249
00:11:00.159 --> 00:11:03.320
<v Speaker 1>So we've navigated the minefield, we have our shell code.

250
00:11:03.399 --> 00:11:06.879
<v Speaker 1>Where are we running this? The book distinguishes between remote

251
00:11:06.919 --> 00:11:08.759
<v Speaker 1>and local attack right.

252
00:11:08.840 --> 00:11:11.480
<v Speaker 2>Remote is the classic hacker movie, you're attacking a server

253
00:11:11.519 --> 00:11:14.200
<v Speaker 2>across the internet. Local is when you're already inside with

254
00:11:14.200 --> 00:11:15.919
<v Speaker 2>a low level account and you want to become the

255
00:11:15.960 --> 00:11:17.320
<v Speaker 2>administrator or route.

256
00:11:17.399 --> 00:11:20.559
<v Speaker 1>Let's do remote first, you launch the exploit. How do

257
00:11:20.600 --> 00:11:22.960
<v Speaker 1>you actually talk to the shell you just spawned?

258
00:11:23.279 --> 00:11:26.159
<v Speaker 2>The simple way is port binding. Your shell code tells

259
00:11:26.200 --> 00:11:29.559
<v Speaker 2>the victim machine to open a new door, say port one, two, three,

260
00:11:29.639 --> 00:11:32.480
<v Speaker 2>four five and listen. Then you just connect to that

261
00:11:32.519 --> 00:11:33.000
<v Speaker 2>new port.

262
00:11:33.320 --> 00:11:35.559
<v Speaker 1>But firewalls would hate that, oh they do.

263
00:11:36.000 --> 00:11:39.440
<v Speaker 2>A random new port opening up is a gigantic red

264
00:11:39.480 --> 00:11:44.200
<v Speaker 2>flag it gets blocked immediately. This sophisticated method is socket reus.

265
00:11:44.480 --> 00:11:45.320
<v Speaker 1>How does that work?

266
00:11:45.440 --> 00:11:49.159
<v Speaker 2>It's parasitic. The shell code looks for the connection that's

267
00:11:49.159 --> 00:11:52.320
<v Speaker 2>already open, the very one you use to send the exploit.

268
00:11:52.799 --> 00:11:54.440
<v Speaker 2>It finds that connections handle in.

269
00:11:54.440 --> 00:11:56.240
<v Speaker 1>Memory, and it just takes it over.

270
00:11:56.399 --> 00:11:59.919
<v Speaker 2>It duplicates it. It redirects the shell's input and output

271
00:12:00.399 --> 00:12:03.559
<v Speaker 2>to that existing connection. So from the firewalls perspective, there's

272
00:12:03.600 --> 00:12:06.919
<v Speaker 2>no new connection. You send the exploit, and suddenly your

273
00:12:06.960 --> 00:12:10.240
<v Speaker 2>existing terminal window is the command prompt on their server.

274
00:12:10.440 --> 00:12:12.320
<v Speaker 1>That is terrifyingly stealthy.

275
00:12:12.519 --> 00:12:16.279
<v Speaker 2>It is now for local attacks, the goal is usually

276
00:12:16.399 --> 00:12:19.080
<v Speaker 2>escaping some kind of jail. The book talks about the

277
00:12:19.159 --> 00:12:19.799
<v Speaker 2>crup jail.

278
00:12:19.960 --> 00:12:23.000
<v Speaker 1>A creup jail sounds like a timeout corner for software.

279
00:12:23.000 --> 00:12:25.159
<v Speaker 2>It's a pretty good analogy. It's a security feature that

280
00:12:25.240 --> 00:12:28.000
<v Speaker 2>locks a program into a specific directory. As far as

281
00:12:28.039 --> 00:12:31.519
<v Speaker 2>that program knows that folders the entire universe. It can't

282
00:12:31.519 --> 00:12:33.120
<v Speaker 2>see the real system files outside.

283
00:12:33.159 --> 00:12:35.240
<v Speaker 1>So if you hack the program, you're still stuck in jail.

284
00:12:35.279 --> 00:12:36.120
<v Speaker 1>How do you break out?

285
00:12:36.440 --> 00:12:40.120
<v Speaker 2>The technique in the book is shockingly simple. If you

286
00:12:40.159 --> 00:12:43.080
<v Speaker 2>have root powers inside the jail, you create a new folder,

287
00:12:43.720 --> 00:12:46.039
<v Speaker 2>and then you use the fruit command again to move

288
00:12:46.080 --> 00:12:47.039
<v Speaker 2>into that new folder.

289
00:12:47.240 --> 00:12:49.039
<v Speaker 1>Jail inside of jail, Yes.

290
00:12:49.039 --> 00:12:52.320
<v Speaker 2>But because of a quirk in older systems, doing that

291
00:12:52.399 --> 00:12:55.919
<v Speaker 2>nested crude breaks the link to the original jail. And

292
00:12:55.960 --> 00:12:58.440
<v Speaker 2>then you just spam dot slash.

293
00:12:58.440 --> 00:13:00.480
<v Speaker 1>Go up one folder commandment over and over.

294
00:13:00.759 --> 00:13:03.480
<v Speaker 2>You just climb the directory tree until you pop out

295
00:13:03.519 --> 00:13:06.559
<v Speaker 2>at the top of the real file system. You've escaped.

296
00:13:06.759 --> 00:13:09.120
<v Speaker 1>That feels like a video game cheat code, just running

297
00:13:09.159 --> 00:13:10.879
<v Speaker 1>against a wall until you clip through the map.

298
00:13:11.320 --> 00:13:13.320
<v Speaker 2>It basically is. And it just goes to show that

299
00:13:13.360 --> 00:13:16.960
<v Speaker 2>even security features are just code, and if you understand

300
00:13:16.960 --> 00:13:18.960
<v Speaker 2>the logic better than the person who wrote it, you

301
00:13:18.960 --> 00:13:19.720
<v Speaker 2>can bypass it.

302
00:13:20.080 --> 00:13:23.759
<v Speaker 1>Hearing all of this, the complexity, the creativity, the sheer

303
00:13:23.919 --> 00:13:27.399
<v Speaker 1>fragility of memory, it brings us back to the big question,

304
00:13:27.679 --> 00:13:29.919
<v Speaker 1>why why does the still work? We've known about this

305
00:13:30.000 --> 00:13:30.519
<v Speaker 1>for decades.

306
00:13:30.600 --> 00:13:33.320
<v Speaker 2>Yeah, the micro data in the book says buffer overflows

307
00:13:33.360 --> 00:13:36.639
<v Speaker 2>account for a huge percentage of vulnerabilities. That number goes

308
00:13:36.720 --> 00:13:38.360
<v Speaker 2>up and down, but the principle holds.

309
00:13:38.399 --> 00:13:40.120
<v Speaker 1>So what's the root cause it's.

310
00:13:39.960 --> 00:13:43.039
<v Speaker 2>Almost always the same thing. Poor input validation.

311
00:13:43.320 --> 00:13:44.639
<v Speaker 1>We trust the user too much.

312
00:13:45.120 --> 00:13:47.799
<v Speaker 2>We assume the user will send a username. That's eight

313
00:13:47.879 --> 00:13:51.639
<v Speaker 2>characters long. We don't plan for them sending ten thousand

314
00:13:51.679 --> 00:13:55.000
<v Speaker 2>characters of malicious assembly. We code for the happy path,

315
00:13:55.559 --> 00:13:56.840
<v Speaker 2>not the psychopathic one.

316
00:13:56.919 --> 00:13:59.840
<v Speaker 1>But surely big companies like Microsoft and Oracle are checking

317
00:13:59.919 --> 00:14:00.720
<v Speaker 1>for this stuff.

318
00:14:00.919 --> 00:14:03.799
<v Speaker 2>They are. But the source makes a great point about

319
00:14:03.799 --> 00:14:07.480
<v Speaker 2>the myth of bug free software. It calls out Oracle,

320
00:14:07.759 --> 00:14:10.879
<v Speaker 2>who once famously claimed their software was unbreakable.

321
00:14:11.080 --> 00:14:13.559
<v Speaker 1>That's just asking for trouble. It's like naming your ship

322
00:14:13.600 --> 00:14:14.320
<v Speaker 1>the Titanic.

323
00:14:14.559 --> 00:14:18.080
<v Speaker 2>It is and they were proven wrong immediately. The book

324
00:14:18.159 --> 00:14:22.039
<v Speaker 2>argues something that sounds a bit controversial, complete security should

325
00:14:22.080 --> 00:14:23.320
<v Speaker 2>not be a sought after goal.

326
00:14:23.399 --> 00:14:26.159
<v Speaker 1>Wait, really, we shouldn't try to be completely secure.

327
00:14:26.360 --> 00:14:29.799
<v Speaker 2>His point is that it's unrealistic. It's an impossible goal.

328
00:14:30.600 --> 00:14:33.840
<v Speaker 2>Software is just too complex. The goal should be risk management.

329
00:14:34.240 --> 00:14:39.600
<v Speaker 2>You aim for realistic milestones like no user provided input vulnerabilities.

330
00:14:40.039 --> 00:14:42.840
<v Speaker 2>You manage the flaws. You don't pretend you can eliminate

331
00:14:42.840 --> 00:14:43.720
<v Speaker 2>them entirely.

332
00:14:43.480 --> 00:14:47.360
<v Speaker 1>Because they're written by humans, and humans make mistakes, and.

333
00:14:47.399 --> 00:14:51.200
<v Speaker 2>Buffer overflows are the digital version of that. It's what

334
00:14:51.240 --> 00:14:53.200
<v Speaker 2>happens when our creations get away from us.

335
00:14:53.320 --> 00:14:56.639
<v Speaker 1>So after all this, what's the takeaway? We've gone from

336
00:14:56.679 --> 00:15:00.080
<v Speaker 1>this scary boogeyman to the beautiful truth of the code.

337
00:15:00.559 --> 00:15:02.279
<v Speaker 2>I think it just changes how you look at the

338
00:15:02.320 --> 00:15:07.080
<v Speaker 2>digital world. It's not this solid, reliable thing. It's this fragile,

339
00:15:07.240 --> 00:15:11.279
<v Speaker 2>intricate dance of memory, and we can run it.

340
00:15:14.080 --> 00:15:16.639
<v Speaker 1>That keeps changing shape. And I want to leave our

341
00:15:16.639 --> 00:15:19.799
<v Speaker 1>listeners with that one final thought from Itel's forward that

342
00:15:19.879 --> 00:15:21.240
<v Speaker 1>honestly just gave me chills.

343
00:15:21.320 --> 00:15:22.399
<v Speaker 2>I think I know which one you mean.

344
00:15:22.679 --> 00:15:26.120
<v Speaker 1>He writes that somewhere right now, there's a fifteen year

345
00:15:26.159 --> 00:15:28.720
<v Speaker 1>old in Sweden working twenty hours a day to be

346
00:15:28.720 --> 00:15:29.759
<v Speaker 1>better than you at this.

347
00:15:30.080 --> 00:15:31.600
<v Speaker 2>It's a very sobering thought.

348
00:15:31.679 --> 00:15:34.000
<v Speaker 1>He says. It's not just about learning a skill, it's

349
00:15:34.039 --> 00:15:37.159
<v Speaker 1>about fiddling until the code is clean, until it's perfect.

350
00:15:37.679 --> 00:15:41.159
<v Speaker 1>While security professionals are in meetings, that kid is staring

351
00:15:41.200 --> 00:15:43.440
<v Speaker 1>at a heck stump trying to find one extra bite

352
00:15:43.480 --> 00:15:44.840
<v Speaker 1>of space for their shell code.

353
00:15:44.919 --> 00:15:47.840
<v Speaker 2>And that applies to the defenders too. Security isn't a

354
00:15:47.879 --> 00:15:50.960
<v Speaker 2>product you buy, it's a process. It's the process of

355
00:15:51.039 --> 00:15:54.960
<v Speaker 2>understanding the deepest flaws in what we build. Hopefully before

356
00:15:54.960 --> 00:15:56.000
<v Speaker 2>that fifteen year old does.

357
00:15:56.279 --> 00:15:58.559
<v Speaker 1>On that note, maybe it's time for all of us

358
00:15:58.559 --> 00:16:01.559
<v Speaker 1>to go update our systems and maybe stop trusting user

359
00:16:01.600 --> 00:16:04.279
<v Speaker 1>infally quite so much. Thanks for diving deep with us,

360
00:16:04.440 --> 00:16:05.679
<v Speaker 1>Take curious, See you next time.