1
00:00:00,000 --> 00:00:08,469
foreign

2
00:00:00,500 --> 00:00:08,469
[Music]

3
00:00:11,120 --> 00:00:15,960
Russell is a Linux kernel hacker

4
00:00:13,620 --> 00:00:19,619
primarily focused on memory protections

5
00:00:15,960 --> 00:00:21,600
and microarchitectural security he leads

6
00:00:19,619 --> 00:00:24,300
the Linux hardening team for IBM power

7
00:00:21,600 --> 00:00:27,000
and today's Russell is going to talk on

8
00:00:24,300 --> 00:00:30,320
the history of Linux Kernel Security

9
00:00:27,000 --> 00:00:30,320
please make him feel welcome

10
00:00:32,960 --> 00:00:37,739
great thanks a lot hello everyone good

11
00:00:36,840 --> 00:00:39,780
morning

12
00:00:37,739 --> 00:00:41,820
um good job managing to find the room

13
00:00:39,780 --> 00:00:43,440
and bad job choosing to come here

14
00:00:41,820 --> 00:00:44,940
instead of Paul McKinney's talker you do

15
00:00:43,440 --> 00:00:46,579
know that Paul mckenney's talking right

16
00:00:44,940 --> 00:00:49,800
but anyway

17
00:00:46,579 --> 00:00:52,500
so yes uh today I'm going to be talking

18
00:00:49,800 --> 00:00:53,879
about a bit of the history of of Linux

19
00:00:52,500 --> 00:00:55,860
Kernel Security

20
00:00:53,879 --> 00:00:57,480
there's a lot of history and there's a

21
00:00:55,860 --> 00:00:59,460
lot of things that mean security so we

22
00:00:57,480 --> 00:01:03,059
may be not able to cover it all in 40

23
00:00:59,460 --> 00:01:04,799
minutes or whatever but uh I will I will

24
00:01:03,059 --> 00:01:07,920
do my best so anyway

25
00:01:04,799 --> 00:01:10,439
uh let's kick into things

26
00:01:07,920 --> 00:01:13,560
yeah there we go great uh just quickly

27
00:01:10,439 --> 00:01:14,280
rattle off um who I am as mentioned I'm

28
00:01:13,560 --> 00:01:16,979
a

29
00:01:14,280 --> 00:01:18,540
full-time kernel developer I run the

30
00:01:16,979 --> 00:01:19,619
links on power kernel hardening team at

31
00:01:18,540 --> 00:01:21,479
IBM

32
00:01:19,619 --> 00:01:22,500
I'm based in Canberra at the Oz Labs

33
00:01:21,479 --> 00:01:25,140
team

34
00:01:22,500 --> 00:01:26,939
and yeah I've been awake since 4am so

35
00:01:25,140 --> 00:01:28,740
this may be slightly more unhinged than

36
00:01:26,939 --> 00:01:31,380
otherwise planned but we'll just kind of

37
00:01:28,740 --> 00:01:33,840
roll with it keep that in mind and just

38
00:01:31,380 --> 00:01:35,939
to set some ground rules for the word

39
00:01:33,840 --> 00:01:38,579
history and just how Abridged I make it

40
00:01:35,939 --> 00:01:40,380
uh first of all I'm going to be talking

41
00:01:38,579 --> 00:01:43,079
about the technology itself I'm going to

42
00:01:40,380 --> 00:01:44,820
be focused on what went into the Linux

43
00:01:43,079 --> 00:01:47,040
kernel what it does why it's important

44
00:01:44,820 --> 00:01:50,399
as opposed to

45
00:01:47,040 --> 00:01:52,140
uh you know other stuff I'm going to be

46
00:01:50,399 --> 00:01:53,579
focused primarily on Upstream now a lot

47
00:01:52,140 --> 00:01:55,500
of Kernel Security features didn't

48
00:01:53,579 --> 00:01:57,299
originate in the Upstream sorcery they

49
00:01:55,500 --> 00:01:58,920
didn't originate in in Mainline and

50
00:01:57,299 --> 00:02:01,320
Linus 12 volts tree

51
00:01:58,920 --> 00:02:03,840
coming from other projects like grsec

52
00:02:01,320 --> 00:02:05,100
but as I work on upstream and focus on

53
00:02:03,840 --> 00:02:06,479
Upstream that's what I'm going to be

54
00:02:05,100 --> 00:02:08,220
talking about today

55
00:02:06,479 --> 00:02:10,020
and I'm specifically going to be talking

56
00:02:08,220 --> 00:02:11,879
about the security of the kernel itself

57
00:02:10,020 --> 00:02:15,080
now the kernel exposes a lot of security

58
00:02:11,879 --> 00:02:16,980
features to user space

59
00:02:15,080 --> 00:02:17,940
we don't care about user space here

60
00:02:16,980 --> 00:02:19,800
we're talking about the kernel we're

61
00:02:17,940 --> 00:02:21,480
talking about Linux itself the core body

62
00:02:19,800 --> 00:02:23,700
that is Linux so we're going to be

63
00:02:21,480 --> 00:02:25,739
talking about linux's ability to protect

64
00:02:23,700 --> 00:02:27,959
itself the security of the kernel itself

65
00:02:25,739 --> 00:02:29,520
which is often called kernel hardening

66
00:02:27,959 --> 00:02:31,260
or kernel self-protection the ability

67
00:02:29,520 --> 00:02:33,540
for the kernel to protect itself against

68
00:02:31,260 --> 00:02:34,920
attacks

69
00:02:33,540 --> 00:02:38,160
so we're going to be rolling through

70
00:02:34,920 --> 00:02:40,020
some some areas here uh into what I've

71
00:02:38,160 --> 00:02:43,319
I've delightfully called the before

72
00:02:40,020 --> 00:02:45,239
times the Dark Ages uh which I was

73
00:02:43,319 --> 00:02:46,800
probably in primary school for uh the

74
00:02:45,239 --> 00:02:48,180
formative years Linux is growing up

75
00:02:46,800 --> 00:02:49,739
people are starting to think that

76
00:02:48,180 --> 00:02:50,760
security is a thing

77
00:02:49,739 --> 00:02:52,560
um into the area where we're really

78
00:02:50,760 --> 00:02:53,640
ramping up into some real stuff we're

79
00:02:52,560 --> 00:02:55,860
actually thinking about and then the

80
00:02:53,640 --> 00:02:58,680
modern era where

81
00:02:55,860 --> 00:03:01,800
most people mostly care about security

82
00:02:58,680 --> 00:03:03,360
which is a good thing so but it's a long

83
00:03:01,800 --> 00:03:06,300
journey to get there so let's start with

84
00:03:03,360 --> 00:03:07,920
the before times the Dark Ages

85
00:03:06,300 --> 00:03:09,900
uh

86
00:03:07,920 --> 00:03:11,580
security has become a much bigger Focus

87
00:03:09,900 --> 00:03:15,000
I think across the entire software

88
00:03:11,580 --> 00:03:16,560
engineering ecosystem as the years have

89
00:03:15,000 --> 00:03:18,360
rolled on this is not necessarily always

90
00:03:16,560 --> 00:03:19,739
being the case

91
00:03:18,360 --> 00:03:22,019
um at least if you're not a security

92
00:03:19,739 --> 00:03:23,940
researcher so back in the day we're

93
00:03:22,019 --> 00:03:27,780
talking you know pre you know early

94
00:03:23,940 --> 00:03:29,580
2000s late 90s we did have you know cves

95
00:03:27,780 --> 00:03:32,640
we did have vulnerabilities get reported

96
00:03:29,580 --> 00:03:35,340
we did have bugs and they did get fixed

97
00:03:32,640 --> 00:03:37,200
um but not really at the rate and with

98
00:03:35,340 --> 00:03:41,900
the kind of passion and vigor we fix

99
00:03:37,200 --> 00:03:44,819
bugs today we're talking you know uh

100
00:03:41,900 --> 00:03:48,120
privileged escalations sitting unpatched

101
00:03:44,819 --> 00:03:50,220
for years Etc so there was the same kind

102
00:03:48,120 --> 00:03:52,799
of process we have now just in a very

103
00:03:50,220 --> 00:03:54,540
very kind of basic form

104
00:03:52,799 --> 00:03:56,700
security not really a thing that people

105
00:03:54,540 --> 00:03:58,920
are super fixated on we did have things

106
00:03:56,700 --> 00:04:00,900
like the security at kernel.org mailing

107
00:03:58,920 --> 00:04:03,000
list where you can privately report bugs

108
00:04:00,900 --> 00:04:05,280
in the kernel but we didn't have things

109
00:04:03,000 --> 00:04:06,900
like you know Common People on mailing

110
00:04:05,280 --> 00:04:08,760
lists knowing to look for things that

111
00:04:06,900 --> 00:04:11,099
could become vulnerabilities

112
00:04:08,760 --> 00:04:13,019
and we didn't have the tooling nowadays

113
00:04:11,099 --> 00:04:14,879
we have a lot more tooling when it comes

114
00:04:13,019 --> 00:04:16,859
to things that can catch bugs before

115
00:04:14,879 --> 00:04:19,680
they become vulnerabilities

116
00:04:16,859 --> 00:04:21,600
things that can you know scan for

117
00:04:19,680 --> 00:04:22,620
exploits and fix them and whatnot we

118
00:04:21,600 --> 00:04:24,660
didn't haven't we didn't have

119
00:04:22,620 --> 00:04:26,040
particularly smart compilers we didn't

120
00:04:24,660 --> 00:04:27,840
have particularly smart tooling

121
00:04:26,040 --> 00:04:30,360
instrumentation Etc

122
00:04:27,840 --> 00:04:32,639
now there's some great quotes here which

123
00:04:30,360 --> 00:04:34,979
I wasn't around for this era and seeing

124
00:04:32,639 --> 00:04:36,720
these quotes makes me glad of that the

125
00:04:34,979 --> 00:04:39,600
first one I found this was around like

126
00:04:36,720 --> 00:04:40,979
2007-ish it's this quote that you know

127
00:04:39,600 --> 00:04:42,540
problem with Linux is just too many

128
00:04:40,979 --> 00:04:44,820
people hacking the code

129
00:04:42,540 --> 00:04:46,560
has this but it's reached this size this

130
00:04:44,820 --> 00:04:49,040
complexity to whether I hack quickly

131
00:04:46,560 --> 00:04:51,240
some code approach doesn't work anymore

132
00:04:49,040 --> 00:04:52,560
in the early days of Linux code

133
00:04:51,240 --> 00:04:54,180
standards are not as high as they are

134
00:04:52,560 --> 00:04:55,560
now I know from some of the younger

135
00:04:54,180 --> 00:04:57,360
people in my team

136
00:04:55,560 --> 00:04:58,740
seeing some stuff in the kernel that's

137
00:04:57,360 --> 00:04:59,699
in that's been in the source for 20

138
00:04:58,740 --> 00:05:01,919
years

139
00:04:59,699 --> 00:05:03,300
wouldn't really fly if it got reviewed

140
00:05:01,919 --> 00:05:04,740
on the mailing list today so the code

141
00:05:03,300 --> 00:05:05,940
quality the standards of the kernel has

142
00:05:04,740 --> 00:05:09,600
gone up

143
00:05:05,940 --> 00:05:11,280
and uh that is reflected in the kind of

144
00:05:09,600 --> 00:05:13,259
wild west era that the colonel used to

145
00:05:11,280 --> 00:05:15,300
be in there's a quote here from from

146
00:05:13,259 --> 00:05:17,040
spender about how this is this

147
00:05:15,300 --> 00:05:19,919
particular time where you know okay we

148
00:05:17,040 --> 00:05:21,960
got 12 new cves so 12 new

149
00:05:19,919 --> 00:05:25,020
vulnerabilities some actually more than

150
00:05:21,960 --> 00:05:28,380
12 found by one guy with grep and a few

151
00:05:25,020 --> 00:05:30,240
days in his spare time now that is a lot

152
00:05:28,380 --> 00:05:32,039
of low-hanging fruit and not to say that

153
00:05:30,240 --> 00:05:33,479
there's no the kernels done with bugs

154
00:05:32,039 --> 00:05:36,479
guys there's still bugs in the kernel

155
00:05:33,479 --> 00:05:38,520
but probably not this level of severity

156
00:05:36,479 --> 00:05:41,880
that you can find this easily I sure

157
00:05:38,520 --> 00:05:43,800
hope we've we've passed this point

158
00:05:41,880 --> 00:05:46,380
um and part of the reason for this is

159
00:05:43,800 --> 00:05:48,240
just that you know if you're in 2005 or

160
00:05:46,380 --> 00:05:51,000
whatever and you're thinking about Linux

161
00:05:48,240 --> 00:05:52,259
uh security pro is on the Forefront of

162
00:05:51,000 --> 00:05:54,960
your mind because the thing next door is

163
00:05:52,259 --> 00:05:56,340
Windows and it's windows in 2005. how

164
00:05:54,960 --> 00:05:58,860
many of you had to deal with a family

165
00:05:56,340 --> 00:06:01,080
member getting spyware from and storing

166
00:05:58,860 --> 00:06:03,900
like a dolphin animated wallpaper or

167
00:06:01,080 --> 00:06:05,340
something you know like

168
00:06:03,900 --> 00:06:07,080
heard from that to your women's computer

169
00:06:05,340 --> 00:06:08,699
that may even have like a working

170
00:06:07,080 --> 00:06:11,639
Network or something at that point

171
00:06:08,699 --> 00:06:13,440
pretty pretty secure by comparison so

172
00:06:11,639 --> 00:06:14,220
not necessarily something that's you

173
00:06:13,440 --> 00:06:16,199
know

174
00:06:14,220 --> 00:06:18,360
a huge concern people just kind of have

175
00:06:16,199 --> 00:06:19,979
this base assumption that Linux is is

176
00:06:18,360 --> 00:06:21,419
pretty secure

177
00:06:19,979 --> 00:06:22,919
uh

178
00:06:21,419 --> 00:06:24,539
but the problem with that is that Linux

179
00:06:22,919 --> 00:06:27,300
is a big Target

180
00:06:24,539 --> 00:06:29,460
um Linux runs on billions of devices it

181
00:06:27,300 --> 00:06:31,199
runs on most of the server world

182
00:06:29,460 --> 00:06:34,319
tons of phones in people's pockets right

183
00:06:31,199 --> 00:06:35,940
now and for the Wilderness that like not

184
00:06:34,319 --> 00:06:37,500
having working things also on the

185
00:06:35,940 --> 00:06:39,660
desktop

186
00:06:37,500 --> 00:06:41,639
so the kernel has a really big scope it

187
00:06:39,660 --> 00:06:43,139
does a ton of things however many things

188
00:06:41,639 --> 00:06:45,539
you think the kernel does it does more

189
00:06:43,139 --> 00:06:47,940
than that so the kernel has a gigantic

190
00:06:45,539 --> 00:06:50,280
scope it has a really high amount of

191
00:06:47,940 --> 00:06:52,680
code that does a ton of different things

192
00:06:50,280 --> 00:06:54,060
the kernel code itself changes really

193
00:06:52,680 --> 00:06:55,680
rapidly thousands of different

194
00:06:54,060 --> 00:06:58,259
contributors every release releases

195
00:06:55,680 --> 00:06:59,639
every few months really high velocity of

196
00:06:58,259 --> 00:07:02,639
course most of us don't actually use

197
00:06:59,639 --> 00:07:04,860
main like Upstream Linux most of us use

198
00:07:02,639 --> 00:07:06,300
distributions and every different

199
00:07:04,860 --> 00:07:08,280
distribution has their own different

200
00:07:06,300 --> 00:07:10,919
version of the source and different

201
00:07:08,280 --> 00:07:12,960
versions of those versions and so on so

202
00:07:10,919 --> 00:07:15,360
the kernel changes really rapidly it has

203
00:07:12,960 --> 00:07:16,740
a really wide range in ways it's it's

204
00:07:15,360 --> 00:07:18,060
distributed

205
00:07:16,740 --> 00:07:19,340
it also runs on lots of different

206
00:07:18,060 --> 00:07:22,560
Hardware

207
00:07:19,340 --> 00:07:25,979
it utilizes lots of different add-on

208
00:07:22,560 --> 00:07:28,380
cards and whatnot it runs on a

209
00:07:25,979 --> 00:07:31,560
hypervisor as a hypervisor both at the

210
00:07:28,380 --> 00:07:34,800
same time so scope big is the point and

211
00:07:31,560 --> 00:07:36,960
because scope big bugs inevitable there

212
00:07:34,800 --> 00:07:40,560
will always be bugs in the Linux kernel

213
00:07:36,960 --> 00:07:42,419
because of the sheer gargantuaness of

214
00:07:40,560 --> 00:07:44,400
the lyrics kernel

215
00:07:42,419 --> 00:07:45,840
there's no way that that we're going to

216
00:07:44,400 --> 00:07:48,120
get around this there's just simply too

217
00:07:45,840 --> 00:07:50,880
much code too much code written in a

218
00:07:48,120 --> 00:07:52,740
memory unsafe language uh so there are

219
00:07:50,880 --> 00:07:54,720
going to be bugs

220
00:07:52,740 --> 00:07:56,759
the point being that if bugs are

221
00:07:54,720 --> 00:07:58,259
inevitable then we need to do something

222
00:07:56,759 --> 00:08:00,000
about it we can't just have the security

223
00:07:58,259 --> 00:08:02,099
model that the kernel doesn't have bugs

224
00:08:00,000 --> 00:08:04,319
we need to give the kernel the ability

225
00:08:02,099 --> 00:08:06,180
to protect itself so when there are bugs

226
00:08:04,319 --> 00:08:07,740
in the code it doesn't get compromised

227
00:08:06,180 --> 00:08:09,660
if you take over the Linux kernel you

228
00:08:07,740 --> 00:08:10,979
take over the whole system if you're

229
00:08:09,660 --> 00:08:13,080
infiltrating a network and you

230
00:08:10,979 --> 00:08:14,460
compromise the kernel in one box then

231
00:08:13,080 --> 00:08:15,840
you can make things look like business

232
00:08:14,460 --> 00:08:17,220
as usual

233
00:08:15,840 --> 00:08:19,319
there's a whole bunch of stuff you get

234
00:08:17,220 --> 00:08:21,300
from being able to own links kernel and

235
00:08:19,319 --> 00:08:23,220
in most data centers the Winx kernels on

236
00:08:21,300 --> 00:08:25,199
pretty much everything so if you can

237
00:08:23,220 --> 00:08:26,699
beat the Linux kernel you win at

238
00:08:25,199 --> 00:08:29,879
hackening and we don't want people to

239
00:08:26,699 --> 00:08:33,020
win at hackening so thus Colonel needs

240
00:08:29,879 --> 00:08:33,020
to start securing up

241
00:08:34,860 --> 00:08:39,300
now time begins in 2007.

242
00:08:37,800 --> 00:08:42,779
uh

243
00:08:39,300 --> 00:08:45,360
it is around the time Linux 2.6.15

244
00:08:42,779 --> 00:08:46,860
people younger in the audience may not

245
00:08:45,360 --> 00:08:48,600
remember when Linux had dumb version

246
00:08:46,860 --> 00:08:50,760
numbers but this goes on for a while

247
00:08:48,600 --> 00:08:53,519
this is a continuing trend

248
00:08:50,760 --> 00:08:55,860
uh I've just started grade nine

249
00:08:53,519 --> 00:08:56,820
for a bit of context for how long ago

250
00:08:55,860 --> 00:08:58,980
this was

251
00:08:56,820 --> 00:09:01,260
it's 2007 everyone's wearing this shirt

252
00:08:58,980 --> 00:09:04,279
I don't know if any of you remember this

253
00:09:01,260 --> 00:09:06,779
this was quite the craze at the time

254
00:09:04,279 --> 00:09:08,459
and aside from that other stuff's

255
00:09:06,779 --> 00:09:10,019
happening uh we're about to you know the

256
00:09:08,459 --> 00:09:11,880
colonel Community is about to have a

257
00:09:10,019 --> 00:09:13,200
really hard lesson about what read only

258
00:09:11,880 --> 00:09:15,720
means

259
00:09:13,200 --> 00:09:19,019
now most people would assume that read

260
00:09:15,720 --> 00:09:21,720
only means that you can only read uh but

261
00:09:19,019 --> 00:09:23,940
it may not actually be true so let's

262
00:09:21,720 --> 00:09:25,260
think about what read only means

263
00:09:23,940 --> 00:09:27,720
so let's just talk about memory

264
00:09:25,260 --> 00:09:29,160
permissions this is the Holy Trinity the

265
00:09:27,720 --> 00:09:30,959
three things you've got a bit of memory

266
00:09:29,160 --> 00:09:34,980
what do you like to do with it well we

267
00:09:30,959 --> 00:09:36,779
have read write and execute rwx so can

268
00:09:34,980 --> 00:09:39,480
we access it can we modify it and can we

269
00:09:36,779 --> 00:09:41,160
run it if we jump the cpu's execution to

270
00:09:39,480 --> 00:09:43,260
this address will it start running

271
00:09:41,160 --> 00:09:46,860
execution running instructions from

272
00:09:43,260 --> 00:09:49,800
there so RW and X now

273
00:09:46,860 --> 00:09:51,959
people may assume that if we have

274
00:09:49,800 --> 00:09:55,560
something that is called read only then

275
00:09:51,959 --> 00:09:59,279
we only have the r here and that would

276
00:09:55,560 --> 00:10:01,920
be very false in 2007 so

277
00:09:59,279 --> 00:10:03,660
read only may not mean read only now

278
00:10:01,920 --> 00:10:06,120
here's just a quick look at the the file

279
00:10:03,660 --> 00:10:10,500
that is the Linux kernel itself this is

280
00:10:06,120 --> 00:10:11,640
a VM Linux it's a elf executable you

281
00:10:10,500 --> 00:10:13,560
don't need to worry too much about this

282
00:10:11,640 --> 00:10:16,080
stuff the first thing is that we've got

283
00:10:13,560 --> 00:10:18,480
we've got these sections we've got you

284
00:10:16,080 --> 00:10:19,920
know properties of those sections and

285
00:10:18,480 --> 00:10:22,320
here we've look at number one there

286
00:10:19,920 --> 00:10:23,700
we've got text now text means code I

287
00:10:22,320 --> 00:10:25,920
don't know why it doesn't just say code

288
00:10:23,700 --> 00:10:28,860
but it's always been text and so text

289
00:10:25,920 --> 00:10:31,140
has some properties like read only and

290
00:10:28,860 --> 00:10:33,420
code because it's code and it should be

291
00:10:31,140 --> 00:10:36,180
read only that's cool then we've got

292
00:10:33,420 --> 00:10:39,360
this next one called Ro data now Ro

293
00:10:36,180 --> 00:10:41,399
stands for read only and you'll notice

294
00:10:39,360 --> 00:10:43,200
there that it doesn't say read only like

295
00:10:41,399 --> 00:10:44,519
the others do so that's that's your

296
00:10:43,200 --> 00:10:46,380
first problem but the second problem is

297
00:10:44,519 --> 00:10:48,000
that this has just did the file itself

298
00:10:46,380 --> 00:10:49,620
once you load this into memory there's

299
00:10:48,000 --> 00:10:51,899
no inherent property that means a

300
00:10:49,620 --> 00:10:54,420
read-only data is read only it's just

301
00:10:51,899 --> 00:10:55,260
supposed to be so obviously it is

302
00:10:54,420 --> 00:10:57,420
um

303
00:10:55,260 --> 00:10:59,220
and so this is potentially a problem if

304
00:10:57,420 --> 00:11:01,260
you've got parts of your memory that you

305
00:10:59,220 --> 00:11:03,240
assume are read only and someone can

306
00:11:01,260 --> 00:11:05,300
change them then perhaps they can change

307
00:11:03,240 --> 00:11:07,560
them in malicious ways

308
00:11:05,300 --> 00:11:09,480
and so people hadn't quite had this this

309
00:11:07,560 --> 00:11:13,740
realization yet for security instead we

310
00:11:09,480 --> 00:11:16,380
got uh debug Ro data so someone comes

311
00:11:13,740 --> 00:11:19,320
along uh iyan finder then probably

312
00:11:16,380 --> 00:11:20,700
mispronounce that uh and introduces this

313
00:11:19,320 --> 00:11:23,399
option when you build the Linux kernel

314
00:11:20,700 --> 00:11:25,500
called config debug Ro data

315
00:11:23,399 --> 00:11:27,420
and the blurb is we want to Mark the

316
00:11:25,500 --> 00:11:29,160
kernel read-only data as write protected

317
00:11:27,420 --> 00:11:32,160
in the page tables in order to catch

318
00:11:29,160 --> 00:11:33,660
accidental and incorrect rights to such

319
00:11:32,160 --> 00:11:35,760
const data

320
00:11:33,660 --> 00:11:37,140
and this is completely fascinating to me

321
00:11:35,760 --> 00:11:40,440
because the idea of making something

322
00:11:37,140 --> 00:11:43,140
read-only be read only is a debug

323
00:11:40,440 --> 00:11:44,820
feature it's not a security feature it

324
00:11:43,140 --> 00:11:47,160
helps catch your bugs when you write to

325
00:11:44,820 --> 00:11:49,680
the wrong place it's really useful so

326
00:11:47,160 --> 00:11:51,300
it's fascinating to me that this is a

327
00:11:49,680 --> 00:11:53,940
debug thing and not a security thing the

328
00:11:51,300 --> 00:11:55,740
way this actually works is that when the

329
00:11:53,940 --> 00:11:57,180
kernel boots it has to do a lot of stuff

330
00:11:55,740 --> 00:11:58,620
based on what it's actually running on

331
00:11:57,180 --> 00:12:01,079
the Kernel doesn't know much about where

332
00:11:58,620 --> 00:12:02,519
it lives when it first boots So based on

333
00:12:01,079 --> 00:12:05,100
the devices that's running on the CPU

334
00:12:02,519 --> 00:12:06,839
it's running on it will change itself so

335
00:12:05,100 --> 00:12:08,760
if you have something marked const if

336
00:12:06,839 --> 00:12:10,740
you have something like that it's not

337
00:12:08,760 --> 00:12:13,200
actually constant until this gets

338
00:12:10,740 --> 00:12:14,760
enforced and this gets enforced in and

339
00:12:13,200 --> 00:12:16,019
kernel in it imagine we've done a bunch

340
00:12:14,760 --> 00:12:17,100
of the knitting you know lots of a

341
00:12:16,019 --> 00:12:19,140
knitting

342
00:12:17,100 --> 00:12:20,519
um then we freeze some stuff and then

343
00:12:19,140 --> 00:12:23,459
before we declare the system is running

344
00:12:20,519 --> 00:12:26,399
we run this magic function Mark Ro data

345
00:12:23,459 --> 00:12:28,260
Ro because it wasn't before so

346
00:12:26,399 --> 00:12:30,240
everything's modifiable until we

347
00:12:28,260 --> 00:12:32,160
actually start running and then now that

348
00:12:30,240 --> 00:12:35,160
we've got this in the kernel the

349
00:12:32,160 --> 00:12:36,839
read-only stuff is read-only so 2007 big

350
00:12:35,160 --> 00:12:39,480
leap forward read only means read only

351
00:12:36,839 --> 00:12:41,760
for some stuff we'll get into that but

352
00:12:39,480 --> 00:12:44,040
it's a good it's a good step forward

353
00:12:41,760 --> 00:12:46,079
uh and this is kind of the birth of

354
00:12:44,040 --> 00:12:47,639
actually setting memory permissions in

355
00:12:46,079 --> 00:12:49,260
the kernel actually utilizing the

356
00:12:47,639 --> 00:12:52,320
features of the memory management unit

357
00:12:49,260 --> 00:12:54,360
of the CPU to make sure that the memory

358
00:12:52,320 --> 00:12:56,160
of the kernel resembles something

359
00:12:54,360 --> 00:13:00,420
sensible this all begins with this this

360
00:12:56,160 --> 00:13:03,000
debug feature in 2007. so nowadays this

361
00:13:00,420 --> 00:13:04,980
isn't called config debug Ro diver it's

362
00:13:03,000 --> 00:13:07,200
called strict kernel rwx or sometimes

363
00:13:04,980 --> 00:13:09,959
more broadly kernel memory protections

364
00:13:07,200 --> 00:13:11,880
uh probably kind of Baseline very

365
00:13:09,959 --> 00:13:13,320
fundamental very important kernel

366
00:13:11,880 --> 00:13:16,019
hardening feature

367
00:13:13,320 --> 00:13:18,300
so essentially asserting that code

368
00:13:16,019 --> 00:13:19,500
should be readable and executable not

369
00:13:18,300 --> 00:13:21,660
writable

370
00:13:19,500 --> 00:13:24,000
a data which isn't read-only should be

371
00:13:21,660 --> 00:13:26,940
readable and writable and read-only data

372
00:13:24,000 --> 00:13:29,279
should be read-only

373
00:13:26,940 --> 00:13:32,040
very glad that that happened

374
00:13:29,279 --> 00:13:33,779
so let's chug forward 2008

375
00:13:32,040 --> 00:13:36,480
still doing the 26 thing that's going to

376
00:13:33,779 --> 00:13:39,540
be a common a common theme I become a

377
00:13:36,480 --> 00:13:41,160
Linux user in 2008 this is Ubuntu 804 my

378
00:13:39,540 --> 00:13:42,860
first distro back when they're still

379
00:13:41,160 --> 00:13:45,420
doing the brown thing

380
00:13:42,860 --> 00:13:47,279
does anyone use this gnome too anyone

381
00:13:45,420 --> 00:13:49,380
used to have the the eyes on your panel

382
00:13:47,279 --> 00:13:51,420
did it follow your cursor around it's

383
00:13:49,380 --> 00:13:53,660
Glory Days it's all been downhill since

384
00:13:51,420 --> 00:13:53,660
then

385
00:13:54,260 --> 00:13:57,959
and so we start using some compiler

386
00:13:56,639 --> 00:14:00,720
features to make the kernel more secure

387
00:13:57,959 --> 00:14:03,000
and this is where we we enter canaries

388
00:14:00,720 --> 00:14:05,639
um does anyone show a fans anyone know

389
00:14:03,000 --> 00:14:07,980
the story of this particular device

390
00:14:05,639 --> 00:14:10,019
couple people so this is a canary

391
00:14:07,980 --> 00:14:11,880
resuscitator

392
00:14:10,019 --> 00:14:14,220
um essentially you know in Coal Mines

393
00:14:11,880 --> 00:14:15,540
they would send canaries in to see if

394
00:14:14,220 --> 00:14:17,399
they perish

395
00:14:15,540 --> 00:14:20,160
um and the engineers at the mine felt

396
00:14:17,399 --> 00:14:22,320
bad for the canaries so they invented a

397
00:14:20,160 --> 00:14:24,360
canary resuscitator not for economic

398
00:14:22,320 --> 00:14:26,519
means but just because they felt bad for

399
00:14:24,360 --> 00:14:29,040
killing a bunch of canaries so there's

400
00:14:26,519 --> 00:14:31,079
your fun fact of the day

401
00:14:29,040 --> 00:14:33,120
uh but when we talk about canaries we're

402
00:14:31,079 --> 00:14:35,579
talking about on the stacks so

403
00:14:33,120 --> 00:14:38,399
quick introduction to what the stack is

404
00:14:35,579 --> 00:14:40,620
it's where a bunch of your memory lives

405
00:14:38,399 --> 00:14:43,079
um the idea of a stack Canary is that

406
00:14:40,620 --> 00:14:45,240
the compiler inserts this magic value

407
00:14:43,079 --> 00:14:47,639
into the stack and we want to control

408
00:14:45,240 --> 00:14:49,380
what's on the stack we don't want a user

409
00:14:47,639 --> 00:14:51,720
we don't want an attacker to be able to

410
00:14:49,380 --> 00:14:53,880
modify the contents of a stack if we're

411
00:14:51,720 --> 00:14:56,579
trying to read some some data into a

412
00:14:53,880 --> 00:14:58,860
buffer and we read too much by accident

413
00:14:56,579 --> 00:15:01,019
that will override other stuff on the

414
00:14:58,860 --> 00:15:02,760
stack other stuff on the stack could be

415
00:15:01,019 --> 00:15:04,560
you know the return address where

416
00:15:02,760 --> 00:15:07,199
execution is going to jump to once we

417
00:15:04,560 --> 00:15:08,699
finish this code which is bad so we put

418
00:15:07,199 --> 00:15:11,279
a canary on the stack and then if anyone

419
00:15:08,699 --> 00:15:13,980
modifies the canary then the colonel

420
00:15:11,279 --> 00:15:15,779
panics this means that you can't without

421
00:15:13,980 --> 00:15:17,100
additional difficulty

422
00:15:15,779 --> 00:15:19,860
um

423
00:15:17,100 --> 00:15:21,060
do do buffer overflows as part of an

424
00:15:19,860 --> 00:15:22,620
exploit

425
00:15:21,060 --> 00:15:24,360
um because you're not but while you do

426
00:15:22,620 --> 00:15:26,279
that you'll blow over the canary and the

427
00:15:24,360 --> 00:15:28,860
kernel will panic

428
00:15:26,279 --> 00:15:31,500
so this is the first of many kernel of

429
00:15:28,860 --> 00:15:33,660
many kernel hardening features where

430
00:15:31,500 --> 00:15:35,160
the compiler gets a feature the feature

431
00:15:33,660 --> 00:15:36,420
starts getting used in user space and

432
00:15:35,160 --> 00:15:39,360
then people find a way to make it work

433
00:15:36,420 --> 00:15:41,579
in the kernel nowadays we have multiple

434
00:15:39,360 --> 00:15:44,040
different modes for this for like how

435
00:15:41,579 --> 00:15:46,560
many functions the compiler decides to

436
00:15:44,040 --> 00:15:48,360
put canaries into which is configurable

437
00:15:46,560 --> 00:15:50,579
Kernel build time

438
00:15:48,360 --> 00:15:51,660
so it's a small step but it's an

439
00:15:50,579 --> 00:15:53,820
important step

440
00:15:51,660 --> 00:15:56,459
and now we have canaries

441
00:15:53,820 --> 00:15:57,899
so we're skipping 2009 nothing important

442
00:15:56,459 --> 00:16:00,180
happened in 2009 it's not really

443
00:15:57,899 --> 00:16:02,399
important uh and now we get into the

444
00:16:00,180 --> 00:16:03,600
formative years we've kind of

445
00:16:02,399 --> 00:16:05,100
you know

446
00:16:03,600 --> 00:16:08,300
we've kind of done some stuff here it's

447
00:16:05,100 --> 00:16:10,680
really starting to ramp us up here so

448
00:16:08,300 --> 00:16:11,880
2.6.33 four years later and we're still

449
00:16:10,680 --> 00:16:12,779
doing this

450
00:16:11,880 --> 00:16:14,220
um

451
00:16:12,779 --> 00:16:15,660
I found this which is slightly

452
00:16:14,220 --> 00:16:17,820
horrifying I'm showing it to you but I'm

453
00:16:15,660 --> 00:16:20,699
in my my senior year of high school I

454
00:16:17,820 --> 00:16:22,500
found my badge from grade 12.

455
00:16:20,699 --> 00:16:24,000
um I think that's actually the last time

456
00:16:22,500 --> 00:16:25,620
I wore a tie

457
00:16:24,000 --> 00:16:28,740
so

458
00:16:25,620 --> 00:16:31,320
um yes slightly horrifying

459
00:16:28,740 --> 00:16:33,000
uh I haven't talked about modules yet so

460
00:16:31,320 --> 00:16:34,800
most you probably know what kernel

461
00:16:33,000 --> 00:16:35,880
modules are but they're dynamically

462
00:16:34,800 --> 00:16:38,519
loaded

463
00:16:35,880 --> 00:16:40,620
you know you'll boot up see okay what do

464
00:16:38,519 --> 00:16:42,899
I need load those modules to do that

465
00:16:40,620 --> 00:16:44,639
then at runtime you can dynamically load

466
00:16:42,899 --> 00:16:46,199
and unload your kernel modules

467
00:16:44,639 --> 00:16:47,820
and they have their own separate virtual

468
00:16:46,199 --> 00:16:49,920
address space

469
00:16:47,820 --> 00:16:51,660
um from the core kernel the core

470
00:16:49,920 --> 00:16:53,279
built-in kernel

471
00:16:51,660 --> 00:16:55,860
what this means is that they're

472
00:16:53,279 --> 00:16:58,259
essentially in a lot of ways

473
00:16:55,860 --> 00:16:59,820
um living in a separate memory space and

474
00:16:58,259 --> 00:17:01,380
we haven't figured out what read only

475
00:16:59,820 --> 00:17:04,260
means for modules yet that's kind of a

476
00:17:01,380 --> 00:17:05,880
different thing so uh kind of a problem

477
00:17:04,260 --> 00:17:07,740
we're still using Universal permissions

478
00:17:05,880 --> 00:17:10,439
for all of our kernel modules so if you

479
00:17:07,740 --> 00:17:12,959
can manage to for example

480
00:17:10,439 --> 00:17:15,179
um track a kernel module into writing

481
00:17:12,959 --> 00:17:17,640
somewhere it shouldn't then

482
00:17:15,179 --> 00:17:20,040
you could change the kernel code to run

483
00:17:17,640 --> 00:17:22,679
your exploit or whatever very bad so

484
00:17:20,040 --> 00:17:24,480
thankfully uh we figured out again as a

485
00:17:22,679 --> 00:17:26,160
debug feature that modules shouldn't do

486
00:17:24,480 --> 00:17:30,419
this either it's got the really catchy

487
00:17:26,160 --> 00:17:34,740
name of debug set module ranks uh

488
00:17:30,419 --> 00:17:36,480
ranks means uh read only non-execute I

489
00:17:34,740 --> 00:17:37,980
sure hope no one actually pronounced it

490
00:17:36,480 --> 00:17:39,600
that way but I don't have a historical

491
00:17:37,980 --> 00:17:42,240
reference for that

492
00:17:39,600 --> 00:17:43,679
um and yeah same concept as debug Arrow

493
00:17:42,240 --> 00:17:45,360
data but for modules

494
00:17:43,679 --> 00:17:47,640
years later it was going to get renamed

495
00:17:45,360 --> 00:17:50,580
to the more catchy config hardened

496
00:17:47,640 --> 00:17:53,460
module mappings before finally becoming

497
00:17:50,580 --> 00:17:55,740
strict module rwx so strict kernel iwx

498
00:17:53,460 --> 00:17:57,720
instructor module rwx like core kernel

499
00:17:55,740 --> 00:17:59,400
hardening features that mean that

500
00:17:57,720 --> 00:18:02,160
things like read only means read only

501
00:17:59,400 --> 00:18:03,900
code can't be writable and executable

502
00:18:02,160 --> 00:18:06,380
Etc so but you know we're getting

503
00:18:03,900 --> 00:18:06,380
somewhere

504
00:18:07,620 --> 00:18:12,660
2011. very very impactful year this is

505
00:18:10,860 --> 00:18:15,000
why

506
00:18:12,660 --> 00:18:16,140
we've we've dropped the whole 2-6 thing

507
00:18:15,000 --> 00:18:18,960
it just wasn't

508
00:18:16,140 --> 00:18:22,820
it wasn't really working out uh finally

509
00:18:18,960 --> 00:18:25,980
so we've entered 3.0 very very impactful

510
00:18:22,820 --> 00:18:27,600
so now let's talk about kernel memory

511
00:18:25,980 --> 00:18:30,360
and user memory

512
00:18:27,600 --> 00:18:32,400
things that are logically different but

513
00:18:30,360 --> 00:18:35,700
in terms of the CPU may not be that

514
00:18:32,400 --> 00:18:37,039
different after all so for most CPU

515
00:18:35,700 --> 00:18:39,660
architectures

516
00:18:37,039 --> 00:18:41,820
user space and kernel space share the

517
00:18:39,660 --> 00:18:43,679
same virtual memory they share the same

518
00:18:41,820 --> 00:18:45,960
range of addresses

519
00:18:43,679 --> 00:18:47,640
there's no isolation between them the

520
00:18:45,960 --> 00:18:49,500
same instructions read from kernel

521
00:18:47,640 --> 00:18:52,380
memory is read from user memory and

522
00:18:49,500 --> 00:18:54,660
whatnot so even though they're logically

523
00:18:52,380 --> 00:18:56,160
very different there's no way at the CPU

524
00:18:54,660 --> 00:18:57,240
level with the mmu memory management

525
00:18:56,160 --> 00:18:59,880
unit level

526
00:18:57,240 --> 00:19:01,919
to enforce that barrier so if the

527
00:18:59,880 --> 00:19:03,720
colonel thinks it's reading from

528
00:19:01,919 --> 00:19:05,100
kernel memory but it's actually been

529
00:19:03,720 --> 00:19:06,960
tricked into reading from user memory

530
00:19:05,100 --> 00:19:08,760
it's just going to do it and not care

531
00:19:06,960 --> 00:19:10,620
because there's no actual enforcement of

532
00:19:08,760 --> 00:19:12,360
that barrier so there's a few reasons

533
00:19:10,620 --> 00:19:15,299
why this is bad

534
00:19:12,360 --> 00:19:16,679
so I've got a lovely image I made on the

535
00:19:15,299 --> 00:19:20,460
plane this morning

536
00:19:16,679 --> 00:19:22,620
um so this is our stack again now if you

537
00:19:20,460 --> 00:19:24,600
don't have that isolation then it's very

538
00:19:22,620 --> 00:19:25,500
easy to compromise the kernel if there's

539
00:19:24,600 --> 00:19:27,720
a bug

540
00:19:25,500 --> 00:19:29,700
if you imagine you stack if you imagine

541
00:19:27,720 --> 00:19:31,020
a single function pointer on that stack

542
00:19:29,700 --> 00:19:33,240
so that could be a funk that could just

543
00:19:31,020 --> 00:19:35,280
be a function pointer as a in the kernel

544
00:19:33,240 --> 00:19:37,020
or you could you know beat the canary if

545
00:19:35,280 --> 00:19:38,460
you have one and then change the return

546
00:19:37,020 --> 00:19:41,100
address

547
00:19:38,460 --> 00:19:42,720
you can just change that to a user

548
00:19:41,100 --> 00:19:45,179
address and it'll run your code that

549
00:19:42,720 --> 00:19:47,580
lives in user space so the barrier that

550
00:19:45,179 --> 00:19:49,740
owning the kernel is as easy as I have

551
00:19:47,580 --> 00:19:51,600
this code running in user space trick to

552
00:19:49,740 --> 00:19:54,780
kind of a look at it boom you win

553
00:19:51,600 --> 00:19:57,780
Colonel's yours and a prize

554
00:19:54,780 --> 00:20:00,419
so thankfully and this is an emerging

555
00:19:57,780 --> 00:20:02,160
Trend that continues forward mmus and

556
00:20:00,419 --> 00:20:04,320
side chips are getting smarter Hardware

557
00:20:02,160 --> 00:20:05,700
vendors are starting to focus more on

558
00:20:04,320 --> 00:20:07,860
security they're starting to add more

559
00:20:05,700 --> 00:20:09,000
features either for security or they're

560
00:20:07,860 --> 00:20:11,820
starting to add memory management

561
00:20:09,000 --> 00:20:14,160
features that have Security benefits

562
00:20:11,820 --> 00:20:16,320
uh there's only so much that can be done

563
00:20:14,160 --> 00:20:18,600
by software the problem with enforcing

564
00:20:16,320 --> 00:20:20,820
security things in software is that it's

565
00:20:18,600 --> 00:20:22,260
often slow and you could solve

566
00:20:20,820 --> 00:20:23,460
everyone's security problems but if you

567
00:20:22,260 --> 00:20:27,120
regress their performance by two percent

568
00:20:23,460 --> 00:20:29,160
they won't turn it on so uh because of

569
00:20:27,120 --> 00:20:30,059
this often we need Hardware assists we

570
00:20:29,160 --> 00:20:31,679
need to be able to set things in

571
00:20:30,059 --> 00:20:33,299
Hardware that will enforce our

572
00:20:31,679 --> 00:20:35,400
permissions for us

573
00:20:33,299 --> 00:20:37,080
so this becomes an increasing and

574
00:20:35,400 --> 00:20:38,700
increasing and increasing focus of

575
00:20:37,080 --> 00:20:41,160
Hardware vendors

576
00:20:38,700 --> 00:20:42,900
uh so the thing that lets us fix this

577
00:20:41,160 --> 00:20:44,400
problem is called smap we're really good

578
00:20:42,900 --> 00:20:45,120
at naming stuff

579
00:20:44,400 --> 00:20:48,360
um

580
00:20:45,120 --> 00:20:51,120
so snap on on x86 refers to supervisor

581
00:20:48,360 --> 00:20:53,340
mode execution prevention so what that

582
00:20:51,120 --> 00:20:56,280
means is when you are in

583
00:20:53,340 --> 00:20:58,620
supervisor mode when you are

584
00:20:56,280 --> 00:21:02,100
the CPU and you're executing

585
00:20:58,620 --> 00:21:05,340
code as the kernel you cannot execute

586
00:21:02,100 --> 00:21:07,200
from user memory the CPU just won't let

587
00:21:05,340 --> 00:21:08,820
you so if the Kernel's been tricked

588
00:21:07,200 --> 00:21:10,140
it'll try to do it and it'll just not

589
00:21:08,820 --> 00:21:12,960
work

590
00:21:10,140 --> 00:21:15,059
so basically you toggle this this bit in

591
00:21:12,960 --> 00:21:17,039
the mmu you try to read from a user

592
00:21:15,059 --> 00:21:20,039
address and it just doesn't very cool

593
00:21:17,039 --> 00:21:21,720
very nice so now this doesn't prevent

594
00:21:20,039 --> 00:21:23,880
exploits none of these mitigations

595
00:21:21,720 --> 00:21:26,520
prevent exploits but they make the

596
00:21:23,880 --> 00:21:28,080
barrier a lot higher they make it much

597
00:21:26,520 --> 00:21:29,880
more difficult which means that you

598
00:21:28,080 --> 00:21:31,679
often need multiple smaller

599
00:21:29,880 --> 00:21:34,620
vulnerabilities to be able to actually

600
00:21:31,679 --> 00:21:37,159
compromise something now instead of just

601
00:21:34,620 --> 00:21:39,840
pointing the kernel at your pre-prepared

602
00:21:37,159 --> 00:21:42,299
exploit code in user space

603
00:21:39,840 --> 00:21:44,400
you now have to somehow get your exploit

604
00:21:42,299 --> 00:21:46,380
code inside of the kernel memories it

605
00:21:44,400 --> 00:21:49,559
but inside of the kernel memory itself

606
00:21:46,380 --> 00:21:52,799
which is substantially harder so I think

607
00:21:49,559 --> 00:21:55,980
snap and it's also called pxn on arm

608
00:21:52,799 --> 00:21:57,780
which is privileged execution never I

609
00:21:55,980 --> 00:21:59,400
want to say and it has other names on

610
00:21:57,780 --> 00:22:02,340
other architectures I think this is

611
00:21:59,400 --> 00:22:04,500
probably the single highest value Kernel

612
00:22:02,340 --> 00:22:08,600
Security thing

613
00:22:04,500 --> 00:22:08,600
so good job on that

614
00:22:10,080 --> 00:22:13,020
let's go forward

615
00:22:11,520 --> 00:22:15,900
2012.

616
00:22:13,020 --> 00:22:17,820
uh good year we've seen version numbers

617
00:22:15,900 --> 00:22:18,960
that's continuing on that's all very

618
00:22:17,820 --> 00:22:21,360
good

619
00:22:18,960 --> 00:22:24,000
the world comes to an end I can prove

620
00:22:21,360 --> 00:22:25,620
this with a little anecdote I was in my

621
00:22:24,000 --> 00:22:27,240
first year of computer science at

622
00:22:25,620 --> 00:22:29,520
University

623
00:22:27,240 --> 00:22:31,500
um I was talking I was you know new on

624
00:22:29,520 --> 00:22:32,820
campus I was talking to a cute girl and

625
00:22:31,500 --> 00:22:35,580
I mentioned I was doing computer science

626
00:22:32,820 --> 00:22:38,940
and she says oh do you use Linux I go

627
00:22:35,580 --> 00:22:41,820
yeah I actually use Arch

628
00:22:38,940 --> 00:22:44,220
um and she says wow that's really

629
00:22:41,820 --> 00:22:45,600
impressive now there's no Universe in

630
00:22:44,220 --> 00:22:47,640
which someone would be impressed let

631
00:22:45,600 --> 00:22:49,740
alone a cute girl that someone used Arch

632
00:22:47,640 --> 00:22:51,360
Linux therefore I can definitively prove

633
00:22:49,740 --> 00:22:55,320
that we're all living in a simulation

634
00:22:51,360 --> 00:22:58,679
this also this also happened in in 2012

635
00:22:55,320 --> 00:22:59,580
so good Good Year very iconic moment

636
00:22:58,679 --> 00:23:01,380
there

637
00:22:59,580 --> 00:23:03,539
now

638
00:23:01,380 --> 00:23:05,580
we talked about executing user memory

639
00:23:03,539 --> 00:23:08,100
The Logical extension of of the problems

640
00:23:05,580 --> 00:23:10,200
of that is just accessing user membrane

641
00:23:08,100 --> 00:23:12,240
I said okay well now you have to get

642
00:23:10,200 --> 00:23:14,580
your exploit inside of Kernel memory to

643
00:23:12,240 --> 00:23:17,880
be able to run it but if you can trick

644
00:23:14,580 --> 00:23:19,380
the kernel into writing into and if you

645
00:23:17,880 --> 00:23:20,760
can trick the kernel to maybe reading

646
00:23:19,380 --> 00:23:23,640
from user and then writing that to

647
00:23:20,760 --> 00:23:25,440
Kernel space then you already have your

648
00:23:23,640 --> 00:23:27,600
exploiting kernel memory so we want to

649
00:23:25,440 --> 00:23:29,820
be able to restrict how the kernel

650
00:23:27,600 --> 00:23:32,220
accesses user memory part of the problem

651
00:23:29,820 --> 00:23:34,559
here is that it needs to do it it does

652
00:23:32,220 --> 00:23:36,059
it all the time it will read stuff from

653
00:23:34,559 --> 00:23:37,380
user space and then write it out to a

654
00:23:36,059 --> 00:23:39,240
device or the billion other things that

655
00:23:37,380 --> 00:23:41,100
kernel does so the Kernel's reading and

656
00:23:39,240 --> 00:23:43,440
writing to user memory all the time how

657
00:23:41,100 --> 00:23:44,940
do we enforce some kind of barrier here

658
00:23:43,440 --> 00:23:46,320
how do we actually turn this into a

659
00:23:44,940 --> 00:23:49,020
security benefit

660
00:23:46,320 --> 00:23:51,659
uh so we want to be able to prevent this

661
00:23:49,020 --> 00:23:53,100
in places we don't want it but be able

662
00:23:51,659 --> 00:23:54,780
to do it in places we do we don't have

663
00:23:53,100 --> 00:23:56,700
we want to have our cake and eat it too

664
00:23:54,780 --> 00:23:59,220
is the point here

665
00:23:56,700 --> 00:24:01,440
so we get a thing like Snap called Snap

666
00:23:59,220 --> 00:24:03,720
that lets us do that we get this mmu

667
00:24:01,440 --> 00:24:05,280
feature we can turn on and it prevents

668
00:24:03,720 --> 00:24:08,240
the kernel from accessing user memory

669
00:24:05,280 --> 00:24:10,440
you go to do it and the mmu says no

670
00:24:08,240 --> 00:24:12,440
problem here is you can't just turn that

671
00:24:10,440 --> 00:24:15,059
on all the time like you can with SNAP

672
00:24:12,440 --> 00:24:16,919
because we do need to access user memory

673
00:24:15,059 --> 00:24:20,220
it's it's very important

674
00:24:16,919 --> 00:24:23,400
so thankfully we have these functions

675
00:24:20,220 --> 00:24:25,320
like copy to user and copy from user and

676
00:24:23,400 --> 00:24:28,799
so what we do is when we go to copy to

677
00:24:25,320 --> 00:24:30,720
user we enable being able to access user

678
00:24:28,799 --> 00:24:33,360
memory do what we need to do and then

679
00:24:30,720 --> 00:24:35,640
disable it again

680
00:24:33,360 --> 00:24:37,260
so we can just do that so you're no

681
00:24:35,640 --> 00:24:39,480
longer allowed to just arbitrarily

682
00:24:37,260 --> 00:24:41,700
access user memory you have to do it

683
00:24:39,480 --> 00:24:45,179
using the magic functions and then they

684
00:24:41,700 --> 00:24:46,919
handle all your smapping for you this is

685
00:24:45,179 --> 00:24:49,200
quite a bit more complicated obviously

686
00:24:46,919 --> 00:24:50,880
if you have any way in which you leave

687
00:24:49,200 --> 00:24:52,260
your execution you take an interrupt or

688
00:24:50,880 --> 00:24:56,280
whatever you need to be very careful not

689
00:24:52,260 --> 00:24:58,440
to accidentally leave smap off

690
00:24:56,280 --> 00:25:01,020
which would be bad you also need to not

691
00:24:58,440 --> 00:25:02,820
have smap on when it shouldn't be

692
00:25:01,020 --> 00:25:04,500
I'm only bringing this up because I

693
00:25:02,820 --> 00:25:06,720
wrote the first implementation for power

694
00:25:04,500 --> 00:25:08,640
and basically broke everything and then

695
00:25:06,720 --> 00:25:10,620
smarter people rewrote it so maybe this

696
00:25:08,640 --> 00:25:14,240
is just me justifying my own failure but

697
00:25:10,620 --> 00:25:17,640
it's quite complicated to implement

698
00:25:14,240 --> 00:25:19,020
which leads to uh these copy two from

699
00:25:17,640 --> 00:25:21,419
user functions why do we have them

700
00:25:19,020 --> 00:25:23,580
anyway it's kind of a weird thing if you

701
00:25:21,419 --> 00:25:24,659
imagine someone writing a kernel for the

702
00:25:23,580 --> 00:25:27,000
first time

703
00:25:24,659 --> 00:25:28,080
uh why do we have these functions just

704
00:25:27,000 --> 00:25:29,760
to do something we were going to do

705
00:25:28,080 --> 00:25:31,620
anyway why can't we just directly read

706
00:25:29,760 --> 00:25:34,559
and write the addresses we were going to

707
00:25:31,620 --> 00:25:36,059
I had a bit of a look into this because

708
00:25:34,559 --> 00:25:37,679
here's the thing Windows doesn't have

709
00:25:36,059 --> 00:25:39,960
smap because they have this problem

710
00:25:37,679 --> 00:25:43,140
window the windows kernel doesn't have

711
00:25:39,960 --> 00:25:43,860
these accesses at all user IO goes

712
00:25:43,140 --> 00:25:46,140
through

713
00:25:43,860 --> 00:25:48,059
so they've just got this code base with

714
00:25:46,140 --> 00:25:50,520
direct accesses everywhere they can't

715
00:25:48,059 --> 00:25:52,799
add some stuff to so Windows doesn't

716
00:25:50,520 --> 00:25:54,600
have snap so first of all sucked in

717
00:25:52,799 --> 00:25:57,120
second of all

718
00:25:54,600 --> 00:25:58,559
uh how come we do so we looked a bit

719
00:25:57,120 --> 00:26:00,480
into the history of this because you

720
00:25:58,559 --> 00:26:02,220
know without having these functions it'd

721
00:26:00,480 --> 00:26:03,960
be a Monumental effort to try to find

722
00:26:02,220 --> 00:26:06,299
every single site in which we do this

723
00:26:03,960 --> 00:26:08,220
kind of thing but it turns out in the

724
00:26:06,299 --> 00:26:11,400
very first public release back when the

725
00:26:08,220 --> 00:26:12,840
make file called it freaks FIA X I don't

726
00:26:11,400 --> 00:26:14,940
know what myos was thinking with that

727
00:26:12,840 --> 00:26:17,159
one uh or if it was even him but yeah

728
00:26:14,940 --> 00:26:19,740
it's back in the very first version of

729
00:26:17,159 --> 00:26:21,900
Linux we had these kind of accesses not

730
00:26:19,740 --> 00:26:23,159
not with that specific name but we had

731
00:26:21,900 --> 00:26:25,860
these functions

732
00:26:23,159 --> 00:26:27,900
and part of it was just that lennis

733
00:26:25,860 --> 00:26:30,360
wanted to play with a lot of features of

734
00:26:27,900 --> 00:26:32,760
the CPU he wanted his test fund kernel

735
00:26:30,360 --> 00:26:34,020
to do lots of stuff and so he had user

736
00:26:32,760 --> 00:26:35,640
memory and kernel memory in these

737
00:26:34,020 --> 00:26:39,360
different segments

738
00:26:35,640 --> 00:26:41,279
um so just that little Idea LED to this

739
00:26:39,360 --> 00:26:44,460
feature being monumentally easier to

740
00:26:41,279 --> 00:26:46,320
implement for Linux than than on Windows

741
00:26:44,460 --> 00:26:48,179
which is pretty cool there's also some

742
00:26:46,320 --> 00:26:50,340
architectures that need to do special

743
00:26:48,179 --> 00:26:51,900
stuff to be able to access to be able to

744
00:26:50,340 --> 00:26:54,240
access user memory so

745
00:26:51,900 --> 00:26:57,799
comes in very handy and yet another

746
00:26:54,240 --> 00:27:02,340
Point as to why uh Windows sucks okay

747
00:26:57,799 --> 00:27:05,159
so 2013 versions still sensible which is

748
00:27:02,340 --> 00:27:06,360
good Linux wins Jeopardy I don't know if

749
00:27:05,159 --> 00:27:08,820
you knew that if you have a commit in

750
00:27:06,360 --> 00:27:10,620
the kernel before 2013 then you also won

751
00:27:08,820 --> 00:27:11,700
Jeopardy and you can tell your family

752
00:27:10,620 --> 00:27:13,080
and friends

753
00:27:11,700 --> 00:27:15,659
so this is

754
00:27:13,080 --> 00:27:17,100
um this is IBM's Watson

755
00:27:15,659 --> 00:27:20,220
thing

756
00:27:17,100 --> 00:27:22,260
um running on Linux on power I think so

757
00:27:20,220 --> 00:27:25,620
yes there you go Linux one Jeopardy

758
00:27:22,260 --> 00:27:27,779
beating out uh Ken Jennings and the

759
00:27:25,620 --> 00:27:29,400
other guy who was not Ken Jennings

760
00:27:27,779 --> 00:27:31,620
uh-huh

761
00:27:29,400 --> 00:27:32,700
so if you want me to remember his name

762
00:27:31,620 --> 00:27:34,260
he should have

763
00:27:32,700 --> 00:27:35,840
done better

764
00:27:34,260 --> 00:27:38,940
um

765
00:27:35,840 --> 00:27:41,940
so this is this is when we get Tesla and

766
00:27:38,940 --> 00:27:44,220
this is a bit of an interlude into uh

767
00:27:41,940 --> 00:27:46,020
the kind of complexity versus security

768
00:27:44,220 --> 00:27:46,919
gain issues you have in this kind of

769
00:27:46,020 --> 00:27:49,799
space

770
00:27:46,919 --> 00:27:52,200
so casla stands for kernel address space

771
00:27:49,799 --> 00:27:54,539
layout randomization if you're very if

772
00:27:52,200 --> 00:27:56,039
you've ever done any kind of binary

773
00:27:54,539 --> 00:27:57,779
exploitation and use a space you'd be

774
00:27:56,039 --> 00:27:59,580
familiar with ASLA which is address

775
00:27:57,779 --> 00:28:01,500
space layout randomization so every time

776
00:27:59,580 --> 00:28:04,260
you run a program

777
00:28:01,500 --> 00:28:06,960
it's things are in different spots uh

778
00:28:04,260 --> 00:28:08,640
the layout of its memory gets randomized

779
00:28:06,960 --> 00:28:10,500
so that you can't just find things once

780
00:28:08,640 --> 00:28:12,779
and then reuse the exploit forever

781
00:28:10,500 --> 00:28:14,159
so what if we do that to the kernel what

782
00:28:12,779 --> 00:28:15,720
if we're making when we boot the kernel

783
00:28:14,159 --> 00:28:17,760
all of its stuff goes in different

784
00:28:15,720 --> 00:28:19,020
places so in order to hack things you

785
00:28:17,760 --> 00:28:21,900
need to be able to find where the stuff

786
00:28:19,020 --> 00:28:23,880
lives fun little mini game for

787
00:28:21,900 --> 00:28:26,940
um for exploiters out there

788
00:28:23,880 --> 00:28:28,860
which is a decent idea in theory that

789
00:28:26,940 --> 00:28:31,559
there's there's potentially some issues

790
00:28:28,860 --> 00:28:34,860
with it first of all

791
00:28:31,559 --> 00:28:36,900
uh the kernel now can't leak any

792
00:28:34,860 --> 00:28:38,580
information ever so if you imagine the

793
00:28:36,900 --> 00:28:41,779
code base really big really fast

794
00:28:38,580 --> 00:28:44,820
changing yada yada like the Linux kernel

795
00:28:41,779 --> 00:28:47,820
any single place there that we reveal

796
00:28:44,820 --> 00:28:49,159
the location of something uh to a to

797
00:28:47,820 --> 00:28:52,440
user space

798
00:28:49,159 --> 00:28:54,419
is basically getting around Tesla if we

799
00:28:52,440 --> 00:28:56,159
print out a pointer somewhere if we have

800
00:28:54,419 --> 00:28:58,020
anything that reveals the location of a

801
00:28:56,159 --> 00:28:59,460
symbol and kernel memory then that can

802
00:28:58,020 --> 00:29:00,840
be used to figure out where everything

803
00:28:59,460 --> 00:29:03,840
else is

804
00:29:00,840 --> 00:29:05,640
which is bad so info weeks get around

805
00:29:03,840 --> 00:29:07,200
kasler and there's a lot of code to

806
00:29:05,640 --> 00:29:08,880
detect for info leaks which creates a

807
00:29:07,200 --> 00:29:10,700
lot of work to find and fix all of the

808
00:29:08,880 --> 00:29:13,860
info leaks

809
00:29:10,700 --> 00:29:14,659
kernels also again big mistakes are very

810
00:29:13,860 --> 00:29:19,200
easy

811
00:29:14,659 --> 00:29:21,059
another side tangent rant is that if you

812
00:29:19,200 --> 00:29:22,500
have a casler enabled kernel and you

813
00:29:21,059 --> 00:29:23,640
have like a crash dump or something and

814
00:29:22,500 --> 00:29:26,039
you want to figure out what went wrong

815
00:29:23,640 --> 00:29:28,320
uh good luck figuring that out because

816
00:29:26,039 --> 00:29:30,000
all your stuff's in random places so you

817
00:29:28,320 --> 00:29:31,620
have to beat Casa to figure out what

818
00:29:30,000 --> 00:29:33,000
went wrong

819
00:29:31,620 --> 00:29:34,919
um and then we have this info week

820
00:29:33,000 --> 00:29:37,020
prevention going everywhere around the

821
00:29:34,919 --> 00:29:38,340
kernel you know me printing pointers

822
00:29:37,020 --> 00:29:39,899
everywhere trying to find out what my

823
00:29:38,340 --> 00:29:41,640
thing broke and then I just see

824
00:29:39,899 --> 00:29:44,460
underscore underscore pointer vowel

825
00:29:41,640 --> 00:29:46,620
underscore underscore because you know

826
00:29:44,460 --> 00:29:47,940
that's the world we live in now that's

827
00:29:46,620 --> 00:29:49,440
terrifying

828
00:29:47,940 --> 00:29:51,659
so

829
00:29:49,440 --> 00:29:53,460
has been pretty heavily criticized in

830
00:29:51,659 --> 00:29:55,919
terms of the value it brings

831
00:29:53,460 --> 00:29:58,980
um now that I have quite quote unquote

832
00:29:55,919 --> 00:30:00,659
industry standard casual defeats uh

833
00:29:58,980 --> 00:30:02,700
because there's a lot of them

834
00:30:00,659 --> 00:30:04,200
uh and they've taken the order of

835
00:30:02,700 --> 00:30:08,940
minutes

836
00:30:04,200 --> 00:30:11,460
um to essentially get around Kessler the

837
00:30:08,940 --> 00:30:14,340
fun the one I think is the most fun is

838
00:30:11,460 --> 00:30:16,679
that someone you can you can look at the

839
00:30:14,340 --> 00:30:20,039
voltage of the CPU

840
00:30:16,679 --> 00:30:22,580
um and basically try and access all the

841
00:30:20,039 --> 00:30:25,559
ranges that the kernel could be at

842
00:30:22,580 --> 00:30:27,000
and by looking at the voltage of the CPU

843
00:30:25,559 --> 00:30:28,980
when it spikes you can figure out that's

844
00:30:27,000 --> 00:30:31,559
where the kernel is and so just with

845
00:30:28,980 --> 00:30:33,240
voltage of a core you can figure out how

846
00:30:31,559 --> 00:30:34,520
to get around Kesler which is pretty

847
00:30:33,240 --> 00:30:36,600
cool

848
00:30:34,520 --> 00:30:38,220
so there's a lot of different mechanisms

849
00:30:36,600 --> 00:30:41,580
to find stuff in the kernel

850
00:30:38,220 --> 00:30:43,799
it does make attacks harder but not a

851
00:30:41,580 --> 00:30:46,500
substantial jump so you know you're

852
00:30:43,799 --> 00:30:48,779
taking more of a security researchers

853
00:30:46,500 --> 00:30:50,960
morning as opposed to making an attack

854
00:30:48,779 --> 00:30:55,679
relatively infeasible

855
00:30:50,960 --> 00:30:57,600
so that's Kessler it it tried its best

856
00:30:55,679 --> 00:30:58,860
um and maybe this is just me justifying

857
00:30:57,600 --> 00:31:02,039
what I haven't written castle for power

858
00:30:58,860 --> 00:31:03,419
yet but I I think it's of dubious

859
00:31:02,039 --> 00:31:05,159
Effectiveness and I'm happy to argue

860
00:31:03,419 --> 00:31:07,559
with people about that later if anyone's

861
00:31:05,159 --> 00:31:11,640
anyone's interested

862
00:31:07,559 --> 00:31:14,340
so let's keep going through history uh

863
00:31:11,640 --> 00:31:16,500
we've run out of uh fingers and toes on

864
00:31:14,340 --> 00:31:18,620
Linus 12 odds and so we've incremented

865
00:31:16,500 --> 00:31:21,419
major versions up to up to four three

866
00:31:18,620 --> 00:31:23,460
very impactful year 2015 to the colonel

867
00:31:21,419 --> 00:31:26,159
because here's my first commit

868
00:31:23,460 --> 00:31:27,240
um it's it's all downhill from here I'm

869
00:31:26,159 --> 00:31:31,080
pretty sure this patch is completely

870
00:31:27,240 --> 00:31:34,320
broken but I I was doing my best

871
00:31:31,080 --> 00:31:39,310
um and so this

872
00:31:34,320 --> 00:31:43,520
plus 11 that's uh that's here yeah

873
00:31:39,310 --> 00:31:43,520
[Laughter]

874
00:31:44,100 --> 00:31:48,720
I just moved from Sunny Gold Coast to

875
00:31:46,500 --> 00:31:50,740
Canberra so this patch not the only

876
00:31:48,720 --> 00:31:54,960
questionable decision I made

877
00:31:50,740 --> 00:31:56,460
[Laughter]

878
00:31:54,960 --> 00:31:57,360
the cater Tooling in and around the

879
00:31:56,460 --> 00:31:59,520
kernel

880
00:31:57,360 --> 00:32:01,260
as time goes on and a huge step forward

881
00:31:59,520 --> 00:32:04,500
here was was K sand all the kernel

882
00:32:01,260 --> 00:32:07,860
address sanitizer so asan or address

883
00:32:04,500 --> 00:32:11,840
sanitizers are feature in llvm in clang

884
00:32:07,860 --> 00:32:14,220
you know to find memory access misuses

885
00:32:11,840 --> 00:32:15,600
in user programs and then with

886
00:32:14,220 --> 00:32:17,700
substantial amount of effort that can be

887
00:32:15,600 --> 00:32:20,159
applied to Linux kernel as well so K10

888
00:32:17,700 --> 00:32:21,539
is a dynamic memory safety error

889
00:32:20,159 --> 00:32:23,580
detector it's not the kind of thing you

890
00:32:21,539 --> 00:32:25,380
build into the Linux kernel itself you

891
00:32:23,580 --> 00:32:26,820
run it all the time it's something you

892
00:32:25,380 --> 00:32:29,159
test with

893
00:32:26,820 --> 00:32:31,380
it's not a defense in itself but it

894
00:32:29,159 --> 00:32:32,880
finds spots where things are happening

895
00:32:31,380 --> 00:32:35,399
that should not be happening and tells

896
00:32:32,880 --> 00:32:36,720
you how to fix them sometimes salty if

897
00:32:35,399 --> 00:32:37,620
they've been chasing a case and Bug for

898
00:32:36,720 --> 00:32:40,500
a week

899
00:32:37,620 --> 00:32:41,940
um but KFAN is a huge step forward it

900
00:32:40,500 --> 00:32:43,500
finds things like out of bounds use

901
00:32:41,940 --> 00:32:45,720
after freeze double phrase these are

902
00:32:43,500 --> 00:32:48,000
like the building blocks for exploits

903
00:32:45,720 --> 00:32:50,580
these are the kinds of bugs people write

904
00:32:48,000 --> 00:32:52,860
in memory on safe languages like C that

905
00:32:50,580 --> 00:32:54,659
lead to real world exploits becoming

906
00:32:52,860 --> 00:32:56,940
possible so having the kind of tooling

907
00:32:54,659 --> 00:32:58,500
to be able to find detect and fix them

908
00:32:56,940 --> 00:33:00,899
is really significant

909
00:32:58,500 --> 00:33:04,320
essentially it has a shadow memory

910
00:33:00,899 --> 00:33:06,240
region for for allocations and then when

911
00:33:04,320 --> 00:33:07,500
you try to do them it will check if

912
00:33:06,240 --> 00:33:08,820
you're allowed to do them and if you're

913
00:33:07,500 --> 00:33:10,679
not allowed to do them it will fit out

914
00:33:08,820 --> 00:33:11,399
this nice error report

915
00:33:10,679 --> 00:33:14,460
um

916
00:33:11,399 --> 00:33:15,899
about that so I found this quote I

917
00:33:14,460 --> 00:33:19,980
apparently don't attribute it to anyone

918
00:33:15,899 --> 00:33:22,140
it's just fact that tilde 70 of security

919
00:33:19,980 --> 00:33:24,080
issues a memory misuse bugs but I found

920
00:33:22,140 --> 00:33:26,399
this number in a few different places

921
00:33:24,080 --> 00:33:28,860
especially when you look at

922
00:33:26,399 --> 00:33:31,320
big projects written in C

923
00:33:28,860 --> 00:33:34,200
most bugs are memory misuse bugs so

924
00:33:31,320 --> 00:33:36,480
finding those kind of things leads to a

925
00:33:34,200 --> 00:33:38,039
tangible security benefit you know a

926
00:33:36,480 --> 00:33:40,919
bunch of vulnerabilities would have

927
00:33:38,039 --> 00:33:43,380
become real if you know tools like ksan

928
00:33:40,919 --> 00:33:45,899
hadn't found bug classes like this

929
00:33:43,380 --> 00:33:49,260
is a look at the memory corruption that

930
00:33:45,899 --> 00:33:50,580
K Sands found so it can tell you you

931
00:33:49,260 --> 00:33:52,080
know where the address what object the

932
00:33:50,580 --> 00:33:55,200
address belongs to what the offset is

933
00:33:52,080 --> 00:33:57,179
what page it's in yada yada so very cool

934
00:33:55,200 --> 00:33:59,640
very sophisticated but it's it's slow so

935
00:33:57,179 --> 00:34:00,899
no one turns it on but we do in CI so

936
00:33:59,640 --> 00:34:02,340
that's that's good

937
00:34:00,899 --> 00:34:04,019
this is what happens when you have K

938
00:34:02,340 --> 00:34:05,399
sand now the horrifying thing is what

939
00:34:04,019 --> 00:34:06,980
happens when you Dart and what happens

940
00:34:05,399 --> 00:34:09,240
when you don't is nothing

941
00:34:06,980 --> 00:34:10,560
so if you're trying to debug a memory

942
00:34:09,240 --> 00:34:12,599
corruption hopefully not many of you

943
00:34:10,560 --> 00:34:13,500
have been here I suspect a lot of you

944
00:34:12,599 --> 00:34:15,359
have

945
00:34:13,500 --> 00:34:17,159
is the best case when you have a memory

946
00:34:15,359 --> 00:34:19,379
corruption is that you find it straight

947
00:34:17,159 --> 00:34:23,040
away your kernel crashes and you go and

948
00:34:19,379 --> 00:34:24,599
fix it that's the dream case the bad

949
00:34:23,040 --> 00:34:26,460
case is that you crash and you don't

950
00:34:24,599 --> 00:34:28,020
quite know why it's not really obvious

951
00:34:26,460 --> 00:34:29,399
you have to try and figure it out and

952
00:34:28,020 --> 00:34:31,440
the absolute worst case is you don't

953
00:34:29,399 --> 00:34:33,839
notice something's gone wrong you don't

954
00:34:31,440 --> 00:34:36,419
know how to find it you kind of you know

955
00:34:33,839 --> 00:34:38,099
up creep without the pedal so ksen

956
00:34:36,419 --> 00:34:39,359
solves this because at the point that

957
00:34:38,099 --> 00:34:41,520
the thing goes wrong in the first place

958
00:34:39,359 --> 00:34:44,359
you detect the problem so really

959
00:34:41,520 --> 00:34:44,359
significant step forward

960
00:34:44,580 --> 00:34:47,760
chugging on through history of which

961
00:34:46,500 --> 00:34:50,940
there is still some

962
00:34:47,760 --> 00:34:53,820
versions saying it's my first LCA LCA by

963
00:34:50,940 --> 00:34:56,900
the Bay who here was in Geelong

964
00:34:53,820 --> 00:34:59,040
very nice very nice so

965
00:34:56,900 --> 00:35:01,500
this is when we start getting smarter

966
00:34:59,040 --> 00:35:03,180
about the kernel stack itself so before

967
00:35:01,500 --> 00:35:05,400
I gave you this image of a stack and

968
00:35:03,180 --> 00:35:07,740
said you know you can compromise them

969
00:35:05,400 --> 00:35:09,420
and we have to be careful about that the

970
00:35:07,740 --> 00:35:11,339
kernel Stacks are all allocated using

971
00:35:09,420 --> 00:35:13,560
physically contiguous memory there's no

972
00:35:11,339 --> 00:35:15,660
real infrastructure around it meanwhile

973
00:35:13,560 --> 00:35:17,700
for example all of modules are allocated

974
00:35:15,660 --> 00:35:19,800
using the virtual memory subsystem this

975
00:35:17,700 --> 00:35:21,839
means that addresses can be you know

976
00:35:19,800 --> 00:35:25,260
separate from each other

977
00:35:21,839 --> 00:35:26,640
uh another big benefit is that because

978
00:35:25,260 --> 00:35:28,140
your addresses can be separate from each

979
00:35:26,640 --> 00:35:30,180
other you can have spaces around them

980
00:35:28,140 --> 00:35:31,740
that for example can be marked as you

981
00:35:30,180 --> 00:35:34,079
know poisoned God pages so if you

982
00:35:31,740 --> 00:35:35,940
overflow them it gets detected which is

983
00:35:34,079 --> 00:35:38,820
nice for bug finding reasons I mentioned

984
00:35:35,940 --> 00:35:41,460
before so by reworking the kernel Stacks

985
00:35:38,820 --> 00:35:43,140
to be on top of virtual memory you no

986
00:35:41,460 --> 00:35:45,300
longer have first of all Stacks next to

987
00:35:43,140 --> 00:35:47,339
each other where an overflow on one

988
00:35:45,300 --> 00:35:50,640
stack could compromise the one above it

989
00:35:47,339 --> 00:35:52,020
but you also get much better debugging

990
00:35:50,640 --> 00:35:54,720
information when you do have some kind

991
00:35:52,020 --> 00:35:57,000
of buffer overflow so pretty fundamental

992
00:35:54,720 --> 00:35:59,640
thing there this is my image from before

993
00:35:57,000 --> 00:36:01,320
so this is physically contiguous in the

994
00:35:59,640 --> 00:36:04,020
case of Kernel Stacks until you have

995
00:36:01,320 --> 00:36:05,940
stacks on virtual memory instead so on

996
00:36:04,020 --> 00:36:07,800
virtual memory you can imagine instead

997
00:36:05,940 --> 00:36:09,780
of the return address being right next

998
00:36:07,800 --> 00:36:11,700
to the previous function stack frame

999
00:36:09,780 --> 00:36:13,500
there's a gap and there's you know

1000
00:36:11,700 --> 00:36:15,960
poison pages in that Gap that say you're

1001
00:36:13,500 --> 00:36:17,160
not allowed to do stuff here

1002
00:36:15,960 --> 00:36:19,560
so

1003
00:36:17,160 --> 00:36:21,540
the modern era

1004
00:36:19,560 --> 00:36:24,060
that was history now we're in here and

1005
00:36:21,540 --> 00:36:25,619
now which is 2017-ish apparently but

1006
00:36:24,060 --> 00:36:27,780
just roll with it

1007
00:36:25,619 --> 00:36:29,760
um so this is the stuff I'm about to

1008
00:36:27,780 --> 00:36:32,160
talk about I essentially consider to

1009
00:36:29,760 --> 00:36:33,839
have birthed the era wherein now where

1010
00:36:32,160 --> 00:36:35,220
security is much more at the Forefront

1011
00:36:33,839 --> 00:36:37,560
of people's minds

1012
00:36:35,220 --> 00:36:39,540
where we have a lot more capability we

1013
00:36:37,560 --> 00:36:42,060
have a lot more technology and people

1014
00:36:39,540 --> 00:36:45,060
care a lot more about security so these

1015
00:36:42,060 --> 00:36:45,900
guys are a big reason for that

1016
00:36:45,060 --> 00:36:48,720
um

1017
00:36:45,900 --> 00:36:51,180
so Spectra meltdown essentially a

1018
00:36:48,720 --> 00:36:53,700
hardware vulnerabilities so they are

1019
00:36:51,180 --> 00:36:55,800
Hardware flaws that allow attackers to

1020
00:36:53,700 --> 00:36:57,780
get around a bunch of sensible

1021
00:36:55,800 --> 00:37:00,720
protections that the kernel has by just

1022
00:36:57,780 --> 00:37:03,599
making the CPU do stuff anyway

1023
00:37:00,720 --> 00:37:05,339
um so that's that's lovely and you know

1024
00:37:03,599 --> 00:37:06,839
since then a lot of people that aren't

1025
00:37:05,339 --> 00:37:09,780
too familiar with this world kind of

1026
00:37:06,839 --> 00:37:11,820
think oh yeah that happened we're fine

1027
00:37:09,780 --> 00:37:13,440
um but speculative execution is a bug

1028
00:37:11,820 --> 00:37:14,940
class of itself and there's been new

1029
00:37:13,440 --> 00:37:17,940
vulnerabilities year after year since

1030
00:37:14,940 --> 00:37:20,280
then so you know both in software and in

1031
00:37:17,940 --> 00:37:21,540
Hardware new techniques to harden

1032
00:37:20,280 --> 00:37:24,240
against these kind of things have come

1033
00:37:21,540 --> 00:37:26,220
along and the amount of panic over this

1034
00:37:24,240 --> 00:37:27,900
specific case really led to a shift I

1035
00:37:26,220 --> 00:37:28,859
think in the overall mindset around

1036
00:37:27,900 --> 00:37:30,300
security

1037
00:37:28,859 --> 00:37:32,099
and I gave a talk at link security

1038
00:37:30,300 --> 00:37:34,619
Summit North America last year about

1039
00:37:32,099 --> 00:37:36,720
that if people are interested another

1040
00:37:34,619 --> 00:37:40,680
huge reason is is Android which I very

1041
00:37:36,720 --> 00:37:42,599
helpfully uh put a black font on a dark

1042
00:37:40,680 --> 00:37:45,660
background but we'll ignore that

1043
00:37:42,599 --> 00:37:48,000
um billions of android devices right

1044
00:37:45,660 --> 00:37:49,500
um Android devices run the Linux kernel

1045
00:37:48,000 --> 00:37:51,960
compromising the Linux kernel

1046
00:37:49,500 --> 00:37:53,160
compromises Android so a huge amount of

1047
00:37:51,960 --> 00:37:55,560
investment into these type of things

1048
00:37:53,160 --> 00:37:58,140
especially around tooling around things

1049
00:37:55,560 --> 00:37:59,099
like sanitizers around fuzzers has come

1050
00:37:58,140 --> 00:38:01,680
in

1051
00:37:59,099 --> 00:38:04,800
largely motivated by

1052
00:38:01,680 --> 00:38:06,119
the huge Target that Android is so the

1053
00:38:04,800 --> 00:38:07,740
amount of android devices has definitely

1054
00:38:06,119 --> 00:38:10,160
contributed to the overall security and

1055
00:38:07,740 --> 00:38:11,940
mindset of the kernel

1056
00:38:10,160 --> 00:38:13,680
syscoa which I don't really have time to

1057
00:38:11,940 --> 00:38:15,599
get into but Cisco is a assist called

1058
00:38:13,680 --> 00:38:18,480
fuzzer so

1059
00:38:15,599 --> 00:38:20,520
essentially it just does stuff it makes

1060
00:38:18,480 --> 00:38:21,780
the kernel do stuff and it finds when it

1061
00:38:20,520 --> 00:38:23,160
breaks stuff and it gives you a little

1062
00:38:21,780 --> 00:38:25,440
reproducer so you can break stuff

1063
00:38:23,160 --> 00:38:26,640
yourself now some people say Cisco is

1064
00:38:25,440 --> 00:38:28,320
the best thing ever look at all the bugs

1065
00:38:26,640 --> 00:38:30,480
that's finding we can fix them all other

1066
00:38:28,320 --> 00:38:31,859
people say security researchers can now

1067
00:38:30,480 --> 00:38:34,619
just checks his call or take something

1068
00:38:31,859 --> 00:38:36,900
and run with it which depending on your

1069
00:38:34,619 --> 00:38:38,339
mindset both are true but this is the

1070
00:38:36,900 --> 00:38:40,260
level of thing we could do now where we

1071
00:38:38,339 --> 00:38:41,820
have essentially automated finding bugs

1072
00:38:40,260 --> 00:38:42,660
in ways that we've never been able to do

1073
00:38:41,820 --> 00:38:45,240
before

1074
00:38:42,660 --> 00:38:47,339
so checkouts is cool it's cool

1075
00:38:45,240 --> 00:38:49,140
we have a lot more sanitizers

1076
00:38:47,339 --> 00:38:51,420
um sanitizers for for concurrency

1077
00:38:49,140 --> 00:38:53,099
undefined Behavior Etc

1078
00:38:51,420 --> 00:38:55,020
and rust

1079
00:38:53,099 --> 00:38:59,220
who raise your hand if you're on the the

1080
00:38:55,020 --> 00:39:02,400
rust uh hype train I am

1081
00:38:59,220 --> 00:39:04,079
so uh arrest in the colonel people have

1082
00:39:02,400 --> 00:39:06,119
pretty mixed opinions so just you know

1083
00:39:04,079 --> 00:39:07,740
first of all we can't what we probably

1084
00:39:06,119 --> 00:39:08,940
won't but we also can't rewrite the

1085
00:39:07,740 --> 00:39:10,619
whole kernel in it it's going to be a

1086
00:39:08,940 --> 00:39:12,660
steady trickle

1087
00:39:10,619 --> 00:39:15,480
um writing something in Ross does not in

1088
00:39:12,660 --> 00:39:18,720
fact uh make it 100 memory secure

1089
00:39:15,480 --> 00:39:20,280
especially in the context of a kernel so

1090
00:39:18,720 --> 00:39:21,599
riding stuff in Rust doesn't solve a lot

1091
00:39:20,280 --> 00:39:24,839
of problems but it does help minimize

1092
00:39:21,599 --> 00:39:27,480
them a lot it won't actually do that

1093
00:39:24,839 --> 00:39:30,180
um but it is good and it will help

1094
00:39:27,480 --> 00:39:31,740
um so right now there are several actual

1095
00:39:30,180 --> 00:39:33,599
device

1096
00:39:31,740 --> 00:39:35,640
um drivers being written in Rust most

1097
00:39:33,599 --> 00:39:36,839
notably probably is the GPU for Apple

1098
00:39:35,640 --> 00:39:39,480
silicon

1099
00:39:36,839 --> 00:39:41,280
but we will gradually have more rust and

1100
00:39:39,480 --> 00:39:43,760
it will gradually help

1101
00:39:41,280 --> 00:39:46,440
anyway that's the end of History so

1102
00:39:43,760 --> 00:39:47,820
thanks for history thanks for consuming

1103
00:39:46,440 --> 00:39:51,980
history hopefully I didn't miss any

1104
00:39:47,820 --> 00:39:51,980
history and that's it thank you

1105
00:39:55,130 --> 00:39:59,460
[Applause]

1106
00:39:57,540 --> 00:40:03,560
we've got time for a couple of questions

1107
00:39:59,460 --> 00:40:03,560
quick ones that are actually questions

1108
00:40:08,839 --> 00:40:12,839
uh yes

1109
00:40:12,920 --> 00:40:18,599
oh yes sorry um was power hit hard by

1110
00:40:17,160 --> 00:40:21,660
Specter and meltdown

1111
00:40:18,599 --> 00:40:24,900
um was uh Power was vulnerable yes not

1112
00:40:21,660 --> 00:40:27,900
to the same degree as Intel in

1113
00:40:24,900 --> 00:40:30,780
particular but yeah pretty much every I

1114
00:40:27,900 --> 00:40:34,160
think every CPU architecture was hit to

1115
00:40:30,780 --> 00:40:34,160
some degree yeah so

1116
00:40:38,040 --> 00:40:42,420
absolutely

1117
00:40:39,900 --> 00:40:44,640
and uh we've got a little gift here for

1118
00:40:42,420 --> 00:40:47,099
you from the organizers in the hackers

1119
00:40:44,640 --> 00:40:48,839
space great there's a little speaker's

1120
00:40:47,099 --> 00:40:50,130
good for you awesome thank you very much

1121
00:40:48,839 --> 00:40:53,649
Russell

1122
00:40:50,130 --> 00:40:53,649
[Applause]