1
00:00:00,000 --> 00:00:02,959
Welcome.

2
00:00:02,959 --> 00:00:05,999
This is Java every day exploiting

3
00:00:05,999 --> 00:00:08,501
It's an honor to be speaking to you

4
00:00:08,501 --> 00:00:09,834
I'm been coming to this for a decade.

5
00:00:09,834 --> 00:00:12,834
And first time speaking and I'm happy

6
00:00:12,834 --> 00:00:16,999
By the looks of you, many

7
00:00:22,834 --> 00:00:25,834
Hope you enjoy this tour

8
00:00:26,083 --> 00:00:27,999
And you walk away

9
00:00:27,999 --> 00:00:31,083
of vulnerabilities that affect Java

10
00:00:31,083 --> 00:00:32,626
Zero Day.

11
00:00:33,459 --> 00:00:36,542
The first thing we're going to do

12
00:00:36,626 --> 00:00:38,667
Actually provided to us by the U.S.

13
00:00:38,667 --> 00:00:39,667
government.

14
00:00:39,667 --> 00:00:42,083
Unless it's absolutely necessary

15
00:00:42,083 --> 00:00:45,125
disable it as described

16
00:00:45,125 --> 00:00:50,042
will help mitigate other vulnerabilities

17
00:00:50,999 --> 00:00:56,834
This came from an advisory

18
00:00:56,834 --> 00:00:58,125
So the U.S.

19
00:00:58,125 --> 00:00:58,999
government

20
00:00:58,999 --> 00:01:02,083
the latest version of the software,

21
00:01:02,083 --> 00:01:04,083
for a piece of software.

22
00:01:06,167 --> 00:01:07,999
But as you know, nobody

23
00:01:07,999 --> 00:01:09,709
to follow what the U.S.

24
00:01:09,709 --> 00:01:10,167
government is going

25
00:01:10,167 --> 00:01:12,083
to do this presentation.

26
00:01:13,417 --> 00:01:15,083
So for the agenda.

27
00:01:15,167 --> 00:01:18,250
We're going to take a tour

28
00:01:18,250 --> 00:01:20,999
to describe

29
00:01:20,999 --> 00:01:24,417
exist and we're going to go

30
00:01:24,417 --> 00:01:26,667
in the Java framework.

31
00:01:26,751 --> 00:01:29,792
Provide you Of concepts

32
00:01:29,792 --> 00:01:32,999
and we released them last week.

33
00:01:32,999 --> 00:01:34,876
They've been passed there

34
00:01:34,876 --> 00:01:37,959
in the Zero Day Initiative program

35
00:01:37,959 --> 00:01:40,792
of the classic vulnerability of Java.

36
00:01:41,292 --> 00:01:44,999
We're going to take that and look

37
00:01:44,999 --> 00:01:49,999
in landscape and look at what Oracle

38
00:01:52,959 --> 00:01:55,209
I'm Brian Gorenc.

39
00:01:55,209 --> 00:01:56,751
I work for Hewlett Packard.

40
00:01:56,751 --> 00:01:58,083
I run the Zero Day Initiative program,

41
00:01:58,083 --> 00:02:01,542
is the world's largest bug bounty

42
00:02:02,834 --> 00:02:06,999
So, if you have bugs and you want

43
00:02:06,999 --> 00:02:10,999
I also run the Pwn2Own hacking

44
00:02:12,999 --> 00:02:16,417
I'm a family man, have two kids

45
00:02:16,417 --> 00:02:18,501
And, when I'm not spending time

46
00:02:18,501 --> 00:02:21,167
at assembly code looking for bugs.

47
00:02:21,167 --> 00:02:26,209
JASIEL SPELMAN: I'm Jasiel

48
00:02:26,292 --> 00:02:28,999
I report to Brian.

49
00:02:29,250 --> 00:02:31,709
I spent a lot of time looking at IDA

50
00:02:31,709 --> 00:02:34,876
the cases that get submitted to ZDI.

51
00:02:35,167 --> 00:02:38,125
I'm known as wandering glitch

52
00:02:38,125 --> 00:02:40,999
and also behind the ZDI account.

53
00:02:47,083 --> 00:02:49,999
So why did we choose Java to look at?

54
00:02:49,999 --> 00:02:52,751
It had what we wanted to get

55
00:02:52,751 --> 00:02:55,999
of the attack surface itself

56
00:02:55,999 --> 00:02:58,626
of submissions

57
00:02:58,626 --> 00:03:03,542
at the time industry razz focused

58
00:03:03,542 --> 00:03:06,375
We wanted to look independently

59
00:03:06,375 --> 00:03:09,209
if that was actually the case.

60
00:03:09,209 --> 00:03:11,459
We wanted to determine what

61
00:03:11,459 --> 00:03:13,959
was, which part

62
00:03:13,959 --> 00:03:16,083
the subcomponents

63
00:03:16,083 --> 00:03:18,375
the most vulnerabilities and which one

64
00:03:18,375 --> 00:03:20,999
the most severe vulnerabilities.

65
00:03:21,209 --> 00:03:24,792
Tying that with what's being used

66
00:03:24,792 --> 00:03:28,501
whether the CDSS scoring system was

67
00:03:28,501 --> 00:03:30,792
and we wanted to take

68
00:03:30,792 --> 00:03:33,501
at Oracle's response

69
00:03:33,501 --> 00:03:36,083
discoveries in their product.

70
00:03:36,999 --> 00:03:39,918
So let's talk

71
00:03:39,918 --> 00:03:41,999
for this analysis.

72
00:03:41,999 --> 00:03:45,167
We scoped ourselves

73
00:03:45,167 --> 00:03:49,375
every issue passed between 2011

74
00:03:49,375 --> 00:03:54,501
We performed a root cause analysis

75
00:03:54,501 --> 00:03:56,083
These are probably

76
00:03:56,083 --> 00:03:58,626
of Java vulnerabilities

77
00:03:58,626 --> 00:04:00,876
or other nation states.

78
00:04:00,999 --> 00:04:05,876
We have the entire Zero Day Initiative

79
00:04:05,876 --> 00:04:10,250
all the big name penetration testing

80
00:04:10,250 --> 00:04:15,667
that we've submitted to Oracle

81
00:04:15,834 --> 00:04:19,167
So this is actually trending

82
00:04:19,751 --> 00:04:22,250
When we looked

83
00:04:22,250 --> 00:04:25,083
with reversing labs and

84
00:04:25,083 --> 00:04:28,999
of 52,000 Java malware samples so we

85
00:04:28,999 --> 00:04:31,125
used out there today.

86
00:04:32,459 --> 00:04:35,959
If we look at the footprint of Java,

87
00:04:35,959 --> 00:04:38,876
and that's what makes it

88
00:04:38,876 --> 00:04:41,375
they actually boast about it,

89
00:04:41,375 --> 00:04:45,417
during the installation process,

90
00:04:45,626 --> 00:04:48,959
According to Oracle,

91
00:04:48,959 --> 00:04:51,999
itself and somebody produces 1.4 Java

92
00:04:51,999 --> 00:04:56,250
I have no idea what a Java card is,

93
00:04:56,250 --> 00:05:01,792
and if it's running any part of Java,

94
00:05:02,751 --> 00:05:05,667
The other interesting thing

95
00:05:05,667 --> 00:05:08,626
for their base language

96
00:05:08,626 --> 00:05:11,083
have thousands and thousands

97
00:05:11,083 --> 00:05:14,375
out every year and they're core

98
00:05:14,375 --> 00:05:16,501
there's been

99
00:05:16,501 --> 00:05:19,125
of Java in the marketplace,

100
00:05:19,125 --> 00:05:21,125
in the mobile space.

101
00:05:21,125 --> 00:05:23,626
So it's a really good target for attackers.

102
00:05:24,501 --> 00:05:27,999
If you look at the architecture itself,

103
00:05:27,999 --> 00:05:30,083
There's over 50 subcomponents

104
00:05:30,083 --> 00:05:32,959
on in this presentation, what

105
00:05:32,959 --> 00:05:36,083
of this architecture and we'll cover

106
00:05:36,083 --> 00:05:38,459
up later in the presentation.

107
00:05:38,501 --> 00:05:39,999
The employment subcomponent

108
00:05:39,999 --> 00:05:43,999
of the Java web star capabilities

109
00:05:46,125 --> 00:05:49,999
Java is differing rich applications.

110
00:05:49,999 --> 00:05:54,125
Java 2D produces 2D graphics

111
00:05:54,125 --> 00:05:58,626
and UTIL components provide

112
00:05:58,626 --> 00:06:03,542
for almost every application that's

113
00:06:03,792 --> 00:06:06,999
So there is wide range

114
00:06:06,999 --> 00:06:11,834
to quickly implement tasks

115
00:06:11,999 --> 00:06:14,626
Write once, run everywhere.

116
00:06:14,999 --> 00:06:17,792
Let's look

117
00:06:18,125 --> 00:06:21,876
What you're seeing here

118
00:06:21,876 --> 00:06:24,417
from their patch releases.

119
00:06:24,542 --> 00:06:28,959
They've actually patched year

120
00:06:28,959 --> 00:06:33,667
year with 50 vulnerabilities being

121
00:06:33,667 --> 00:06:38,999
in 2011 with over 130 remotely exploit

122
00:06:38,999 --> 00:06:42,626
There's been a huge increase

123
00:06:42,999 --> 00:06:46,459
When they release a patch,

124
00:06:46,459 --> 00:06:49,250
of metadata and what you see

125
00:06:49,250 --> 00:06:53,626
is Java's SE risk matrix and it

126
00:06:53,626 --> 00:06:56,083
and people deploying

127
00:06:56,083 --> 00:06:59,834
they should know

128
00:06:59,834 --> 00:07:02,209
is a 2D vulnerability.

129
00:07:06,417 --> 00:07:08,667
It is remotely CDD score

130
00:07:08,667 --> 00:07:11,459
is the most severe vulnerability so

131
00:07:11,459 --> 00:07:14,626
of information there we can look

132
00:07:14,626 --> 00:07:17,083
to determine what

133
00:07:17,083 --> 00:07:19,417
of the architecture is.

134
00:07:19,709 --> 00:07:22,542
The most interesting thing

135
00:07:22,542 --> 00:07:26,751
they score CVSS is they assume

136
00:07:26,751 --> 00:07:31,250
and applets are running

137
00:07:31,250 --> 00:07:33,334
So they're giving themselves

138
00:07:33,334 --> 00:07:36,751
on CVSS than most vendors probably

139
00:07:39,167 --> 00:07:42,542
If we take a look just

140
00:07:42,542 --> 00:07:44,999
from the patches,

141
00:07:44,999 --> 00:07:46,999
to determine

142
00:07:46,999 --> 00:07:50,125
for the most vulnerable components

143
00:07:50,125 --> 00:07:52,709
the 5 you see

144
00:07:52,709 --> 00:07:55,083
for the 2011 through 2013.

145
00:07:58,292 --> 00:08:01,751
Deployment being number one,

146
00:08:01,751 --> 00:08:04,584
by libraries, Java FX and AWT.

147
00:08:04,959 --> 00:08:09,083
But, if you look at the rankings,

148
00:08:09,083 --> 00:08:12,834
is producing vulnerabilities

149
00:08:12,834 --> 00:08:15,334
on average that

150
00:08:15,334 --> 00:08:17,751
in the architecture.

151
00:08:17,751 --> 00:08:20,834
Other interesting statistics it

152
00:08:20,834 --> 00:08:23,542
that have been patched

153
00:08:23,542 --> 00:08:27,584
in the last 2 1/2 years,

154
00:08:27,999 --> 00:08:32,918
At one point there was two components

155
00:08:32,999 --> 00:08:38,626
The deployment had 10 vulnerabilities

156
00:08:38,626 --> 00:08:41,250
in February of 2013.

157
00:08:43,250 --> 00:08:45,792
If we tie that

158
00:08:45,792 --> 00:08:48,250
we start to see interesting stuff.

159
00:08:48,626 --> 00:08:51,792
We see that on average,

160
00:08:51,792 --> 00:08:54,999
is receiving

161
00:08:54,999 --> 00:08:57,584
with a high of 33

162
00:08:57,584 --> 00:09:01,209
to Ben Murphy and Vitali

163
00:09:01,209 --> 00:09:04,209
to our program in one quarter.

164
00:09:04,792 --> 00:09:07,999
Our researchers actually account

165
00:09:07,999 --> 00:09:13,375
with CVSS score 9 or higher, that's

166
00:09:13,375 --> 00:09:16,792
On average our researchers are scoring

167
00:09:16,792 --> 00:09:21,083
on severe vulnerabilities

168
00:09:21,083 --> 00:09:22,667
We can look at it two ways.

169
00:09:22,999 --> 00:09:26,334
Either they're focusing

170
00:09:26,334 --> 00:09:30,959
vulnerabilities or what they're focusing

171
00:09:30,959 --> 00:09:33,375
you start looking at them.

172
00:09:33,375 --> 00:09:34,999
Depends on perspective.

173
00:09:36,999 --> 00:09:39,501
So we took

174
00:09:39,501 --> 00:09:42,999
and performed a root cause analysis

175
00:09:42,999 --> 00:09:45,751
into the blue boxes up here.

176
00:09:45,792 --> 00:09:48,999
And the first one is privilege

177
00:09:48,999 --> 00:09:52,083
Followed by buffer overflows,

178
00:09:52,083 --> 00:09:54,626
on buffer operations,

179
00:09:54,626 --> 00:09:58,083
integer overflow and a bunch

180
00:09:58,918 --> 00:10:02,999
And what we found out was that

181
00:10:02,999 --> 00:10:07,000
the most popular vulnerability

182
00:10:07,000 --> 00:10:09,626
by buffer over flows.

183
00:10:09,626 --> 00:10:11,626
But we can take

184
00:10:11,626 --> 00:10:14,250
at it those specific issues

185
00:10:14,250 --> 00:10:17,501
out into even further subcategories.

186
00:10:17,542 --> 00:10:19,999
So we broke them

187
00:10:19,999 --> 00:10:22,959
is the abuse of the reflection APIs

188
00:10:22,959 --> 00:10:26,417
to restricted components

189
00:10:26,501 --> 00:10:30,000
Another subcategory was least

190
00:10:30,000 --> 00:10:32,918
is the abuse

191
00:10:32,918 --> 00:10:36,000
to execute code

192
00:10:36,000 --> 00:10:40,375
confusion which are vulnerabilities

193
00:10:40,375 --> 00:10:44,209
either through the use

194
00:10:44,209 --> 00:10:46,959
data or other techniques.

195
00:10:46,959 --> 00:10:50,876
We have the classic key based buffer

196
00:10:50,876 --> 00:10:54,167
and various other process control

197
00:10:55,125 --> 00:10:58,959
But the key takeaway for this

198
00:10:58,959 --> 00:11:02,999
from every major class of bug that's

199
00:11:02,999 --> 00:11:07,459
a really good case study

200
00:11:09,667 --> 00:11:10,876
(Laughter.

201
00:11:10,876 --> 00:11:14,250
So we take a look specifically

202
00:11:14,250 --> 00:11:17,459
Those accounted for half

203
00:11:17,459 --> 00:11:18,626
If you look at the pie chart,

204
00:11:18,626 --> 00:11:21,125
the unsafe reflection vulnerability

205
00:11:21,125 --> 00:11:24,125
of those and then followed

206
00:11:24,125 --> 00:11:26,334
accounted for a quarter.

207
00:11:26,626 --> 00:11:29,709
The interesting thing about these

208
00:11:29,709 --> 00:11:32,667
in the exploited community

209
00:11:32,667 --> 00:11:35,375
to bypass any OS mitigations.

210
00:11:35,375 --> 00:11:36,375
They just work.

211
00:11:36,375 --> 00:11:37,999
You don't have to bypass that.

212
00:11:37,999 --> 00:11:41,083
You don't have to bypass ASOR,

213
00:11:41,083 --> 00:11:43,542
Every time you click on it,

214
00:11:43,542 --> 00:11:44,542
Quite good.

215
00:11:44,959 --> 00:11:47,751
If you look

216
00:11:47,751 --> 00:11:52,999
what you're seeing is the blue box,

217
00:11:52,999 --> 00:11:57,292
the submissions

218
00:11:57,292 --> 00:12:00,250
for sandbox bypass issues.

219
00:12:00,250 --> 00:12:05,417
So we've been receiving these

220
00:12:05,417 --> 00:12:08,626
So Oracle has actually known

221
00:12:09,167 --> 00:12:11,999
If we look specifically

222
00:12:11,999 --> 00:12:15,959
vulnerabilities, out of bounds rights

223
00:12:15,959 --> 00:12:18,792
there's really two causes

224
00:12:18,792 --> 00:12:23,083
in those two classes so we could

225
00:12:23,083 --> 00:12:25,459
We found out that a third

226
00:12:25,459 --> 00:12:28,167
by integer overflows causing

227
00:12:28,167 --> 00:12:30,751
of a smaller than intended buffer

228
00:12:30,751 --> 00:12:34,751
the rest were incorrect arithmetic

229
00:12:34,876 --> 00:12:36,918
So it's interesting

230
00:12:36,918 --> 00:12:41,250
of memory corruption issues and

231
00:12:42,459 --> 00:12:46,292
So taking all this information,

232
00:12:46,292 --> 00:12:49,375
all the information from the ZDI,

233
00:12:49,375 --> 00:12:52,459
the top 7 vulnerability classes

234
00:12:52,459 --> 00:12:55,834
the unsafe reflection vulnerability which

235
00:12:55,834 --> 00:12:59,083
in the library subcomponent followed

236
00:12:59,083 --> 00:13:02,125
is also most popular

237
00:13:02,125 --> 00:13:05,999
by two classic memory corruption

238
00:13:05,999 --> 00:13:08,834
most of these ended

239
00:13:08,834 --> 00:13:13,083
would keep key based buffer overflows

240
00:13:13,501 --> 00:13:15,626
Untrusted pointer dereference which

241
00:13:15,626 --> 00:13:17,918
and Javascript framework.

242
00:13:17,918 --> 00:13:19,792
I don't know why they exist but they do.

243
00:13:19,792 --> 00:13:23,083
And they're quite funny when

244
00:13:23,083 --> 00:13:28,999
by we have key based buffer overflows

245
00:13:28,999 --> 00:13:31,375
confusion issues.

246
00:13:32,999 --> 00:13:35,626
But to make it even more interesting,

247
00:13:35,626 --> 00:13:38,999
all of that information on top

248
00:13:38,999 --> 00:13:41,125
understand what type

249
00:13:41,125 --> 00:13:45,626
in which subcomponents and this

250
00:13:45,626 --> 00:13:48,999
This is one the first times there's been

251
00:13:48,999 --> 00:13:51,999
for you to start looking for them.

252
00:13:52,584 --> 00:13:54,999
What you see

253
00:13:54,999 --> 00:13:59,250
the packages that had vulnerable code

254
00:13:59,250 --> 00:14:03,375
of vulnerabilities that existed

255
00:14:03,375 --> 00:14:08,083
from memory code issues

256
00:14:08,459 --> 00:14:11,334
Deployment suffered

257
00:14:11,334 --> 00:14:14,667
and process control problems and

258
00:14:14,667 --> 00:14:18,667
on the slide here were sandbox bypass

259
00:14:19,999 --> 00:14:22,999
The rest of the subcomponents

260
00:14:22,999 --> 00:14:26,083
the Java FX component which was

261
00:14:26,083 --> 00:14:29,751
of untrusted pointer dereferences

262
00:14:29,751 --> 00:14:31,918
studies,

263
00:14:31,918 --> 00:14:34,626
suffered from sandbox issues

264
00:14:34,626 --> 00:14:37,209
is something because it suffers

265
00:14:37,209 --> 00:14:39,959
and memory corruption issues.

266
00:14:39,999 --> 00:14:42,334
So that's the sound component.

267
00:14:42,459 --> 00:14:45,417
But this is really valuable

268
00:14:45,417 --> 00:14:47,417
because it's

269
00:14:47,417 --> 00:14:49,999
to go bug hunting and look for stuff

270
00:14:49,999 --> 00:14:53,459
hopefully submit them

271
00:14:53,459 --> 00:14:55,876
But the basically, you're able to take

272
00:14:55,876 --> 00:14:59,083
at the 2d component and you know that

273
00:14:59,083 --> 00:15:03,459
for key based buffer overflows

274
00:15:03,626 --> 00:15:06,834
It's also useful when a patch comes

275
00:15:06,834 --> 00:15:09,918
to scope what you need to look

276
00:15:09,918 --> 00:15:14,709
they give you which component they're

277
00:15:16,417 --> 00:15:18,584
Now what we're going to do

278
00:15:18,584 --> 00:15:20,999
of case studies

279
00:15:20,999 --> 00:15:23,083
we talked about in the slides.

280
00:15:23,626 --> 00:15:27,999
We're going to do two case studies

281
00:15:29,250 --> 00:15:33,250
Two different memory corruption

282
00:15:33,250 --> 00:15:38,459
and untrusted Java FX component

283
00:15:38,459 --> 00:15:41,876
So you know, this is probably one

284
00:15:41,876 --> 00:15:43,999
been shown publicly.

285
00:15:47,292 --> 00:15:49,959
All right, so the first bug we're going

286
00:15:49,959 --> 00:15:53,501
over is in the    JASIEL SPELMAN: So

287
00:15:53,501 --> 00:15:56,751
over is library subcomponent

288
00:15:56,751 --> 00:15:59,250
on what unsafe reflection is,

289
00:15:59,250 --> 00:16:02,959
a dispatch method that takes

290
00:16:02,959 --> 00:16:04,626
of arguments.

291
00:16:05,375 --> 00:16:08,417
We'll look up the function

292
00:16:08,417 --> 00:16:11,250
If you pass add it will look

293
00:16:11,250 --> 00:16:12,959
invoke it.

294
00:16:12,999 --> 00:16:14,667
Unsafe reflection

295
00:16:14,667 --> 00:16:16,918
validation

296
00:16:16,918 --> 00:16:19,999
the delete everything method

297
00:16:19,999 --> 00:16:24,584
In CVE2436,

298
00:16:24,584 --> 00:16:30,083
exploration issues 5034 you could

299
00:16:30,083 --> 00:16:35,584
issue 5 fore makes use

300
00:16:35,584 --> 00:16:40,167
to get protected method

301
00:16:40,167 --> 00:16:42,918
a instance of it.

302
00:16:43,125 --> 00:16:46,501
It requires the use

303
00:16:46,501 --> 00:16:49,167
usually the use of framework such

304
00:16:49,167 --> 00:16:53,167
if you really wanted you could hard

305
00:16:53,751 --> 00:16:56,167
After you've done that,

306
00:16:56,167 --> 00:16:59,292
to on the class litter and that

307
00:16:59,292 --> 00:17:03,417
to the class litter such that you could

308
00:17:03,417 --> 00:17:06,250
Once you've done that all you have

309
00:17:06,250 --> 00:17:10,999
a permission domain that contains

310
00:17:10,999 --> 00:17:15,209
to load a class and disable

311
00:17:15,209 --> 00:17:18,876
You do that either through the use

312
00:17:18,876 --> 00:17:21,626
or within a method in that class.

313
00:17:21,626 --> 00:17:23,501
And I'll go into that in this slide.

314
00:17:24,167 --> 00:17:28,709
So here you can see invoked dynamic

315
00:17:28,709 --> 00:17:33,999
and get class handle would be

316
00:17:34,334 --> 00:17:36,999
All that will do is make the call

317
00:17:36,999 --> 00:17:40,999
the set define class method handle here

318
00:17:40,999 --> 00:17:43,542
in this case it will be

319
00:17:43,542 --> 00:17:46,167
to the define class method.

320
00:17:46,501 --> 00:17:48,876
We save it

321
00:17:48,876 --> 00:17:51,999
variable so we can access it later on.

322
00:17:52,250 --> 00:17:55,667
Once we've done that we create

323
00:17:55,667 --> 00:17:58,918
all permission

324
00:17:58,918 --> 00:18:00,918
based off that.

325
00:18:00,918 --> 00:18:03,459
Once we've done that, we get access

326
00:18:03,459 --> 00:18:06,292
the method handle to our class loader.

327
00:18:06,292 --> 00:18:09,167
That the point we can invoke

328
00:18:09,167 --> 00:18:13,292
and load a malicious class that

329
00:18:13,292 --> 00:18:16,876
the sandbox or the security manager.

330
00:18:18,999 --> 00:18:23,417
This was patched

331
00:18:23,417 --> 00:18:28,375
of convert method

332
00:18:28,417 --> 00:18:31,999
The main takeaway is there's

333
00:18:31,999 --> 00:18:35,918
if the parameter class is not

334
00:18:35,918 --> 00:18:39,334
the given object to the given class.

335
00:18:39,334 --> 00:18:42,999
We can see in the previous version that

336
00:18:42,999 --> 00:18:45,250
And as a result,

337
00:18:45,250 --> 00:18:47,834
in a class cast exception.

338
00:18:48,999 --> 00:18:52,250
The next weakness is also

339
00:18:52,250 --> 00:18:56,125
is a privilege and sandbox issue due

340
00:18:56,125 --> 00:18:58,999
that exists

341
00:18:58,999 --> 00:19:00,959
privilege blocks.

342
00:19:00,959 --> 00:19:03,834
It takes two arguments or

343
00:19:03,834 --> 00:19:07,167
arguments the first of which

344
00:19:07,167 --> 00:19:10,459
or otherwise that exposes

345
00:19:10,501 --> 00:19:13,125
This run method will get run

346
00:19:13,125 --> 00:19:15,626
than you're currently within.

347
00:19:15,626 --> 00:19:17,999
The second optional argument

348
00:19:17,999 --> 00:19:21,250
and that's a save state

349
00:19:21,250 --> 00:19:23,083
running within.

350
00:19:23,083 --> 00:19:24,876
When you're running

351
00:19:24,876 --> 00:19:27,959
to have a much lower privilege level

352
00:19:27,959 --> 00:19:29,876
do whatever it wanted.

353
00:19:30,459 --> 00:19:33,999
Ben Murphy found

354
00:19:33,999 --> 00:19:37,999
instance does not save

355
00:19:37,999 --> 00:19:41,876
and as a result it will use the libraries.

356
00:19:41,999 --> 00:19:44,999
Unfortunately, it requires

357
00:19:44,999 --> 00:19:47,959
to execute an arbitrary statement.

358
00:19:47,959 --> 00:19:49,999
He then found that method handle

359
00:19:49,999 --> 00:19:53,501
as interface instance that can do

360
00:19:53,501 --> 00:19:57,167
And using this, you can access

361
00:19:57,167 --> 00:19:59,417
And load a malicious class.

362
00:19:59,417 --> 00:20:01,876
You still have one hurdled

363
00:20:01,876 --> 00:20:03,834
to be able

364
00:20:03,834 --> 00:20:08,250
without putting any user frames

365
00:20:08,667 --> 00:20:12,999
So here we can see a little snippet

366
00:20:12,999 --> 00:20:14,751
You'd start off by deciding

367
00:20:14,751 --> 00:20:18,999
an instance method you want

368
00:20:18,999 --> 00:20:20,999
And you would instantiate it.

369
00:20:20,999 --> 00:20:23,375
You then create a method type

370
00:20:23,375 --> 00:20:27,834
off the instance methods return value

371
00:20:27,834 --> 00:20:30,999
the classes for primers it takes.

372
00:20:30,999 --> 00:20:33,584
You then use the find virtual method

373
00:20:33,584 --> 00:20:36,250
off the desired class, the name

374
00:20:36,250 --> 00:20:39,000
the method type you just created.

375
00:20:39,834 --> 00:20:43,042
You bind it to the you bind

376
00:20:43,042 --> 00:20:47,167
to the desired class and then you run

377
00:20:47,167 --> 00:20:50,501
which

378
00:20:50,834 --> 00:20:54,125
When the method handle

379
00:20:54,125 --> 00:20:58,459
the first three method argument

380
00:20:58,459 --> 00:21:03,542
be dropped and not sent

381
00:21:04,083 --> 00:21:07,999
At this point you create your invocation

382
00:21:07,999 --> 00:21:11,959
of method handles dot

383
00:21:11,959 --> 00:21:16,417
to he create the proxy

384
00:21:16,417 --> 00:21:19,584
And you'll have to do that

385
00:21:19,584 --> 00:21:21,667
but that is doable.

386
00:21:21,667 --> 00:21:24,876
We haven't added it

387
00:21:24,876 --> 00:21:27,834
what the actual exploit is.

388
00:21:27,834 --> 00:21:29,999
So this was patched in three classes.

389
00:21:29,999 --> 00:21:31,292
First class

390
00:21:31,292 --> 00:21:34,999
and that was patched first

391
00:21:34,999 --> 00:21:38,709
makes use

392
00:21:38,709 --> 00:21:41,999
The main takeaway from this

393
00:21:41,999 --> 00:21:45,999
to be returned here which means when

394
00:21:45,999 --> 00:21:49,334
below and find virtual,

395
00:21:49,334 --> 00:21:50,999
null there.

396
00:21:51,959 --> 00:21:54,709
In method handle proxies you have

397
00:21:54,709 --> 00:21:57,751
as interface instance method which

398
00:21:57,751 --> 00:22:00,959
of the maybe bind caller function.

399
00:22:01,250 --> 00:22:04,584
And in the maybe bind caller,

400
00:22:04,584 --> 00:22:07,959
if the parameter class is null or

401
00:22:07,959 --> 00:22:11,501
is class libr null which means it's library

402
00:22:11,501 --> 00:22:14,292
without any modification of it.

403
00:22:14,999 --> 00:22:17,792
If that's not the case

404
00:22:17,792 --> 00:22:22,125
the bind caller method The last class

405
00:22:22,125 --> 00:22:25,501
of this patch

406
00:22:25,501 --> 00:22:29,584
class and specifically

407
00:22:29,584 --> 00:22:31,375
The main takeaway here is that

408
00:22:31,375 --> 00:22:34,459
if it's null just throw an internal error.

409
00:22:34,542 --> 00:22:38,999
Previous to this, you would try

410
00:22:39,792 --> 00:22:41,999
That said,

411
00:22:41,999 --> 00:22:44,584
because we would die

412
00:22:44,584 --> 00:22:46,667
the eMethod handle.

413
00:22:49,167 --> 00:22:50,876
And okay.

414
00:22:50,876 --> 00:22:51,876
All right.

415
00:22:51,876 --> 00:22:53,999
So the next bug

416
00:22:53,999 --> 00:22:59,250
is a key based buffer overflow due

417
00:22:59,250 --> 00:23:03,334
to us and exists in native C code.

418
00:23:03,667 --> 00:23:07,999
Java has what's called Java native

419
00:23:07,999 --> 00:23:10,999
to be called from Java land.

420
00:23:10,999 --> 00:23:16,167
In this particular case the issue lies

421
00:23:16,167 --> 00:23:21,375
the issue lies because of well,

422
00:23:21,584 --> 00:23:23,999
You have four arguments that are

423
00:23:23,999 --> 00:23:26,999
and which image creates the first

424
00:23:26,999 --> 00:23:30,501
a type specifier that's used

425
00:23:30,999 --> 00:23:33,083
You have three arguments.

426
00:23:33,083 --> 00:23:36,417
Channel within height which

427
00:23:36,417 --> 00:23:39,667
for a signed 32 bit integer.

428
00:23:41,584 --> 00:23:45,375
So there are some bounds placed

429
00:23:45,375 --> 00:23:49,459
and height must be greater than 1

430
00:23:49,459 --> 00:23:52,125
greater than 1 and less than 4.

431
00:23:52,125 --> 00:23:56,459
But once that's done, if the mlib type

432
00:23:56,459 --> 00:24:01,375
and channels by 4 sorry, width

433
00:24:01,375 --> 00:24:05,125
and later on multiply that by height.

434
00:24:05,125 --> 00:24:08,501
So height times width times channels

435
00:24:08,501 --> 00:24:14,459
to the 32nd power we'll send a value

436
00:24:14,459 --> 00:24:17,999
As a result when we start writing

437
00:24:20,876 --> 00:24:25,125
All right, this was patched

438
00:24:25,125 --> 00:24:28,709
of the safe to mult macro and

439
00:24:28,709 --> 00:24:33,626
of this macro time they did any sort

440
00:24:34,083 --> 00:24:38,626
They're making use of the macro and

441
00:24:38,626 --> 00:24:43,083
they'll actually do the multiplication

442
00:24:43,083 --> 00:24:46,501
Here we can see that we're making use

443
00:24:46,501 --> 00:24:49,999
and checking it against WB and 4

444
00:24:49,999 --> 00:24:53,292
will we multiply WB by 4 same goes

445
00:24:53,292 --> 00:24:56,083
before passing it to malloc.

446
00:24:57,417 --> 00:25:00,417
So the next vulnerability

447
00:25:00,417 --> 00:25:04,083
is out of bounds right due

448
00:25:04,626 --> 00:25:11,209
It was reported by Vitali and it exists

449
00:25:11,209 --> 00:25:14,167
Specifically in sun AWT image rep.

450
00:25:14,209 --> 00:25:17,209
It's accessible via sun image,

451
00:25:17,209 --> 00:25:19,542
the issue lies

452
00:25:19,542 --> 00:25:23,375
is an integer component object which

453
00:25:23,375 --> 00:25:26,751
is used

454
00:25:27,167 --> 00:25:31,792
So we're we can see a snippet

455
00:25:31,792 --> 00:25:35,792
is the vulnerable function

456
00:25:35,792 --> 00:25:38,834
is the image component raster.

457
00:25:39,083 --> 00:25:42,542
Here is where we're getting access

458
00:25:42,542 --> 00:25:45,417
and we're now setting destination

459
00:25:45,417 --> 00:25:47,626
you can see that

460
00:25:47,626 --> 00:25:49,876
is being set based

461
00:25:49,876 --> 00:25:51,959
the scan line field.

462
00:25:51,999 --> 00:25:54,083
We have an outer

463
00:25:54,083 --> 00:25:58,709
the source pointer and destination

464
00:25:58,709 --> 00:26:03,083
and scan line stride and this

465
00:26:03,083 --> 00:26:05,999
to prevent integer overflow.

466
00:26:06,375 --> 00:26:08,999
We then update the source

467
00:26:08,999 --> 00:26:12,417
actually going to be writing

468
00:26:12,417 --> 00:26:16,083
destination pointer

469
00:26:16,083 --> 00:26:19,083
Finally we actually have the right to it.

470
00:26:19,501 --> 00:26:22,417
So this was patched

471
00:26:22,417 --> 00:26:26,083
of three macros, check stride,

472
00:26:26,083 --> 00:26:29,999
and Oracle did proper patch

473
00:26:33,959 --> 00:26:36,667
So here are

474
00:26:36,667 --> 00:26:40,417
And you can see that they're checking

475
00:26:40,417 --> 00:26:43,999
by actually doing the calculations.

476
00:26:44,167 --> 00:26:47,999
If one occurs, they'll false

477
00:26:47,999 --> 00:26:50,999
Same goes for check source

478
00:26:51,292 --> 00:26:54,999
Here you can see that X and W

479
00:26:54,999 --> 00:26:58,334
validated and you can see that

480
00:26:58,334 --> 00:27:03,918
is also being checked just this

481
00:27:04,709 --> 00:27:08,501
Here you can see the use

482
00:27:09,501 --> 00:27:12,334
The blast vulnerability

483
00:27:12,334 --> 00:27:15,083
is an untrusted corner D reference

484
00:27:15,083 --> 00:27:17,459
is his favorite bug in Java.

485
00:27:17,709 --> 00:27:22,125
Reported by Vitali and this particular

486
00:27:22,125 --> 00:27:25,999
in the com sun web page class.

487
00:27:25,999 --> 00:27:28,626
The issues lies

488
00:27:28,626 --> 00:27:31,999
functions that are executed

489
00:27:31,999 --> 00:27:36,125
and one of them will allocate a buffer

490
00:27:36,125 --> 00:27:37,999
to Java land.

491
00:27:37,999 --> 00:27:40,999
This is stored

492
00:27:41,292 --> 00:27:43,999
There is a public get page accessor

493
00:27:43,999 --> 00:27:47,584
of the methods within the web class

494
00:27:47,584 --> 00:27:51,125
the P page variable whereas, others

495
00:27:51,125 --> 00:27:54,167
of the get page accessor method.

496
00:27:54,459 --> 00:27:57,959
As a result we can subclass

497
00:27:57,959 --> 00:28:00,834
and achieve memory corruption.

498
00:28:00,999 --> 00:28:05,417
So here we can see that the class

499
00:28:05,417 --> 00:28:07,167
subclass it.

500
00:28:07,209 --> 00:28:09,584
Here we can see that

501
00:28:09,584 --> 00:28:13,542
is also public which also means we can

502
00:28:13,542 --> 00:28:17,999
And here is one of the native functions,

503
00:28:17,999 --> 00:28:21,667
It's private but above it we can see that

504
00:28:21,667 --> 00:28:24,709
is public so we can actually call it.

505
00:28:24,709 --> 00:28:27,999
And within it we see a call

506
00:28:27,999 --> 00:28:32,792
get page, the value returned

507
00:28:33,209 --> 00:28:36,375
So this was patched

508
00:28:36,375 --> 00:28:38,999
We actually got a slew

509
00:28:38,999 --> 00:28:43,209
all at the same time and

510
00:28:43,209 --> 00:28:49,667
of make the hurting stop reaction just

511
00:28:49,999 --> 00:28:53,375
Any attempt to access that package

512
00:28:53,375 --> 00:28:57,459
in a package access exception error.

513
00:28:57,584 --> 00:29:02,626
There's a package restriction list

514
00:29:02,999 --> 00:29:05,334
Brian will go into that a little later.

515
00:29:05,626 --> 00:29:09,459
Then properly patches

516
00:29:09,459 --> 00:29:13,626
the get page package private and final.

517
00:29:14,083 --> 00:29:17,292
And with that, I'm going

518
00:29:17,292 --> 00:29:20,292
he can go over to Pwn 2 own

519
00:29:20,292 --> 00:29:24,083
in the threat landscape    BRIAN

520
00:29:24,083 --> 00:29:28,250
to look to see how people are using

521
00:29:28,709 --> 00:29:31,542
This year when we access

522
00:29:31,542 --> 00:29:34,999
the scope of the competition

523
00:29:34,999 --> 00:29:38,083
into it mostly

524
00:29:38,083 --> 00:29:43,083
by malware and we added flash reader

525
00:29:43,083 --> 00:29:49,292
of course Java when we did that people

526
00:29:50,459 --> 00:29:54,209
ZDI is giving out $20,000 for free.

527
00:29:54,584 --> 00:29:56,999
At the time it felt like that

528
00:29:56,999 --> 00:30:00,167
of Zero Day activity going

529
00:30:00,167 --> 00:30:02,334
going

530
00:30:02,334 --> 00:30:05,083
to highlight the browser plug ins.

531
00:30:06,709 --> 00:30:10,083
0 you are expectation was

532
00:30:10,083 --> 00:30:14,999
due to unsafe reflection

533
00:30:14,999 --> 00:30:16,918
They actually brought

534
00:30:16,918 --> 00:30:18,626
affecting Java.

535
00:30:19,083 --> 00:30:21,876
If we look at the actual participants.

536
00:30:21,876 --> 00:30:24,042
James fore Shaw brought

537
00:30:24,042 --> 00:30:27,834
Josh Drake brought and

538
00:30:28,375 --> 00:30:32,959
Luke brought overflow and Ben Murphy

539
00:30:33,083 --> 00:30:36,626
It's interesting to see that

540
00:30:36,626 --> 00:30:40,709
leveraged and used to win money

541
00:30:41,667 --> 00:30:45,667
The one of my favorite quotes when we

542
00:30:45,667 --> 00:30:47,292
in security.

543
00:30:47,292 --> 00:30:50,417
We asked them to bring us

544
00:30:50,417 --> 00:30:52,959
and Chuckie says of course

545
00:30:52,959 --> 00:30:55,999
to bring you something interesting.

546
00:30:55,999 --> 00:30:58,417
So they brought

547
00:30:59,125 --> 00:31:04,125
Looking at the landscape itself,

548
00:31:04,792 --> 00:31:09,083
This is depicting

549
00:31:11,542 --> 00:31:15,334
You see a huge increase

550
00:31:15,876 --> 00:31:17,501
The recent months.

551
00:31:17,876 --> 00:31:20,751
The this actually mirrors

552
00:31:20,751 --> 00:31:22,918
going on at the time.

553
00:31:22,918 --> 00:31:24,876
That's just an interesting data point.

554
00:31:24,999 --> 00:31:26,709
People are looking at Java.

555
00:31:26,709 --> 00:31:28,792
It is a popular application to audit.

556
00:31:28,834 --> 00:31:33,250
If you're a developer, you're required

557
00:31:33,250 --> 00:31:36,375
just to stay competitive

558
00:31:36,375 --> 00:31:38,167
on the market.

559
00:31:38,626 --> 00:31:41,709
There's quite a competitive market

560
00:31:41,999 --> 00:31:44,292
Attackers are upping their game.

561
00:31:44,459 --> 00:31:46,834
One of the interesting things

562
00:31:46,834 --> 00:31:49,209
is it shows vulnerabilities in 2011,

563
00:31:49,209 --> 00:31:52,375
in 2011 are still actively being used

564
00:31:52,375 --> 00:31:56,834
because the installation process

565
00:31:57,959 --> 00:32:02,125
There's been several studies that have

566
00:32:02,125 --> 00:32:05,918
of the install base hasn't updated

567
00:32:05,918 --> 00:32:09,209
after release and sometimes

568
00:32:09,626 --> 00:32:13,999
The fact is that multiple major versions

569
00:32:13,999 --> 00:32:19,083
at one time and as a result,

570
00:32:20,375 --> 00:32:23,083
So we wanted to look

571
00:32:23,083 --> 00:32:26,792
compared to what's actually

572
00:32:26,792 --> 00:32:28,999
And what we see

573
00:32:28,999 --> 00:32:32,834
the most common bug to be utilized

574
00:32:32,834 --> 00:32:36,375
of the sample set being

575
00:32:37,250 --> 00:32:39,542
What you see

576
00:32:39,542 --> 00:32:42,167
a quarter followed

577
00:32:42,167 --> 00:32:44,417
and three

578
00:32:44,417 --> 00:32:48,834
for almost 90% of the actual activity

579
00:32:48,999 --> 00:32:53,501
Memory corruption issues do end

580
00:32:53,501 --> 00:32:57,999
and so there's more focus in reality

581
00:32:57,999 --> 00:33:01,999
because you don't have

582
00:33:04,125 --> 00:33:06,876
Now we're going to go

583
00:33:06,876 --> 00:33:10,083
and one that's not as common

584
00:33:10,250 --> 00:33:13,083
JASIEL SPELMAN: All right.

585
00:33:13,083 --> 00:33:14,999
So the main goal

586
00:33:14,999 --> 00:33:18,292
with sandbox bypass asks

587
00:33:18,292 --> 00:33:20,999
and pass null as the argument.

588
00:33:20,999 --> 00:33:24,626
This was the effect

589
00:33:24,626 --> 00:33:28,167
means you can run anything you want.

590
00:33:28,501 --> 00:33:31,959
With memory corruption you have

591
00:33:31,959 --> 00:33:35,709
as overwriting

592
00:33:35,709 --> 00:33:39,626
is a technique given to us

593
00:33:39,626 --> 00:33:42,876
of Java being statement class.

594
00:33:44,918 --> 00:33:48,999
So Java being statement represents

595
00:33:48,999 --> 00:33:54,083
of the form instance variable.instance

596
00:33:54,167 --> 00:33:56,334
What you can potentially do

597
00:33:56,334 --> 00:34:00,250
an out of bounds rate and

598
00:34:00,250 --> 00:34:04,209
buffer that's vulnerable

599
00:34:04,292 --> 00:34:07,083
A statement has implicitly created

600
00:34:07,083 --> 00:34:10,709
is clearly going to be weaker

601
00:34:10,709 --> 00:34:12,999
in your untrusted applet.

602
00:34:13,250 --> 00:34:15,999
You then create

603
00:34:15,999 --> 00:34:20,918
by creating a permissions object,

604
00:34:20,918 --> 00:34:22,584
Then you create

605
00:34:22,584 --> 00:34:26,792
out of that and create access control

606
00:34:26,999 --> 00:34:30,999
You then use your memory corruption

607
00:34:30,999 --> 00:34:33,999
the statements,

608
00:34:33,999 --> 00:34:37,667
and then you can just execute

609
00:34:37,667 --> 00:34:39,959
with more privileges.

610
00:34:40,375 --> 00:34:43,250
Now going to go through a piece

611
00:34:43,250 --> 00:34:46,083
use of a sapped box bypass

612
00:34:50,876 --> 00:34:53,876
Makes use

613
00:34:53,876 --> 00:34:56,959
to instantiate

614
00:34:56,959 --> 00:35:00,999
and then it uses object manager factory

615
00:35:00,999 --> 00:35:04,999
to the load class protected methods

616
00:35:04,999 --> 00:35:08,999
the it then invokes that class

617
00:35:08,999 --> 00:35:14,999
on a malicious class that implements

618
00:35:15,083 --> 00:35:17,999
And once it's done that it then nullifies

619
00:35:17,999 --> 00:35:19,584
at stage 2.

620
00:35:21,083 --> 00:35:23,999
So here we see that

621
00:35:23,999 --> 00:35:27,292
the Java version and checking to see

622
00:35:27,292 --> 00:35:30,417
So, if it's not JDK7, it's just going

623
00:35:30,959 --> 00:35:33,999
If it is, it then grabs

624
00:35:33,999 --> 00:35:38,125
exception action and turns it

625
00:35:38,375 --> 00:35:40,834
We then make use

626
00:35:40,834 --> 00:35:43,083
to instantiate

627
00:35:43,083 --> 00:35:46,209
and we then get access

628
00:35:46,209 --> 00:35:49,792
using manager objected

629
00:35:50,083 --> 00:35:53,667
That the point we invoke

630
00:35:53,667 --> 00:35:57,292
class and we then call method within it.

631
00:35:57,292 --> 00:35:59,999
And forgot to mention

632
00:35:59,999 --> 00:36:01,918
very clear and easy

633
00:36:01,918 --> 00:36:04,584
because we've deobfuscated it.

634
00:36:04,584 --> 00:36:07,959
This particular piece

635
00:36:07,959 --> 00:36:14,083
but did not use advanced methods

636
00:36:14,417 --> 00:36:19,375
We were able to use normal compiler

637
00:36:19,999 --> 00:36:23,375
So continuing on, we call

638
00:36:23,375 --> 00:36:26,125
and give it two arguments.

639
00:36:26,125 --> 00:36:28,584
The class we just loaded and basically

640
00:36:28,584 --> 00:36:32,250
by the HTML that served this piece

641
00:36:33,626 --> 00:36:40,626
Within the malicious class we start

642
00:36:47,083 --> 00:36:48,626
Sorry about that.

643
00:36:48,709 --> 00:36:50,626
So we first take our string

644
00:36:50,626 --> 00:36:51,999
by the characters H and J.

645
00:36:51,999 --> 00:36:54,999
Then we turn that

646
00:36:54,999 --> 00:36:56,375
later on.

647
00:36:56,876 --> 00:36:59,083
We then get access

648
00:36:59,083 --> 00:37:01,083
and instantiate it.

649
00:37:01,209 --> 00:37:04,999
And pass it

650
00:37:04,999 --> 00:37:06,999
At this point we end

651
00:37:06,999 --> 00:37:10,999
the first thing we do is make a call

652
00:37:10,999 --> 00:37:14,209
block and we pass this as the variable.

653
00:37:14,459 --> 00:37:18,083
This has the effect of because we're

654
00:37:18,083 --> 00:37:22,209
exception actions this has the effect

655
00:37:22,209 --> 00:37:24,999
nullifies the security manager.

656
00:37:24,999 --> 00:37:28,209
At this point everything after this

657
00:37:28,209 --> 00:37:30,250
fully taken place.

658
00:37:30,375 --> 00:37:34,501
So now we make now we call our stage

659
00:37:34,876 --> 00:37:38,667
And the first thing we do is grab

660
00:37:38,667 --> 00:37:42,999
to the URL that we were given

661
00:37:42,999 --> 00:37:47,083
in our app data directories called Java

662
00:37:47,667 --> 00:37:50,083
We then go through and download

663
00:37:50,083 --> 00:37:53,167
into that download the file

664
00:37:53,167 --> 00:37:56,709
into the Java IO tempter file

665
00:37:56,709 --> 00:38:00,250
as an executable and falling that,

666
00:38:00,250 --> 00:38:04,375
as a DLL At this point I'm going

667
00:38:04,375 --> 00:38:06,918
he can go

668
00:38:06,918 --> 00:38:08,709
with all this.

669
00:38:08,709 --> 00:38:10,999
BRIAN GORENC: All right.

670
00:38:10,999 --> 00:38:12,083
So we kind of have

671
00:38:12,083 --> 00:38:13,999
and how

672
00:38:13,999 --> 00:38:16,417
because we handle so many of them.

673
00:38:16,417 --> 00:38:18,999
We've done over 200 just this year.

674
00:38:18,999 --> 00:38:22,083
Zero Day's patched

675
00:38:22,709 --> 00:38:24,999
In the case of Oracle,

676
00:38:24,999 --> 00:38:27,999
about three months to turn

677
00:38:27,999 --> 00:38:30,209
puts them in the middle of the pack

678
00:38:30,209 --> 00:38:32,125
but in reality what's going

679
00:38:32,125 --> 00:38:35,209
is they've decreased their turnaround

680
00:38:35,209 --> 00:38:38,334
the vulnerability submissions have

681
00:38:38,334 --> 00:38:42,083
So it's actually quite a feat when

682
00:38:42,083 --> 00:38:46,667
in 2013 you patched over 130

683
00:38:46,667 --> 00:38:48,834
turnaround time.

684
00:38:48,834 --> 00:38:50,626
To from an external perspective,

685
00:38:50,626 --> 00:38:53,083
over their patch organization

686
00:38:53,083 --> 00:38:54,999
being discovered.

687
00:38:55,417 --> 00:38:58,083
They're increased patch cycle.

688
00:38:58,083 --> 00:38:59,999
They release four times

689
00:38:59,999 --> 00:39:01,709
are discovered.

690
00:39:01,709 --> 00:39:04,667
They've made public commitments

691
00:39:04,667 --> 00:39:08,542
of time to get a patch when Zero Day

692
00:39:10,584 --> 00:39:12,667
They're aggressively adjusting their

693
00:39:12,667 --> 00:39:14,999
for Java which we'll go over next.

694
00:39:14,999 --> 00:39:17,542
They killed several

695
00:39:17,542 --> 00:39:21,751
in this perspective means we

696
00:39:21,751 --> 00:39:22,667
We verify that it works and

697
00:39:22,667 --> 00:39:24,999
a patch and killed the bug.

698
00:39:25,125 --> 00:39:29,501
So in U13 they killed 3 and in U15

699
00:39:29,501 --> 00:39:32,292
And this is due

700
00:39:32,292 --> 00:39:35,834
and also a tightening

701
00:39:35,834 --> 00:39:37,876
violation bugs.

702
00:39:37,918 --> 00:39:40,459
What you see on the screen

703
00:39:40,459 --> 00:39:44,999
to the attack surface that they've made

704
00:39:44,999 --> 00:39:46,125
We've base lined it in U9.

705
00:39:46,250 --> 00:39:51,501
They had about 12 packages

706
00:39:51,501 --> 00:39:54,834
And you see in U10 and U11

707
00:39:54,834 --> 00:39:57,999
in U13 they added another dozen

708
00:39:57,999 --> 00:40:01,459
to the restriction list and one

709
00:40:01,459 --> 00:40:06,125
the sun package that we went

710
00:40:06,250 --> 00:40:09,918
They're actually adding those

711
00:40:09,918 --> 00:40:12,709
And trying to tighten

712
00:40:12,709 --> 00:40:15,167
In U15, you see that

713
00:40:15,167 --> 00:40:17,292
is kind of strange.

714
00:40:17,292 --> 00:40:19,834
But what they're actually doing

715
00:40:19,834 --> 00:40:22,250
and adding higher level packages.

716
00:40:22,250 --> 00:40:26,167
So you see that it's com, sun,

717
00:40:26,167 --> 00:40:31,792
and they're further tightening

718
00:40:31,792 --> 00:40:34,792
an applet can get to.

719
00:40:34,792 --> 00:40:35,999
In U21 they made a lot

720
00:40:35,999 --> 00:40:38,999
with the same sort of thing,

721
00:40:38,999 --> 00:40:40,999
and add more packages.

722
00:40:41,083 --> 00:40:43,083
The interesting thing for everybody

723
00:40:43,083 --> 00:40:46,042
is those are where you want

724
00:40:46,042 --> 00:40:48,999
if you're doing one day patch analysis

725
00:40:48,999 --> 00:40:53,751
because there's vulnerabilities that

726
00:40:53,751 --> 00:40:55,417
So you can take this and

727
00:40:55,417 --> 00:40:58,959
and you can understand and reduce

728
00:40:58,959 --> 00:41:01,501
to look for bugs in the program.

729
00:41:01,999 --> 00:41:03,834
In Java itself.

730
00:41:03,999 --> 00:41:06,626
And you can see that they're changing

731
00:41:06,626 --> 00:41:10,167
So what you see on the screen

732
00:41:10,167 --> 00:41:11,999
for JDK7U25.

733
00:41:12,375 --> 00:41:14,999
There's 43 packages

734
00:41:14,999 --> 00:41:17,167
is quite a change than U9.

735
00:41:17,999 --> 00:41:22,167
You see a lot of com, sun,

736
00:41:22,167 --> 00:41:26,876
they'll remove those and add

737
00:41:27,999 --> 00:41:32,209
So in conclusion Oracle has weathered

738
00:41:32,209 --> 00:41:34,667
three years, they've had

739
00:41:34,667 --> 00:41:38,501
of vulnerability discoveries

740
00:41:38,501 --> 00:41:43,334
we've had 50+ Zero Day submissions

741
00:41:43,667 --> 00:41:47,083
Attackers are leveraging them

742
00:41:47,083 --> 00:41:49,751
against Facebook and Apple.

743
00:41:50,083 --> 00:41:51,999
And you've seen some

744
00:41:51,999 --> 00:41:53,167
to date.

745
00:41:53,375 --> 00:41:56,501
Everybody's focusing

746
00:41:56,751 --> 00:41:59,584
With unsafe reflection being

747
00:41:59,584 --> 00:42:02,667
in the architecture followed

748
00:42:02,667 --> 00:42:07,375
the most properly used vulnerability,

749
00:42:07,542 --> 00:42:10,751
The 2d component produces

750
00:42:10,751 --> 00:42:11,999
But it's not used.

751
00:42:12,167 --> 00:42:16,125
When they come out with 2d

752
00:42:16,125 --> 00:42:20,751
in reality as important

753
00:42:20,751 --> 00:42:24,292
usually garners around 8.7 or 7.6.

754
00:42:26,125 --> 00:42:29,417
We talked about thousand

755
00:42:29,417 --> 00:42:34,375
and increased patching so they're

756
00:42:34,459 --> 00:42:37,542
We want to thank everybody

757
00:42:37,542 --> 00:42:40,918
to thank the researchers who submitted

758
00:42:40,918 --> 00:42:43,667
over the last three years,

759
00:42:43,667 --> 00:42:47,459
and you'd like to sell it and make some

760
00:42:47,459 --> 00:42:48,999
to do that.

761
00:42:48,999 --> 00:42:50,751
You can submit it

762
00:42:50,751 --> 00:42:53,834
you and handle

763
00:42:54,083 --> 00:42:55,999
We also want

764
00:42:55,999 --> 00:42:58,999
and security explorations

765
00:42:58,999 --> 00:43:01,626
to help us validate some

766
00:43:01,626 --> 00:43:03,999
on in the paper development.

767
00:43:04,417 --> 00:43:06,083
So thanks for attending.

768
00:43:06,083 --> 00:43:06,709
Good luck bud hunting and we'll be

769
00:43:06,709 --> 00:43:08,999
out round to answer questions

770
00:43:08,999 --> 00:43:10,999
has additional vulnerabilities.

771
00:43:10,999 --> 00:43:13,083
Depends