1
00:00:00,099 --> 00:00:16,600
<i>Music</i>
Herald: The next talk is about how risky

2
00:00:16,600 --> 00:00:23,210
is software you use. So you may be heard
about Trump versus a Russian security

3
00:00:23,210 --> 00:00:30,949
company. We won't judge this, we won't
comment this, but we dislike the

4
00:00:30,949 --> 00:00:36,590
prejudgments of this case. Tim Carstens
and Parker Thompson will tell you a little

5
00:00:36,590 --> 00:00:43,300
bit more about how risky the software is
you use. Tim Carstens is CITL's Acting

6
00:00:43,300 --> 00:00:48,350
Director and Parker Thompson is CITL's
lead engineer. Please welcome with a very,

7
00:00:48,350 --> 00:00:53,879
very warm applause: Tim and Parker!
Thanks.

8
00:00:53,879 --> 00:01:05,409
<i>Applause</i>
Tim Carstens: Howdy, howdy. So my name is

9
00:01:05,409 --> 00:01:13,010
Tim Carstens. I'm the acting director of
the cyber independent testing lab. It's

10
00:01:13,010 --> 00:01:19,039
four words there, we'll talk about all for
today, especially cyber. With me today as

11
00:01:19,039 --> 00:01:25,760
our lead engineer Parker Thompson. Not on
stage or our other collaborators: Patrick

12
00:01:25,760 --> 00:01:32,929
Stach, Sarah Zatko, and present in the
room but not on stage - Mudge. So today

13
00:01:32,929 --> 00:01:37,010
we're going to be talking about our work,
the lead in. The introduction that was

14
00:01:37,010 --> 00:01:40,289
given is phrased in terms of Kaspersky and
all of that, I'm not gonna be speaking

15
00:01:40,289 --> 00:01:45,370
about Kaspersky and I guarantee you I'm
not gonna be speaking about my president.

16
00:01:45,370 --> 00:01:50,010
Right, yeah? Okay. Thank you.
<i>Applause</i>

17
00:01:50,010 --> 00:01:55,289
All right, so why don't we go ahead and
kick off: I'll mention now parts of this

18
00:01:55,289 --> 00:02:00,539
presentation are going to be quite
technical. Not most of it, and I will

19
00:02:00,539 --> 00:02:04,030
always include analogies and all these
other things if you are here in security

20
00:02:04,030 --> 00:02:10,530
but not a bit-twiddler. But if you do want
to be able to review some of the technical

21
00:02:10,530 --> 00:02:14,810
material, if I go through it too fast you
like to read if you're a mathematician or

22
00:02:14,810 --> 00:02:20,510
if you are a computer scientist, our sides
are already available for download at this

23
00:02:20,510 --> 00:02:25,400
site here. We think our pal our partners
at power door for getting that set up for

24
00:02:25,400 --> 00:02:31,630
us. Let's let's get started on the real
material here. Alright, so we are CITL: a

25
00:02:31,630 --> 00:02:35,770
nonprofit organization based in the United
States founded by our chief scientist

26
00:02:35,770 --> 00:02:43,020
Sarah Zatko and our board chair Mudge. And
our mission is a public good mission - we

27
00:02:43,020 --> 00:02:47,400
are hackers but our mission here is
actually to look out for people who do not

28
00:02:47,400 --> 00:02:50,460
know very much about machines
or as much as the other hackers do.

29
00:02:50,460 --> 00:02:56,030
Specifically, we seek to improve the state
of software security by providing the

30
00:02:56,030 --> 00:03:01,340
public with accurate reporting on the
security of popular software, right? And

31
00:03:01,340 --> 00:03:05,520
so there was a mouthful for you. But no
doubt, no doubt, every single one of you

32
00:03:05,520 --> 00:03:10,700
has received questions of the form: what
do I run on my phone, what do I do with

33
00:03:10,700 --> 00:03:13,950
this, what do I do with that, how do I
protect myself - all these other things

34
00:03:13,950 --> 00:03:19,770
lots of people in the general public
looking for agency in computing. No one's

35
00:03:19,770 --> 00:03:25,000
offering it to them, and so we're trying
to go ahead and provide a forcing function

36
00:03:25,000 --> 00:03:29,980
on the software field in order to, you
know, again be able to enable consumers

37
00:03:29,980 --> 00:03:36,480
and users and all these things. Our social
good work is funded largely by charitable

38
00:03:36,480 --> 00:03:40,820
monies from the Ford Foundation whom we
thank a great deal, but we also have major

39
00:03:40,820 --> 00:03:44,920
partnerships with Consumer Reports, which
is a major organization in the United

40
00:03:44,920 --> 00:03:51,620
States that generally, broadly, looks at
consumer goods for safety and performance.

41
00:03:51,620 --> 00:03:55,690
But also partners with The Digital
Standard, which probably would be of great

42
00:03:55,690 --> 00:03:59,460
interest to many people here at Congress
as it is a holistic standard for

43
00:03:59,460 --> 00:04:04,340
protecting user rights. We'll talk about
some of the work that goes into those

44
00:04:04,340 --> 00:04:10,250
things here in a bit, but first I want to
give the big picture of what it is we're

45
00:04:10,250 --> 00:04:17,940
really trying to do in one one short
little sentence. Something like this but

46
00:04:17,940 --> 00:04:23,710
for security, right? What are the
important facts, how does it rate, you

47
00:04:23,710 --> 00:04:26,810
know, is it easy to consume, is it easy to
go ahead and look and say this thing is

48
00:04:26,810 --> 00:04:31,300
good this thing is not good. Something
like this, but for software security.

49
00:04:33,120 --> 00:04:39,190
Sounds hard doesn't it? So I want to talk
a little bit about what I mean by

50
00:04:39,190 --> 00:04:44,870
something like this.
There are lots of consumer outlook and

51
00:04:44,870 --> 00:04:50,270
watchdog and protection groups - some
private, some government, which are

52
00:04:50,270 --> 00:04:54,820
looking to do this for various things that
are not a software security. And you can

53
00:04:54,820 --> 00:04:58,210
see some examples here that are big in the
United States - I happen to not like these

54
00:04:58,210 --> 00:05:02,120
as much as some of the newer consumer
labels coming out from the EU. But

55
00:05:02,120 --> 00:05:05,080
nonetheless they are examples of the kinds
of things people have done in other

56
00:05:05,080 --> 00:05:10,870
fields, fields that are not security to
try to achieve that same end. And when

57
00:05:10,870 --> 00:05:17,410
these things work well, it is for three
reasons: One, it has to contain the

58
00:05:17,410 --> 00:05:22,960
relevant information. Two: it has to be
based in fact, we're not talking opinions,

59
00:05:22,960 --> 00:05:28,800
this is not a book club or something like
that. And three: it has to be actionable,

60
00:05:28,800 --> 00:05:32,520
it has to be actionable - you have to be
able to know how to make a decision based

61
00:05:32,520 --> 00:05:36,370
on it. How do you do that for software
security? How <i>do</i> you do that for

62
00:05:36,370 --> 00:05:43,760
software security? So the rest of the talk
is going to go in three parts.

63
00:05:43,760 --> 00:05:49,450
First, we're going to give a bit of an
overview for more of the consumer facing

64
00:05:49,450 --> 00:05:52,820
side of things for that we do: look at
some data that we have reported on early

65
00:05:52,820 --> 00:05:57,260
and all these other kinds of good things.
We're then going to go ahead and get

66
00:05:57,940 --> 00:06:06,011
terrifyingly, terrifyingly technical. And
then after that we'll talk about tools to

67
00:06:06,011 --> 00:06:09,560
actually implement all this stuff. The
technical part comes before the tools. So

68
00:06:09,560 --> 00:06:12,170
it just tells you how terrifyingly
technical we're gonna get. It's gonna be

69
00:06:12,170 --> 00:06:19,680
fun right. So how do you do this for
software security: a consumer version. So,

70
00:06:19,680 --> 00:06:25,010
if you set forth to the task of trying to
measure software security, right, many

71
00:06:25,010 --> 00:06:27,680
people here probably do work in the
security field perhaps as consultants

72
00:06:27,680 --> 00:06:32,281
doing reviews; certainly I used to. Then
probably what you're thinking to yourself

73
00:06:32,281 --> 00:06:38,650
right now is that there are lots and lots
and lots and lots of things that affect

74
00:06:38,650 --> 00:06:44,150
the security of a piece of software. Some
of which are, mmm, you're only gonna see

75
00:06:44,150 --> 00:06:47,640
them if you go reversing. And some of
which are just you know kicking around on

76
00:06:47,640 --> 00:06:51,580
the ground waiting for you to notice,
right. So we're going to talk about both

77
00:06:51,580 --> 00:06:55,919
of those kinds of things that you might
measure. But here you see these giant

78
00:06:55,919 --> 00:07:03,380
charts that basically go through on the
left - on the left we have Microsoft Excel

79
00:07:03,380 --> 00:07:08,310
on OS X on the right Google Chrome for OS
X this is a couple years old at this point

80
00:07:08,310 --> 00:07:12,850
maybe one and a half years old but over
here I'm not expecting you to be able to

81
00:07:12,850 --> 00:07:16,250
read these - the real point is to say look
at all of the different things you can

82
00:07:16,250 --> 00:07:20,490
measure very easily.
How do you distill, it how do you boil it

83
00:07:20,490 --> 00:07:26,770
down, right. So this is a the opposite of
a good consumer safety label. This is just

84
00:07:26,770 --> 00:07:29,780
um if you ever done any consulting this is
the kind of report you hand a client to

85
00:07:29,780 --> 00:07:32,870
tell them how good their software is,
right? It's the opposite of consumer

86
00:07:32,870 --> 00:07:39,800
grade. But the reason I'm showing it here
is because, you know, I'm gonna call out

87
00:07:39,800 --> 00:07:42,650
some things and maybe you can't process
all of this because it's too much

88
00:07:42,650 --> 00:07:46,911
material, you know. But I'm gonna call it
some things and once I call them out just

89
00:07:46,911 --> 00:07:52,949
like NP you're gonna recognize them
instantly. So for example, Excel, at the

90
00:07:52,949 --> 00:07:56,820
time of this review - look at this column
of dots. What's this dots telling you?

91
00:07:56,820 --> 00:07:59,990
It's telling you look at all these
libraries -all of them are 32-bit only.

92
00:07:59,990 --> 00:08:07,180
Not 64 bits, not 64 bits. Take a look at
Chrome - exact opposite, exact opposite

93
00:08:07,180 --> 00:08:14,021
64-bit binary, right? What are some other
things? Excel, again, on OSX maybe you can

94
00:08:14,021 --> 00:08:19,550
see these danger warning signs that go
straight straight up the whole thing.

95
00:08:19,550 --> 00:08:27,520
That's the the absence of major heat
protection flags in the binary headers.

96
00:08:27,520 --> 00:08:31,919
We'll talk about some what that means
exactly in a bit. But also if you hop over

97
00:08:31,919 --> 00:08:35,639
here you'll see like yeah yeah yeah like
Chrome has all the different heat

98
00:08:35,639 --> 00:08:41,578
protections that a binary might enable, on
OSX that is, but it also has more dots in

99
00:08:41,578 --> 00:08:44,649
this column here off to the right. And
what do those dots represent?

100
00:08:44,649 --> 00:08:52,050
Those dots represent functions, functions
that historically have been the source of

101
00:08:52,050 --> 00:08:54,460
you know if you call these functions are
very hard to call correctly - if you're a

102
00:08:54,460 --> 00:08:59,029
C programmer the "gets" function is a good
example. But there are lots of them. And

103
00:08:59,029 --> 00:09:03,279
you can see here the Chrome doesn't mind,
it uses them all a bunch. And Excel not so

104
00:09:03,279 --> 00:09:08,360
much. And if you know the history of
Microsoft and the trusted computing

105
00:09:08,360 --> 00:09:12,379
initiative and the SDO and all of that you
will know that a very long time ago

106
00:09:12,379 --> 00:09:17,180
Microsoft made the decision and they said
we're gonna start purging some of these

107
00:09:17,180 --> 00:09:22,009
risky functions from our code bases
because we think it's easier to ban them

108
00:09:22,009 --> 00:09:24,990
than teach our devs to use them correctly.
And you see that reverberating out in

109
00:09:24,990 --> 00:09:28,980
their software. Google on the other hand
says yeah yeah yeah those functions can be

110
00:09:28,980 --> 00:09:31,920
dangerous to use but if you know how to
use them they can be very good and so

111
00:09:31,920 --> 00:09:38,959
they're permitted. The point all of this
is building to is that if you start by

112
00:09:38,959 --> 00:09:42,540
just measuring every little thing that
like your static analyzers can detect in a

113
00:09:42,540 --> 00:09:47,760
piece of software. Two things: one, you
wind up with way more data than you can

114
00:09:47,760 --> 00:09:55,269
show in a slide. And two: the engineering
process, the software development life

115
00:09:55,269 --> 00:09:59,779
cycle that went into the software will
leave behind artifacts that tell you

116
00:09:59,779 --> 00:10:05,170
something about the decisions that went
into designing that engineering process.

117
00:10:05,170 --> 00:10:10,179
And so you know, Google for example:
quite rigorous as far as hitting you know

118
00:10:10,179 --> 00:10:14,379
GCC dash, and then enable all of the
compiler protections. Microsoft may be

119
00:10:14,379 --> 00:10:19,949
less good at that, but much more rigid in
things that's were very popular ideas when

120
00:10:19,949 --> 00:10:24,199
they introduced trusted computing,
alright. So the big takeaway from this

121
00:10:24,199 --> 00:10:29,040
material is that again the software
engineering process results in artifacts

122
00:10:29,040 --> 00:10:35,610
in the software that people can find.
Alright. Ok, so that's that's a whole

123
00:10:35,610 --> 00:10:40,579
bunch of data, certainly it's not a
consumer-friendly label. So how do you

124
00:10:40,579 --> 00:10:45,899
start to get in towards the consumer zone?
Well, the main defect of the big reports

125
00:10:45,899 --> 00:10:51,240
that we just saw is that it's too much
information. It's a very dense on data but

126
00:10:51,240 --> 00:10:55,649
it's very hard to distill it to the "so
what" of it, right?

127
00:10:55,649 --> 00:11:00,470
And so this here is one of our earlier
attempts to go ahead and do that

128
00:11:00,470 --> 00:11:04,990
distillation. What are these charts how
did we come up with these? Well on the

129
00:11:04,990 --> 00:11:08,490
previous slide when we saw all these
different factors that you can analyze in

130
00:11:08,490 --> 00:11:14,189
software, basically here's whose views
that we arrive at this. For each of those

131
00:11:14,189 --> 00:11:18,639
things: pick a weight. Go ahead and
compute a score, average against the

132
00:11:18,639 --> 00:11:22,110
weight: tada, now you have some number.
You can do that for each of the libraries

133
00:11:22,110 --> 00:11:25,819
and the piece of software. And if you do
that for each of the libraries in the

134
00:11:25,819 --> 00:11:29,399
software you can then go ahead and produce
these histograms to show, you know, like

135
00:11:29,399 --> 00:11:35,619
this percentage of the DLLs had a score in
this range. Boom, there's a bar, right.

136
00:11:35,619 --> 00:11:39,269
How do you pick those weights? We'll talk
about that in a sec - it's very technical.

137
00:11:39,269 --> 00:11:45,339
But the the takeaway though, is you know
that you wind up with these charts. Now

138
00:11:45,339 --> 00:11:48,329
I've obscured the labels, I've obscured
the labels and the reason I've done that

139
00:11:48,329 --> 00:11:52,329
is because I don't really care that much
about the actual counts. I want to talk

140
00:11:52,329 --> 00:11:57,420
about the shapes, the shapes of these
charts: it's a qualitative thing.

141
00:11:57,420 --> 00:12:02,540
So here: good scores appear on the right,
bad scores appear on the left. The

142
00:12:02,540 --> 00:12:06,269
histogram measuring all the libraries and
components and so a very secure piece of

143
00:12:06,269 --> 00:12:12,879
software in this model manifests as a tall
bar far to the right. And you can see a

144
00:12:12,879 --> 00:12:17,910
clear example at in our custom Gentoo
build. Anyone here is a Gentoo fan knows -

145
00:12:17,910 --> 00:12:21,189
hey I'm going to install this thing, I
think I'm going to go ahead and turn on

146
00:12:21,189 --> 00:12:25,120
every single one of those flags, and lo
and behold if you do that yeah you wind up

147
00:12:25,120 --> 00:12:30,520
with tall bar far to the right. Here's in
Ubuntu 16, I bet it's 16.04 but I don't

148
00:12:30,520 --> 00:12:35,959
recall exactly, 16 LTS. Here you see a lot
of tall bars to the right - not quite as

149
00:12:35,959 --> 00:12:39,619
consolidated as a custom Gentoo build, but
that makes sense doesn't it right? Because

150
00:12:39,619 --> 00:12:44,769
then you know you don't do your whole
Ubuntu build. Now I want to contrast. I

151
00:12:44,769 --> 00:12:50,360
want to contrast. So over here on the
right we see in the same model, an

152
00:12:50,360 --> 00:12:55,929
analysis of the firmware obtained from two
smart televisions. Last year's models from

153
00:12:55,929 --> 00:12:59,920
Samsung and LG. And here the model
numbers. We did this work in concert with

154
00:12:59,920 --> 00:13:05,039
Consumer Reports. And what do you notice
about these histograms, right. Are the

155
00:13:05,039 --> 00:13:11,790
bars tall and to the right? No, they look
almost normal, not quite, but that doesn't

156
00:13:11,790 --> 00:13:16,619
really matter. The main thing that matters
is that this is the shape you would expect

157
00:13:16,619 --> 00:13:23,649
to get if you were playing a random game
basically to decide what security features

158
00:13:23,649 --> 00:13:27,879
to enable in your software. This is the
shape of not having a security program, is

159
00:13:27,879 --> 00:13:33,540
my bet. That's my bet. And so what do you
see? You see heavy concentration here in

160
00:13:33,540 --> 00:13:38,800
the middle, right, that seems fair, and
like it tails off. On the Samsung nothing

161
00:13:38,800 --> 00:13:43,549
scored all that great, same on the LG.
Both of them are you know running their

162
00:13:43,549 --> 00:13:46,639
respective operating systems and they're
basically just inheriting whatever

163
00:13:46,639 --> 00:13:51,249
security came from whatever open source
thing they forked, right.

164
00:13:51,249 --> 00:13:55,000
So this is this is the kind of message,
this right here is the kind of thing that

165
00:13:55,000 --> 00:14:01,929
we serve to exist for. This is us
producing charts showing that the current

166
00:14:01,929 --> 00:14:08,019
practices in the not-so consumer-friendly
space of running your own Linux distros

167
00:14:08,019 --> 00:14:13,290
far exceed the products being delivered,
certainly in this case in the smart TV

168
00:14:13,290 --> 00:14:24,941
market. But I think you might agree with
me, it's much worse than this. So let's

169
00:14:24,941 --> 00:14:28,319
dig into that a little bit more, I have a
different point that I want to make about

170
00:14:28,319 --> 00:14:33,959
that same data set - so this table here
this table is again looking at the LG

171
00:14:33,959 --> 00:14:39,769
Samsung and Gentoo Linux installations.
And on this table we're just pulling out

172
00:14:39,769 --> 00:14:43,839
some of the easy to identify security
features you might enable in a binary

173
00:14:43,839 --> 00:14:49,989
right. So percentage of binaries with
address space layout randomization, right?

174
00:14:49,989 --> 00:14:56,429
Let's talk about that on our Gentoo build
it's over 99%. That also holds for the

175
00:14:56,429 --> 00:15:02,699
Amazon Linux AMI - it holds in Ubuntu.
ASLR is incredibly common in modern Linux.

176
00:15:02,699 --> 00:15:09,290
And despite that, fewer than 70 percent of
the binaries on the LG television had it

177
00:15:09,290 --> 00:15:13,739
enabled. Fewer than 70 percent. And the
Samsung was doing, you know, better than

178
00:15:13,739 --> 00:15:19,780
that I guess, but 80 percent is a pretty
disappointing when a default Linux

179
00:15:19,780 --> 00:15:25,190
install, you know, mainstream Linux distro
is going to get you 99, right? And it only

180
00:15:25,190 --> 00:15:28,079
gets worse, it only gets worse right you
know?

181
00:15:28,079 --> 00:15:32,379
RELRO support, if you don't know what that
is that's ok but if you do, look abysmal

182
00:15:32,379 --> 00:15:37,809
coverage look at this abysmal coverage
coming out of these IOT devices very sad.

183
00:15:37,809 --> 00:15:40,749
And you see it over and over and over
again. I'm showing this because some

184
00:15:40,749 --> 00:15:46,339
people in this room or watching this video
ship software - and I have a message, I

185
00:15:46,339 --> 00:15:50,309
have a message to those people who ship
software who aren't working on say Chrome

186
00:15:50,309 --> 00:15:58,609
or any of the other big-name Pwn2Own kinds
of targets. Look at this: you can be

187
00:15:58,609 --> 00:16:02,480
leading the pack by mastering the
fundamentals. You can be leading the pack

188
00:16:02,480 --> 00:16:07,079
by mastering the fundamentals. This is a
point that really as a security field we

189
00:16:07,079 --> 00:16:11,179
really need to be driving home. You know,
one of the things that we're seeing here

190
00:16:11,179 --> 00:16:15,709
in our data is that if you're the vendor
who is shipping the product everyone has

191
00:16:15,709 --> 00:16:19,390
heard of in the security field and maybe
your game is pretty decent right? If

192
00:16:19,390 --> 00:16:23,599
you're shipping say Windows or if you're
shipping Firefox or whatever. But if

193
00:16:23,599 --> 00:16:26,149
you're if you're doing one of these things
where people are just kind of beating you

194
00:16:26,149 --> 00:16:30,619
up for default passwords, then your
problems are way further than just default

195
00:16:30,619 --> 00:16:35,399
passwords, right? Like the house, the
house is messy it needs to be cleaned,

196
00:16:35,399 --> 00:16:43,190
needs to be cleaned. So the rest of the
talk like I said we're going to be

197
00:16:43,190 --> 00:16:47,019
discussing a lot of other things that
amount to getting you know a peek behind

198
00:16:47,019 --> 00:16:50,689
the curtain and where some of these things
come from and getting very specific about

199
00:16:50,689 --> 00:16:54,420
how this business works, but if you're
interested in more of the high level

200
00:16:54,420 --> 00:16:58,980
material - especially if you're interested
in interesting results and insights, some

201
00:16:58,980 --> 00:17:01,949
of which I'm going to have here later. But
I really encourage you though to take a

202
00:17:01,949 --> 00:17:06,750
look at the talk from this past summer by
our chief scientist Sarah Zatko, which is

203
00:17:06,750 --> 00:17:11,217
predominantly on the topic of surprising
results in the data.

204
00:17:14,892 --> 00:17:18,539
Today, though, this being our first time
presenting here in Europe, we figured we

205
00:17:18,539 --> 00:17:22,869
would take more of an overarching kind of
view. What we're doing and why we're

206
00:17:22,869 --> 00:17:26,619
excited about it and where it's headed. So
we're about to move into a little bit of

207
00:17:26,619 --> 00:17:31,600
the underlying theory, you know. Why do I
think it's reasonable to even try to

208
00:17:31,600 --> 00:17:35,429
measure the security of software from a
technical perspective. But before we can

209
00:17:35,429 --> 00:17:39,310
get into that I need to talk a little bit
about our goals, so that the decisions and

210
00:17:39,310 --> 00:17:45,380
the theory; the motivation is clear,
right. Our goals are really simple: it's a

211
00:17:45,380 --> 00:17:51,399
very easy organization to run because of
that. Goal number one: remain independent

212
00:17:51,399 --> 00:17:56,260
of vendor influence. We are not the first
organization to purport to be looking out

213
00:17:56,260 --> 00:18:02,470
for the consumer. But unlike many of our
predecessors, we are not taking money from

214
00:18:02,470 --> 00:18:09,920
the people we review, right? Seems like
some basic stuff. Seems like some basic

215
00:18:09,920 --> 00:18:17,539
stuff right? Thank you, okay.
Two: automated, comparable, quantitative

216
00:18:17,539 --> 00:18:23,790
analysis. Why automated? Well, we need our
test results to be reproducible. And Tim

217
00:18:23,790 --> 00:18:27,720
goes in opens up your software in IDA and
finds a bunch of stuff that makes them all

218
00:18:27,720 --> 00:18:32,620
stoped - that's not a very repeatable kind
of a standard for things. And so we're

219
00:18:32,620 --> 00:18:36,440
interested in things which are automated.
We'll talk about, maybe a few hackers in

220
00:18:36,440 --> 00:18:39,940
here know how hard that is. We'll talk
about that, but then last we also we're

221
00:18:39,940 --> 00:18:43,539
well acting as a watchdog - we're
protecting the interests of the user, the

222
00:18:43,539 --> 00:18:47,630
consumer, however you would like to look
at it. But we also have three non goals,

223
00:18:47,630 --> 00:18:52,510
three non goals that are equally
important. One: we have a non goal of

224
00:18:52,510 --> 00:18:56,859
finding and disclosing vulnerabilities. I
reserve the right to find and disclose

225
00:18:56,859 --> 00:19:01,370
vulnerabilities. But that's not my goal,
it's not my goal. Another non goal is to

226
00:19:01,370 --> 00:19:04,840
tell software vendors what to do. If a
vendor asks me how to remediate their

227
00:19:04,840 --> 00:19:08,500
terrible score, I will tell them what we
are measuring but I'm not there to help

228
00:19:08,500 --> 00:19:11,950
them remediate. It's on them to be able to
ship a secure product without me holding

229
00:19:11,950 --> 00:19:19,049
their hand. We'll see. And then three:
non-goal, perform free security testing

230
00:19:19,049 --> 00:19:24,090
for vendors. Our testing happens after you
release. Because when you release your

231
00:19:24,090 --> 00:19:28,980
software you are telling people it is
ready to be used. Is it really though, is

232
00:19:28,980 --> 00:19:31,799
it really though, right?
<i>Applause</i>

233
00:19:31,799 --> 00:19:37,309
Yeah, thank you. Yeah, so we are not there
to give you a preview of what your score

234
00:19:37,309 --> 00:19:42,270
will be. There is no sum of money you can
hand me that will get you an early preview

235
00:19:42,270 --> 00:19:46,169
of what your score is - you can try me,
you can try me: there's a fee for trying

236
00:19:46,169 --> 00:19:50,260
me. There's a fee for trying me. But I'm
not gonna look at your stuff until I'm

237
00:19:50,260 --> 00:19:58,549
ready to drop it, right. Yeah bitte, yeah.
All right. So moving into this theory

238
00:19:58,549 --> 00:20:02,770
territory. Three big questions, three big
questions that need to be addressed if you

239
00:20:02,770 --> 00:20:06,990
want to do our work efficiently: what
works, what works for improving security,

240
00:20:06,990 --> 00:20:13,030
what are the things that need or that you
really want to see in software. Two: how

241
00:20:13,030 --> 00:20:17,120
do you recognize when it's being done?
It's no good if someone hands you a piece

242
00:20:17,120 --> 00:20:20,169
of software and says, "I've done all the
latest things" and it's a complete black

243
00:20:20,169 --> 00:20:24,529
box. If you can't check the claim, the
claim is as good as false, in practical

244
00:20:24,529 --> 00:20:30,210
terms, period, right. Software has to be
reviewable or a priori, I'll think you're

245
00:20:30,210 --> 00:20:35,730
full of it. And then three: who's doing it
- of all the things that work, that you

246
00:20:35,730 --> 00:20:39,820
can recognize, who's actually doing it.
You know, let's go ahead - our field is

247
00:20:39,820 --> 00:20:47,429
famous for ruining people's holidays and
weekends over Friday bug disclosures, you

248
00:20:47,429 --> 00:20:51,799
know New Year's Eve bug disclosures. I
would like us to also be famous for

249
00:20:51,799 --> 00:20:59,250
calling out those teams and those software
organizations which are being as good as

250
00:20:59,250 --> 00:21:04,240
the bad guys are being bad, yeah? So
provide someone an incentive to be maybe

251
00:21:04,240 --> 00:21:19,460
happy to see us for a change, right. Okay,
so thank you. Yeah, all right. So how do

252
00:21:19,460 --> 00:21:26,120
we actually pull these things off; the
basic idea. So, I'm going to get into some

253
00:21:26,120 --> 00:21:29,470
deeper theory: if you're not a theorist I
want you to focus on this slide.

254
00:21:29,470 --> 00:21:33,429
And I'm gonna bring it back, it's not all
theory from here on out after this but if

255
00:21:33,429 --> 00:21:39,289
you're not a theorist I really want you to
focus on this slide. The basic motivation,

256
00:21:39,289 --> 00:21:42,560
the basic motivation behind what we're
doing; the technical motivation - why we

257
00:21:42,560 --> 00:21:47,020
think that it's possible to measure and
report on security. It all boils down to

258
00:21:47,020 --> 00:21:53,020
this right. So we start with a thought
experiment, a gedankent, right? Given a

259
00:21:53,020 --> 00:21:58,650
piece of software we can ask: overall, how
secure is it? Kind of a vague question but

260
00:21:58,650 --> 00:22:03,000
you could imagine you know there's
versions of that question. And two: what

261
00:22:03,000 --> 00:22:07,820
are its vulnerabilities. Maybe you want to
nitpick with me about what the word

262
00:22:07,820 --> 00:22:11,240
vulnerability means but broadly you know
this is a much more specific question

263
00:22:11,240 --> 00:22:18,850
right. And here's here's the enticing
thing: the first question appears to ask

264
00:22:18,850 --> 00:22:24,929
for less information than the second
question. And maybe if we were taking bets

265
00:22:24,929 --> 00:22:28,520
I would put my money on, yes, it actually
does ask for less information. What do I

266
00:22:28,520 --> 00:22:33,240
mean by that what do I mean by that? Well,
let's say that someone told you all of the

267
00:22:33,240 --> 00:22:38,389
vulnerabilities in a system right? They
said, "Hey, I got them all", right? You're

268
00:22:38,389 --> 00:22:41,580
like all right that's cool, that's cool.
And if someone asks you hey how secure is

269
00:22:41,580 --> 00:22:45,440
this system you can give them a very
precise answer. You can say it has N

270
00:22:45,440 --> 00:22:48,620
vulnerabilities, and they're of this kind
and like all this stuff right so certainly

271
00:22:48,620 --> 00:22:54,630
the second question is enough to answer
the first. But, is the reverse true?

272
00:22:54,630 --> 00:22:58,470
Namely, if someone were to tell you, for
example, "hey, this piece of software has

273
00:22:58,470 --> 00:23:06,210
exactly 32 vulnerabilities in it." Does
that make it easier to find any of them?

274
00:23:06,210 --> 00:23:12,320
Right, there's room for to maybe do that
using some algorithms that are not yet in

275
00:23:12,320 --> 00:23:15,840
existence.
Certainly the computer scientists in here

276
00:23:15,840 --> 00:23:19,450
are saying, "well, you know, yeah maybe
counting the number of SAT solutions

277
00:23:19,450 --> 00:23:22,700
doesn't help you practically find
solutions. But it might and we just don't

278
00:23:22,700 --> 00:23:27,120
know." Okay fine fine fine. Maybe these
things are the same, but the my experience

279
00:23:27,120 --> 00:23:30,410
in security, and the experience of many
others perhaps is that they probably

280
00:23:30,410 --> 00:23:36,510
aren't the same question. And this
motivates what I'm calling here is Zatko's

281
00:23:36,510 --> 00:23:40,870
question, which is basically asking for an
algorithm that demonstrates that the first

282
00:23:40,870 --> 00:23:45,970
question is easier than the second
question, right. So Zatko's question:

283
00:23:45,970 --> 00:23:49,360
develop a heuristic which can to
efficiently answer one, but not

284
00:23:49,360 --> 00:23:53,549
necessarily two. If you're looking for a
metaphor, if you want to know why I care

285
00:23:53,549 --> 00:23:56,640
about this distinction, I want you to
think about some certain controversial

286
00:23:56,640 --> 00:24:00,990
technologies: maybe think about say
nuclear technology, right. An algorithm

287
00:24:00,990 --> 00:24:04,529
that answers one, but not two, it's a very
safe algorithm to publish. Very safe

288
00:24:04,529 --> 00:24:11,369
algorithm publish indeed. Okay, Claude
Shannon would like more information. happy

289
00:24:11,369 --> 00:24:16,039
to oblige. Let's take a look at this
question from a different perspective

290
00:24:16,039 --> 00:24:19,379
maybe a more hands-on perspective: the
hacker perspective, right? If you're a

291
00:24:19,379 --> 00:24:22,389
hacker and you're watching me up here and
I'm waving my hands around and I'm showing

292
00:24:22,389 --> 00:24:25,930
you charts maybe you're thinking to
yourself yeah boy, what do you got? Right,

293
00:24:25,930 --> 00:24:29,730
how does this actually go. And maybe what
you're thinking to yourself is that, you

294
00:24:29,730 --> 00:24:34,350
know, finding good vulns: that's an
artisan craft right? You're in IDA, you

295
00:24:34,350 --> 00:24:37,250
know you're reversing old way you're doing
all these things or hit and Comm, I don't

296
00:24:37,250 --> 00:24:41,429
know all that stuff. And like, you know,
this kind of clever game; cleverness is

297
00:24:41,429 --> 00:24:47,210
not like this thing that feels very
automatable. But you know on the other

298
00:24:47,210 --> 00:24:51,360
hand there are a lot of tools that do
automate things and so it's not completely

299
00:24:51,360 --> 00:24:57,110
not automatable.
And if you're into fuzzing then perhaps

300
00:24:57,110 --> 00:25:01,500
you are aware of this very simple
observation, which is that if your harness

301
00:25:01,500 --> 00:25:04,940
is perfect if you really know what you're
doing if you have a decent fuzzer then in

302
00:25:04,940 --> 00:25:08,840
principle fuzzing can find every single
problem. You have to be able to look for

303
00:25:08,840 --> 00:25:13,870
it you have to be able harness for it but
in principle it will, right. So the hacker

304
00:25:13,870 --> 00:25:19,210
perspective on Zatko's question is maybe
of two minds on the one hand assessing

305
00:25:19,210 --> 00:25:22,399
security is a game of cleverness, but on
the other hand we're kind of right now at

306
00:25:22,399 --> 00:25:25,880
the cusp of having some game-changing tech
really go - maybe you're saying like

307
00:25:25,880 --> 00:25:29,580
fuzzing is not at the cusp, I promise it's
just at the cusp. We haven't seen all the

308
00:25:29,580 --> 00:25:33,690
fuzzing has to offer right and so maybe
there's room maybe there's room for some

309
00:25:33,690 --> 00:25:41,200
automation to be possible in pursuit of
Zatko's question. Of course, there are

310
00:25:41,200 --> 00:25:45,920
many challenges still in, you know, using
existing hacker technology. Mostly of the

311
00:25:45,920 --> 00:25:49,570
form of various open questions. For
example if you're into fuzzing, you know,

312
00:25:49,570 --> 00:25:53,039
hey: identifying unique crashes. There's
an open question. We'll talk about some of

313
00:25:53,039 --> 00:25:57,060
those, we'll talk about some of those. But
I'm going to offer another perspective

314
00:25:57,060 --> 00:26:01,490
here: so maybe you're not in the business
of doing software reviews but you know a

315
00:26:01,490 --> 00:26:05,929
little computer science. And maybe that
computer science has you wondering what's

316
00:26:05,929 --> 00:26:12,679
this guy talking about, right. I'm here to
acknowledge that. So whatever you think

317
00:26:12,679 --> 00:26:16,610
the word security means: I've got a list
of questions up here. Whatever you think

318
00:26:16,610 --> 00:26:19,502
the word security means, probably, some of
these questions are relevant to your

319
00:26:19,502 --> 00:26:23,299
definition. Right.
Does the software have a hidden backdoor

320
00:26:23,299 --> 00:26:26,600
or any kind of hidden functionality, does
it handle crypto material correctly, etc,

321
00:26:26,600 --> 00:26:30,429
so forth. Anyone in here who knows some
computers abilities theory knows that

322
00:26:30,429 --> 00:26:34,240
every single one of these questions and
many others like them are undecidable due

323
00:26:34,240 --> 00:26:37,960
to reasons essentially no different than
the reason the halting problem is

324
00:26:37,960 --> 00:26:41,330
undecidable,\ which is to say due to
reasons essentially first identified and

325
00:26:41,330 --> 00:26:46,019
studied by Alan Turing a long time before
we had microarchitectures and all these

326
00:26:46,019 --> 00:26:50,350
other things. And so, the computability
perspective says that, you know, whatever

327
00:26:50,350 --> 00:26:54,640
your definition of security is ultimately
you have this recognizability problem:

328
00:26:54,640 --> 00:26:57,900
fancy way of saying that algorithms won't
be able to recognize secure software

329
00:26:57,900 --> 00:27:02,690
because of the undecidability these
issues. The takeaway, the takeaway is that

330
00:27:02,690 --> 00:27:07,090
the computability angle on all of this
says: anyone who's in the business that

331
00:27:07,090 --> 00:27:12,394
we're in has to use heuristics. You have
to, you have to.

332
00:27:15,006 --> 00:27:24,850
All right, this guy gets it. All right, so
on the tech side our last technical

333
00:27:24,850 --> 00:27:28,380
perspective that we're going to take now
is certainly the most abstract which is

334
00:27:28,380 --> 00:27:32,220
the Bayesian perspective, right. So if
you're a frequentist, you need to get with

335
00:27:32,220 --> 00:27:37,490
the times you know it's everything
Bayesian now. So, let's talk about this

336
00:27:37,490 --> 00:27:43,899
for a bit. Only two slides of math, I
promise, only two! So, let's say that I

337
00:27:43,899 --> 00:27:47,120
have some corpus of software. Perhaps it's
a collection of all modern browsers,

338
00:27:47,120 --> 00:27:50,510
perhaps it's the collection of all the
packages in the Debian repository, perhaps

339
00:27:50,510 --> 00:27:53,990
it's everything on github that builds on
this system, perhaps it's a hard drive

340
00:27:53,990 --> 00:27:58,159
full of warez that some guy mailed you,
right? You have some corpus of software

341
00:27:58,159 --> 00:28:02,980
and for a random program in that corpus we
can consider this probability: the

342
00:28:02,980 --> 00:28:07,180
probability distribution of which software
is secure versus which is not. For reasons

343
00:28:07,180 --> 00:28:11,080
described on the computability
perspective, this number is not a

344
00:28:11,080 --> 00:28:17,130
computable number for any reasonable
definition of security. So that's a neat

345
00:28:17,130 --> 00:28:21,220
and so, for practical terms, if you want
to do some probabilistic reasoning, you

346
00:28:21,220 --> 00:28:27,509
need some surrogate for that and so we
consider this here. So, instead of

347
00:28:27,509 --> 00:28:31,000
considering the probability that a piece
of software is secure, a non computable

348
00:28:31,000 --> 00:28:35,960
non verifiable claim, we take a look here
at this indexed collection of

349
00:28:35,960 --> 00:28:38,840
probabilities. This is an infinite
countable family of probability

350
00:28:38,840 --> 00:28:44,330
distributions, basically P sub h,k is just
the probability that for a random piece of

351
00:28:44,330 --> 00:28:50,330
software in the corpus, h work units of
fuzzing will find no more than k unique

352
00:28:50,330 --> 00:28:56,130
crashes, right. And why is this relevant?
Well, at the bottom we have this analytic

353
00:28:56,130 --> 00:28:59,389
observation, which is that in the limit as
h goes to infinity you're basically

354
00:28:59,389 --> 00:29:03,679
saying: "Hey, you know, if I fuzz this
thing for infinity times, you know, what's

355
00:29:03,679 --> 00:29:07,549
that look like?" And, essentially, here we
have analytically that this should

356
00:29:07,549 --> 00:29:12,970
converge. The P sub h,1 should converge to
the probability that a piece of software

357
00:29:12,970 --> 00:29:16,331
just simply cannot be made to crash. Not
the same thing as being secure, but

358
00:29:16,331 --> 00:29:23,730
certainly not a small concern relevant to
security. So, none of that stuff actually

359
00:29:23,730 --> 00:29:30,620
was Bayesian yet, so we need to get there.
And so here we go, right: so, the previous

360
00:29:30,620 --> 00:29:35,080
slide described a probability distribution
measured based on fuzzing. But fuzzing is

361
00:29:35,080 --> 00:29:39,130
expensive and it is also not an answer to
Zatko's question because it finds

362
00:29:39,130 --> 00:29:43,759
vulnerabilities, it doesn't measure
security in the general sense and so

363
00:29:43,759 --> 00:29:47,110
here's where we make the jump to
conditional probabilities: Let M be some

364
00:29:47,110 --> 00:29:51,929
observable property of software has ASLR,
has RELRO, calls these functions, doesn't

365
00:29:51,929 --> 00:29:56,770
call those functions... take your pick.
For random s in S we now consider these

366
00:29:56,770 --> 00:30:02,070
conditional probability distributions and
this is the same kind of probability as we

367
00:30:02,070 --> 00:30:08,379
had on the previous slide but conditioned
on this observable being true, and this

368
00:30:08,379 --> 00:30:11,480
leads to the refined of the Siddall
variant of Zatko's question:

369
00:30:11,480 --> 00:30:17,120
Which observable properties of software
satisfy that, when the software has

370
00:30:17,120 --> 00:30:22,590
property m, the probability of fuzzing
being hard is very high? That's what this

371
00:30:22,590 --> 00:30:27,121
version of this question phrases, and here
we say, you know, in large log(h)/k, in

372
00:30:27,121 --> 00:30:31,590
other words: exponentially more fuzzing
than you expect to find bugs. So this is

373
00:30:31,590 --> 00:30:36,350
the technical version of what we're after.
All of this can be explored, you can

374
00:30:36,350 --> 00:30:40,340
brute-force your way to finding all of
this stuff, and that's exactly what we're

375
00:30:40,340 --> 00:30:48,050
doing. So we're looking for all kinds of
things, we're looking for all kinds of

376
00:30:48,050 --> 00:30:53,840
things that correlate with fuzzing having
low yield on a piece of software, and

377
00:30:53,840 --> 00:30:57,360
there's a lot of ways in which that can
happen. It could be that you are looking

378
00:30:57,360 --> 00:31:01,409
at a feature of software that literally
prevents crashes. Maybe it's the never

379
00:31:01,409 --> 00:31:08,210
crash flag, I don't know. But most of the
things I've talked about, ASLR, RERO, etc.

380
00:31:08,210 --> 00:31:12,169
don't prevent crashes. In fact a ASLR can
take non-crashing programs and make them

381
00:31:12,169 --> 00:31:16,849
crashing. It's the number one reason
vendors don't enable it, right? So why am

382
00:31:16,849 --> 00:31:20,079
I talking about ASLR? Why am I talking
about RELRO? Why am i talking about all

383
00:31:20,079 --> 00:31:22,899
these things that have nothing to do with
stopping crashes and I'm claiming I'm

384
00:31:22,899 --> 00:31:27,399
measuring crashes? This is because, in the
Bayesian perspective, correlation is not

385
00:31:27,399 --> 00:31:31,730
the same thing as causation, right?
Correlation is not the same thing as

386
00:31:31,730 --> 00:31:35,340
causation. It could be that M's presence
literally prevents crashes, but it could

387
00:31:35,340 --> 00:31:39,749
also be that, by some underlying
coincidence, the things we're looking for

388
00:31:39,749 --> 00:31:43,600
are mostly only found in software that's
robust against crashing.

389
00:31:43,600 --> 00:31:48,799
If you're looking for security, I submit
to you that the difference doesn't matter.

390
00:31:48,799 --> 00:31:54,929
Okay, end of my math, danke. I will now go
ahead and do this like really nice analogy

391
00:31:54,929 --> 00:31:59,279
of all those things that I just described,
right. So we're looking for indicators of

392
00:31:59,279 --> 00:32:03,640
a piece of software being secure enough to
be good for consumers, right. So here's an

393
00:32:03,640 --> 00:32:08,131
analogy. Let's say you're a geologist, you
study minerals and all of that and you're

394
00:32:08,131 --> 00:32:13,560
looking for diamonds. Who isn't, right?
Want those diamonds! And like how do you

395
00:32:13,560 --> 00:32:18,270
find diamonds? Even in places that are
rich in diamonds, diamonds are not common.

396
00:32:18,270 --> 00:32:21,279
You don't just go walking around in your
boots, kicking until your toe stubs on a

397
00:32:21,279 --> 00:32:27,049
diamond? You don't do that. Instead you
look for other minerals that are mostly

398
00:32:27,049 --> 00:32:31,860
only found near diamonds but are much more
abundant in those locations than the

399
00:32:31,860 --> 00:32:37,960
diamonds. So, this is mineral science 101,
I guess, I don't know. So, for example,

400
00:32:37,960 --> 00:32:41,389
you want to go find diamond: put on your
boots and go kicking until you find some

401
00:32:41,389 --> 00:32:46,110
chromite, look for some diopside, you
know, look for some garnet. None of these

402
00:32:46,110 --> 00:32:50,340
things turn into diamonds, none of these
things cause diamonds but if you're

403
00:32:50,340 --> 00:32:54,020
finding good concentrations of these
things, then, statistically, there's

404
00:32:54,020 --> 00:32:58,249
probably diamonds nearby. That's what
we're doing. We're not looking for the

405
00:32:58,249 --> 00:33:02,570
things that cause good security per se.
Rather, we're looking for the indicators

406
00:33:02,570 --> 00:33:08,349
that you have put the effort into your
software, right? How's that working out

407
00:33:08,349 --> 00:33:15,070
for us? How's that working out for us?
Well, we're still doing studies. It's, you

408
00:33:15,070 --> 00:33:18,490
know, early to say exactly but we do have
the following interesting coincidence: and

409
00:33:18,490 --> 00:33:24,789
so, here presented I have a collection of
prices that somebody gave much for so-

410
00:33:24,789 --> 00:33:30,369
called the underground exploits. And I can
tell you these prices are maybe a little

411
00:33:30,369 --> 00:33:34,450
low these days but if you work in that
business, if you go to Cyscin, if you do

412
00:33:34,450 --> 00:33:39,009
that kind of stuff, maybe you know that
this is ballpark, it's ballpark.

413
00:33:39,009 --> 00:33:44,080
Alright, and, just a coincidence, maybe it
means we're on the right track, I don't

414
00:33:44,080 --> 00:33:48,740
know, but it's an encouraging sign: When
we run these programs through our

415
00:33:48,740 --> 00:33:53,060
analysis, our rankings more or less
correspond to the actual prices that you

416
00:33:53,060 --> 00:33:58,279
encounter in the wild for access via these
applications. Up above, I have one of our

417
00:33:58,279 --> 00:34:02,059
histogram charts. You can see here that
Chrome and Edge in this particular model

418
00:34:02,059 --> 00:34:06,149
scored very close to the same and it's a
test model, so, let's say they're

419
00:34:06,149 --> 00:34:11,480
basically the same.
Firefox, you know, behind there a little

420
00:34:11,480 --> 00:34:15,040
bit. I don't have Safari on this chart
because - this or all Windows applications

421
00:34:15,040 --> 00:34:21,091
- but the Safari score falls in between.
So, lots of theory, lots of theory, lots

422
00:34:21,091 --> 00:34:27,920
of theory and then we have this. So, we're
going to go ahead now and hand off to our

423
00:34:27,920 --> 00:34:31,679
lead engineer, Parker, who is going to
talk about some of the concrete stuff, the

424
00:34:31,679 --> 00:34:35,210
non-chalkboard stuff, the software stuff
that actually makes this work.

425
00:34:35,956 --> 00:34:40,980
Thompson: Yeah, so I want to talk about
the process of actually doing it. Building

426
00:34:40,980 --> 00:34:45,050
the tooling that's required to collect
these observables. Effectively, how do you

427
00:34:45,050 --> 00:34:50,560
go mining for indicator indicator
minerals? But first the progression of

428
00:34:50,560 --> 00:34:55,810
where we are and where we're going. We
initially broke this out into three major

429
00:34:55,810 --> 00:35:00,360
tracks of our technology. We have our
static analysis engine, which started as a

430
00:35:00,360 --> 00:35:05,790
prototype, and we have now recently
completed a much more mature and solid

431
00:35:05,790 --> 00:35:09,930
engine that's allowing us to be much more
extensible and digging deeper into

432
00:35:09,930 --> 00:35:16,320
programs, and provide a much more deep
observables. Then, we have the data

433
00:35:16,320 --> 00:35:21,510
collection and data reporting. Tim showed
some of our early stabs at this. We're

434
00:35:21,510 --> 00:35:25,450
right now in the process of building new
engines to make the data more accessible

435
00:35:25,450 --> 00:35:30,150
and easy to work with and hopefully more
of that will be available soon. Finally,

436
00:35:30,150 --> 00:35:35,910
we have our fuzzer track. We needed to get
some early data, so we played with some

437
00:35:35,910 --> 00:35:40,680
existing off-the-shelf fuzzers, including
AFL, and, while that was fun,

438
00:35:40,680 --> 00:35:44,190
unfortunately it's a lot of work to
manually instrument a lot of fuzzers for

439
00:35:44,190 --> 00:35:48,830
hundreds of binaries.
So, we then built an automated solution

440
00:35:48,830 --> 00:35:52,930
that started to get us closer to having a
fuzzing harness that could autogenerate

441
00:35:52,930 --> 00:35:57,840
itself, depending on the software, the
software's behavior. But, right now,

442
00:35:57,840 --> 00:36:01,650
unfortunately that technology showed us
more deficiencies than it showed

443
00:36:01,650 --> 00:36:07,360
successes. So, we are now working on a
much more mature fuzzer that will allow us

444
00:36:07,360 --> 00:36:12,780
to dig deeper into programs as we're
running and collect very specific things

445
00:36:12,780 --> 00:36:21,260
that we need for our model and our
analysis. But on to our analytic pipeline

446
00:36:21,260 --> 00:36:25,831
today. This is one of the most concrete
components of our engine and one of the

447
00:36:25,831 --> 00:36:29,000
most fun!
We effectively wanted some type of

448
00:36:29,000 --> 00:36:34,550
software hopper, where you could just pour
programs in, installers and then, on the

449
00:36:34,550 --> 00:36:39,560
other end, come reports: Fully annotated
and actionable information that we can

450
00:36:39,560 --> 00:36:45,320
present to people. So, we went about the
process of building a large-scale engine.

451
00:36:45,320 --> 00:36:50,500
It starts off with a simple REST API,
where we can push software in, which then

452
00:36:50,500 --> 00:36:55,600
gets moved over to our computation cluster
that effectively provides us a fabric to

453
00:36:55,600 --> 00:37:00,310
work with. It makes is made up of a lot of
different software suites, starting off

454
00:37:00,310 --> 00:37:06,730
with our data processing, which is done by
apache spark and then moves over into data

455
00:37:06,730 --> 00:37:12,910
data handling and data analysis in spark,
and then we have a common HDFS layer to

456
00:37:12,910 --> 00:37:17,530
provide a place for the data to be stored
and then a resource manager and Yarn. All

457
00:37:17,530 --> 00:37:22,500
of that is backed by our compute and data
nodes, which scale out linearly. That then

458
00:37:22,500 --> 00:37:27,590
moves into our data science engine, which
is effectively spark with Apache Zeppelin,

459
00:37:27,590 --> 00:37:30,480
which provides us a really fun interface
where we can work with the data in an

460
00:37:30,480 --> 00:37:35,830
interactive manner but be kicking off
large-scale jobs into the cluster. And

461
00:37:35,830 --> 00:37:40,110
finally, this goes into our report
generation engine. What this bought us,

462
00:37:40,110 --> 00:37:46,030
was the ability to linearly scale and make
that hopper bigger and bigger as we need,

463
00:37:46,030 --> 00:37:50,740
but also provide us a way to process data
that doesn't fit in a single machine's

464
00:37:50,740 --> 00:37:54,110
RAM. You can push the instance sizes as
you large as you want, but we have

465
00:37:54,110 --> 00:38:00,300
datasets that blow away any single host
RAM set. So this allows us to work with

466
00:38:00,300 --> 00:38:08,690
really large collections of observables.
I want to dive down now into our actual

467
00:38:08,690 --> 00:38:13,160
static analysis. But first we have to
explore the problem space, because it's a

468
00:38:13,160 --> 00:38:19,490
nasty one. Effectively in settles mission
is to process as much software as

469
00:38:19,490 --> 00:38:25,790
possible. Hopefully all of it, but it's
hard to get your hand on all the binaries

470
00:38:25,790 --> 00:38:29,260
that are out there. When you start to look
at that problem you understand there's a

471
00:38:29,260 --> 00:38:34,830
lot of combinations: there's a lot of CPU
architectures, there's a lot of operating

472
00:38:34,830 --> 00:38:38,610
systems, there's a lot of file formats,
there's a lot of environments the software

473
00:38:38,610 --> 00:38:43,160
gets deployed into, and every single one
of them has their own app Archer app

474
00:38:43,160 --> 00:38:47,320
armory features. And it can be
specifically set for one combination

475
00:38:47,320 --> 00:38:51,671
button on another and you don't want to
penalize a developer for not turning on a

476
00:38:51,671 --> 00:38:56,290
feature they had no access to ever turn
on. So effectively we need to solve this

477
00:38:56,290 --> 00:39:01,050
in a much more generic way. And so what we
did is our static analysis engine

478
00:39:01,050 --> 00:39:04,630
effectively looks like a gigantic
collection of abstraction libraries to

479
00:39:04,630 --> 00:39:12,390
handle binary programs. You take in some
type of input file be it ELF, PE, MachO

480
00:39:12,390 --> 00:39:17,730
and then the pipeline splits. It goes off
into two major analyzer classes, our

481
00:39:17,730 --> 00:39:22,360
format analyzers, which look at the
software much like how a linker or loader

482
00:39:22,360 --> 00:39:26,600
would look at it. I want to understand how
it's going to be loaded up, what type of

483
00:39:26,600 --> 00:39:30,680
armory feature is going to be applied and
then we can run analyzers over that. In

484
00:39:30,680 --> 00:39:34,520
order to achieve that we need abstraction
libraries that can provide us an abstract

485
00:39:34,520 --> 00:39:40,900
memory map, a symbol resolver, generic
section properties. So all that feeds in

486
00:39:40,900 --> 00:39:46,060
and then we run over a collection of
analyzers to collect data and observables.

487
00:39:46,060 --> 00:39:49,650
Next we have our code analyzers, these are
the analyzers that run over the code

488
00:39:49,650 --> 00:39:57,600
itself. I need to be able to look at every
possible executable path. In order to do

489
00:39:57,600 --> 00:40:02,400
that we need to do function discovery,
feed that into a control flow recovery

490
00:40:02,400 --> 00:40:07,880
engine, and then as a post-processing step
dig through all of the possible metadata

491
00:40:07,880 --> 00:40:12,820
in the software, such as like a switch
table, or something like that to get even

492
00:40:12,820 --> 00:40:20,770
deeper into the software. Then this
provides us a basic list of basic blocks,

493
00:40:20,770 --> 00:40:24,470
functions, instruction ranges. And does so
in an efficient manner so we can process a

494
00:40:24,470 --> 00:40:30,550
lot of software as it goes. Then all that
gets fed over into the main modular

495
00:40:30,550 --> 00:40:36,570
analyzers. Finally, all of this comes
together and gets put into a gigantic blob

496
00:40:36,570 --> 00:40:41,850
of observables and fed up to the pipeline.
We really want to thank the Ford

497
00:40:41,850 --> 00:40:46,920
Foundation for supporting our work in
this, because the pipeline and the static

498
00:40:46,920 --> 00:40:51,840
analysis has been a massive boon for our
project and we're only beginning now to

499
00:40:51,840 --> 00:40:58,920
really get our engine running and we're
having a great time with it. So digging

500
00:40:58,920 --> 00:41:03,760
into the observables themselves, what are
we looking at and let's break them apart.

501
00:41:03,760 --> 00:41:08,980
So the format structure components, things
like ASLR, DEP, RELRO.

502
00:41:08,980 --> 00:41:13,370
basic app armory, that's going to go into
the feature and gonna be enabled at the OS

503
00:41:13,370 --> 00:41:17,830
layer when it gets loaded up or linked.
And we also collect other metadata about

504
00:41:17,830 --> 00:41:22,000
the program such as like: "What libraries
are linked in?", "What's its dependency

505
00:41:22,000 --> 00:41:26,400
tree look like – completely?", "How did
those software, how did those library

506
00:41:26,400 --> 00:41:32,040
score?", because that can affect your main
software. Interesting example on Linux, if

507
00:41:32,040 --> 00:41:35,840
you link a library that requires an
executable stack, guess what your software

508
00:41:35,840 --> 00:41:39,990
now has an executable stack, even if you
didn't mark that. So we need to be owners

509
00:41:39,990 --> 00:41:44,700
to understand what ecosystem the software
is gonna live in. And the code structure

510
00:41:44,700 --> 00:41:47,590
analyzers look at things like
functionality: "What's the software

511
00:41:47,590 --> 00:41:52,600
doing?", "What type of app armory is
getting injected into the code?". A great

512
00:41:52,600 --> 00:41:55,850
example of that is something like stack
guards or fortify source. These are our

513
00:41:55,850 --> 00:42:01,550
main features that only really apply and
can be observed inside of the control flow

514
00:42:01,550 --> 00:42:08,240
or inside of the actual instructions
themselves. This is why control

515
00:42:08,240 --> 00:42:10,880
photographs are key.
We played around with a number of

516
00:42:10,880 --> 00:42:15,980
different ways of analyzing software that
we could scale out and ultimately we had

517
00:42:15,980 --> 00:42:20,171
to come down to working with control
photographs. Provided here is a basic

518
00:42:20,171 --> 00:42:23,400
visualization of what I'm talking about
with a control photograph, provided by

519
00:42:23,400 --> 00:42:28,690
Benja, which has wonderful visualization
tools, hence this photo, and not our

520
00:42:28,690 --> 00:42:33,170
engine because we don't build their very
many visualization engines. But you

521
00:42:33,170 --> 00:42:38,470
basically have a function that's broken up
into basic blocks, which is broken up into

522
00:42:38,470 --> 00:42:42,910
instructions, and then you have basic flow
between them. Having this as an iterable

523
00:42:42,910 --> 00:42:47,650
structure that we can work with, allows us
to walk over that and walk every single

524
00:42:47,650 --> 00:42:50,790
instruction, understand the references,
understand where code and data is being

525
00:42:50,790 --> 00:42:54,500
referenced, and how is it being
referenced.

526
00:42:54,500 --> 00:42:57,640
And then what type of functionalities
being used, so this is a great way to find

527
00:42:57,640 --> 00:43:02,530
something, like whether or not your stack
guards are being applied on every function

528
00:43:02,530 --> 00:43:08,340
that needs them, how deep are they being
applied, and is the compiler possibly

529
00:43:08,340 --> 00:43:11,850
introducing errors into your armory
features. which are interesting side

530
00:43:11,850 --> 00:43:19,590
studies. Also why we did this is because
we want to push the concept of what type

531
00:43:19,590 --> 00:43:28,339
of observables even farther. Let's say
take this example you want to be able to

532
00:43:28,339 --> 00:43:34,340
take instruction abstractions. Let's say
for all major architectures you can break

533
00:43:34,340 --> 00:43:38,690
them up into major categories. Be it
arithmetic instructions, data manipulation

534
00:43:38,690 --> 00:43:45,850
instructions, like load stores and then
control flow instructions. Then with these

535
00:43:45,850 --> 00:43:52,830
basic fundamental building blocks you can
make artifacts. Think of them like a unit

536
00:43:52,830 --> 00:43:56,400
of functionality: has some type of input,
some type of output, it provides some type

537
00:43:56,400 --> 00:44:01,280
of operation on it. And then with these
little units of functionality, you can

538
00:44:01,280 --> 00:44:05,210
link them together and think of these
artifacts as may be sub-basic block or

539
00:44:05,210 --> 00:44:09,440
crossing a few basic blocks, but a
different way to break up the software.

540
00:44:09,440 --> 00:44:13,130
Because a basic block is just a branch
break, but we want to look at

541
00:44:13,130 --> 00:44:18,680
functionality brakes, because these
artifacts can provide the basic

542
00:44:18,680 --> 00:44:24,891
fundamental building blocks of the
software itself. It's more important, when

543
00:44:24,891 --> 00:44:28,840
we want to start doing symbolic lifting.
So that we can lift the entire software up

544
00:44:28,840 --> 00:44:35,250
into a generic representation, that we can
slice and dice as needed.

545
00:44:38,642 --> 00:44:42,760
Moving from there, I want to talk about
fuzzing a little bit more. Fuzzing is

546
00:44:42,760 --> 00:44:47,370
effectively at the heart of our project.
It provides us the rich dataset that we

547
00:44:47,370 --> 00:44:52,040
can use to derive a model. It also
provides us awesome other metadata on the

548
00:44:52,040 --> 00:44:58,060
side. But why? Why do we care about
fuzzing? Why is fuzzing the metric, that

549
00:44:58,060 --> 00:45:04,680
you build an engine, that you build a
model that you drive some type of reason

550
00:45:04,680 --> 00:45:11,560
from? So think of the set of bugs,
vulnerabilities, and exploitable

551
00:45:11,560 --> 00:45:16,930
vulnerabilities. In an ideal world you'd
want to just have a machine that pulls out

552
00:45:16,930 --> 00:45:20,250
exploitable vulnerabilities.
Unfortunately, this is exceedingly costly

553
00:45:20,250 --> 00:45:25,690
for a series of decision problems, that go
between these sets. So now consider the

554
00:45:25,690 --> 00:45:31,900
superset of bugs or faults. A fuzzer can
easily recognize, or other software can

555
00:45:31,900 --> 00:45:37,400
easily recognize faults, but if you want
to move down the sets you unfortunately

556
00:45:37,400 --> 00:45:42,770
need to jump through a lot of decision
hoops. For example, if you want to move to

557
00:45:42,770 --> 00:45:45,760
a vulnerability you have to understand:
Does the attacker have some type of

558
00:45:45,760 --> 00:45:51,150
control? Is there a trust boundary being
crossed? Is this software configured in

559
00:45:51,150 --> 00:45:55,000
the right way for this to be vulnerable
right now? So they're human factors that

560
00:45:55,000 --> 00:45:59,280
are not deducible from the outside. You
then amplify this decision problem even

561
00:45:59,280 --> 00:46:05,320
worse going to exploitable
vulnerabilities. So if we collect the

562
00:46:05,320 --> 00:46:11,360
superset of bugs, we will know that there
is some proportion of subsets in there.

563
00:46:11,360 --> 00:46:15,830
And this provides us a datasets easily
recognizable and we can collect in a cost-

564
00:46:15,830 --> 00:46:22,170
efficient manner. Finally, fuzzing is key
and we're investing a lot of our time

565
00:46:22,170 --> 00:46:26,570
right now and working on a new fuzzing
engine, because there are some key things

566
00:46:26,570 --> 00:46:32,290
we want to do.
We want to be able to understand all of

567
00:46:32,290 --> 00:46:35,340
the different paths the software could be
taking, and as you're fuzzing you're

568
00:46:35,340 --> 00:46:40,010
effectively driving the software down as
many unique paths while referencing as

569
00:46:40,010 --> 00:46:47,760
many unique data manipulations as
possible. So if we save off every path,

570
00:46:47,760 --> 00:46:51,840
annotate the ones that are faulting, we
now have this beautiful rich data set of

571
00:46:51,840 --> 00:46:57,060
exactly where the software went as we were
driving it in specific ways. Then we feed

572
00:46:57,060 --> 00:47:02,010
that back into our static analysis engine
and begin to generate those instruction

573
00:47:02,010 --> 00:47:07,680
out of those instruction abstractions,
those artifacts. And with that, imagine we

574
00:47:07,680 --> 00:47:14,560
have these gigantic traces of instruction
abstractions. From there we can then begin

575
00:47:14,560 --> 00:47:20,990
to train the model to explore around the
fault location and begin to understand and

576
00:47:20,990 --> 00:47:27,300
try and study the fundamental building
blocks of what a bug looks like in an

577
00:47:27,300 --> 00:47:32,990
abstract instruction agnostic way. This is
why we're spending a lot of time on our

578
00:47:32,990 --> 00:47:36,980
Fuzzing engine right now. But hopefully
soon we'll be able to talk about that more

579
00:47:36,980 --> 00:47:40,381
and maybe a tech track and not the policy
track.

580
00:47:44,748 --> 00:47:49,170
C: Yeah, so from then on when anything
went wrong with the computer we said it

581
00:47:49,170 --> 00:47:55,700
had bugs in it. <i>laughs</i> All right, I
promised you a technical journey, I

582
00:47:55,700 --> 00:47:59,461
promised you a technical journey into the
dark abyss of as deep as you want to get

583
00:47:59,461 --> 00:48:03,460
with it. So let's go ahead and bring it
up. Let's wrap it up and bring it up a

584
00:48:03,460 --> 00:48:07,340
little bit here. We've talked a great deal
today about some theory. We've talked

585
00:48:07,340 --> 00:48:09,970
about development in our tooling and
everything else and so I figured I should

586
00:48:09,970 --> 00:48:14,010
end with some things that are not in
progress, but in fact which are done in

587
00:48:14,010 --> 00:48:20,630
yesterday's news. Just to go ahead and
make that shared here with Europe. So in

588
00:48:20,630 --> 00:48:24,140
the midst of all of our development we
have been discovering and reporting bugs,

589
00:48:24,140 --> 00:48:28,680
again this not our primary purpose really.
But you know you can't help but do it. You

590
00:48:28,680 --> 00:48:32,170
know how computers are these days. You
find bugs just for turning them on, right?

591
00:48:32,170 --> 00:48:38,610
So we've been disclosing all of that a
little while ago. At DEFCON and Black Hat

592
00:48:38,610 --> 00:48:43,030
our chief scientist Sarah together with
Mudge went ahead and dropped this

593
00:48:43,030 --> 00:48:47,840
bombshell on the Firefox team which is
that for some period of time they had ASLR

594
00:48:47,840 --> 00:48:54,310
disabled on OS X. When we first found it
we assumed it was a bug in our tools. When

595
00:48:54,310 --> 00:48:57,720
we first mentioned it in a talk they came
to us and said it's definitely a bug on

596
00:48:57,720 --> 00:49:03,140
our tools or might be or some level of
surprise and then people started looking

597
00:49:03,140 --> 00:49:08,840
into it and in fact at one point it had
been enabled and then temporarily

598
00:49:08,840 --> 00:49:12,960
disabled. No one knew, everyone thought it
was on. It takes someone looking to notice

599
00:49:12,960 --> 00:49:18,010
that kind of stuff, right. Major shout out
though, they fixed it immediately despite

600
00:49:18,010 --> 00:49:23,950
our full disclosure on stage and
everything. So very impressed, but in

601
00:49:23,950 --> 00:49:27,870
addition to popping surprises on people
we've also been doing the usual process of

602
00:49:27,870 --> 00:49:32,890
submitting patches and bugs, particularly
to LLVM and Qemu and if you work in

603
00:49:32,890 --> 00:49:35,810
software analysis you could probably guess
why.

604
00:49:36,510 --> 00:49:39,280
Incidentally, if you're looking for a
target to fuzz if you want to go home from

605
00:49:39,280 --> 00:49:45,870
CCC and you want to find a ton of findings
LLVM comes with a bunch of parsers. You

606
00:49:45,870 --> 00:49:50,060
should fuzz them, you should fuzz them and
I say that because I know for a fact you

607
00:49:50,060 --> 00:49:53,170
are gonna get a bunch of findings and it'd
be really nice. I would appreciate it if I

608
00:49:53,170 --> 00:49:56,360
didn't have to pay the people to fix them.
So if you wouldn't mind disclosing them

609
00:49:56,360 --> 00:50:00,240
that would help. But besides these bug
reports and all these other things we've

610
00:50:00,240 --> 00:50:04,210
also been working with lots of others. You
know we gave a talk earlier this summer,

611
00:50:04,210 --> 00:50:06,910
Sarah gave a talk earlier this summer,
about these things and she presented

612
00:50:06,910 --> 00:50:11,830
findings on comparing some of these base
scores of different Linux distributions.

613
00:50:11,830 --> 00:50:16,320
And based on those findings there was a
person on the fedora red team, Jason

614
00:50:16,320 --> 00:50:20,470
Calloway, who sat there and well I can't
read his mind but I'm sure that he was

615
00:50:20,470 --> 00:50:24,700
thinking to himself: golly it would be
nice to not, you know, be surprised at the

616
00:50:24,700 --> 00:50:28,560
next one of these talks. They score very
well by the way. They were leading in

617
00:50:28,560 --> 00:50:33,660
many, many of our metrics. Well, in any
case, he left Vegas and he went back home

618
00:50:33,660 --> 00:50:36,850
and him and his colleagues have been
working on essentially re-implementing

619
00:50:36,850 --> 00:50:41,570
much of our tooling so that they can check
the stuff that we check before they

620
00:50:41,570 --> 00:50:47,530
release. Before they release. Looking for
security before you release. So that would

621
00:50:47,530 --> 00:50:51,520
be a good thing for others to do and I'm
hoping that that idea really catches on.

622
00:50:51,520 --> 00:50:58,990
<i>laughs</i> Yeah, yeah right, that would be
nice. That would be nice.

623
00:50:58,990 --> 00:51:04,310
But in addition to that, in addition to
that our mission really is to get results

624
00:51:04,310 --> 00:51:08,220
out to the public and so in order to
achieve that, we have broad partnerships

625
00:51:08,220 --> 00:51:12,340
with Consumer Reports and the digital
standard. Especially if you're into cyber

626
00:51:12,340 --> 00:51:16,410
policy, I really encourage you to take a
look at the proposed digital standard,

627
00:51:16,410 --> 00:51:21,220
which is encompassing of the things we
look for and and and so much more. URLs,

628
00:51:21,220 --> 00:51:25,720
data, traffic, motion and cryptography and
update mechanisms and all that good stuff.

629
00:51:25,720 --> 00:51:31,951
So, where we are and where we're going,
the big takeaways here for if you're

630
00:51:31,951 --> 00:51:36,310
looking for that, so what, three points
for you: one we are building a tooling

631
00:51:36,310 --> 00:51:39,750
necessary to do larger and larger and
larger studies regarding these surrogate

632
00:51:39,750 --> 00:51:44,980
security stores. My hope is that in some
period of the not-too-distant future, I

633
00:51:44,980 --> 00:51:48,600
would like to be able to, with my
colleagues, publish some really nice

634
00:51:48,600 --> 00:51:51,640
findings about what are the things that
you can observe in software, which have a

635
00:51:51,640 --> 00:51:57,390
suspiciously high correlation with the
software being good. Right, nobody really

636
00:51:57,390 --> 00:52:00,390
knows right now. It's an empirical
question. As far as I know, the study

637
00:52:00,390 --> 00:52:03,080
hasn't been done. We've been running it on
the small scale. We're building the

638
00:52:03,080 --> 00:52:06,620
tooling to do it on a much larger scale.
We are hoping that this winds up being a

639
00:52:06,620 --> 00:52:11,480
useful field in security as that
technology develops. In the meantime our

640
00:52:11,480 --> 00:52:15,560
static analyzers are already making
surprising discoveries: hit YouTube and

641
00:52:15,560 --> 00:52:21,300
take a look for Sara Zatko's recent talks
at DEFCON/Blackhat. Lots of fun findings

642
00:52:21,300 --> 00:52:25,910
in there. Lots of things that anyone who
looks would have found it. Lots of that.

643
00:52:25,910 --> 00:52:29,080
And then lastly, if you were in the
business of shipping software and you are

644
00:52:29,080 --> 00:52:32,620
thinking to yourself.. okay so these guys,
someone gave them some money to mess up my

645
00:52:32,620 --> 00:52:36,840
day and you're wondering: what can I do to
not have my day messed up? One simple

646
00:52:36,840 --> 00:52:40,870
piece of advice, one simple piece of
advice: make sure your software employs

647
00:52:40,870 --> 00:52:45,920
every exploit mitigation technique Mudge
has ever or will ever hear of. And he's

648
00:52:45,920 --> 00:52:49,500
heard of a lot of them. He's only gonna,
you know all that, turn all those things

649
00:52:49,500 --> 00:52:52,280
on and if you don't know anything about
that stuff, if nobody on your team knows

650
00:52:52,280 --> 00:52:57,370
anything about that stuff didn't I don't
even know I'm saying this if you hear you

651
00:52:57,370 --> 00:53:00,972
know about that stuff so do that. If
you're not here, then you should be here.

652
00:53:04,428 --> 00:53:16,330
Danke, Danke.
Herald Angel: Thank you, Tim and Parker.

653
00:53:17,501 --> 00:53:23,630
Do we have any questions from the
audience? It's really hard to see you with

654
00:53:23,630 --> 00:53:30,120
that bright light in my face. I think the
signal angel has a question. Signal Angel:

655
00:53:30,120 --> 00:53:34,550
So the IRC channel was impressed by your
tools and your models that you wrote. And

656
00:53:34,550 --> 00:53:38,050
they are wondering what's going to happen
to that, because you do have funding from

657
00:53:38,050 --> 00:53:42,040
the Ford foundation now and so what are
your plans with this? Do you plan on

658
00:53:42,040 --> 00:53:46,080
commercializing this or is it going to be
open source or how do we get our hands on

659
00:53:46,080 --> 00:53:49,150
this?
C: It's an excellent question. So for the

660
00:53:49,150 --> 00:53:53,550
time being the money that we are receiving
is to develop the tooling, pay for the AWS

661
00:53:53,550 --> 00:53:57,790
instances, pay for the engineers and all
that stuff. The direction as an

662
00:53:57,790 --> 00:54:01,410
organization that we would like to take
things I have no interest in running a

663
00:54:01,410 --> 00:54:05,410
monopoly. That sounds like a fantastic
amount of work and I really don't want to

664
00:54:05,410 --> 00:54:09,430
do it. However, I have a great deal of
interest in taking the gains that we are

665
00:54:09,430 --> 00:54:13,860
making in the technology and releasing the
data so that other competent researchers

666
00:54:13,860 --> 00:54:19,020
can go through and find useful things that
we may not have noticed ourselves. So

667
00:54:19,020 --> 00:54:22,150
we're not at a point where we are
releasing data in bulk just yet, but that

668
00:54:22,150 --> 00:54:26,432
is simply a matter of engineering our
tools, are still in flux as we, you know.

669
00:54:26,432 --> 00:54:29,230
When we do that, we want to make sure the
data is correct and so our software has to

670
00:54:29,230 --> 00:54:33,640
have its own low bug counts and all these
other things. But ultimately for the

671
00:54:33,640 --> 00:54:37,950
scientific aspect of our mission. Though
the science is not our primary mission.

672
00:54:37,950 --> 00:54:41,920
Our primary mission is to apply it to help
consumers. At the same time, it is our

673
00:54:41,920 --> 00:54:47,590
belief that an opaque model is as good as
crap, no one should trust an opaque model,

674
00:54:47,590 --> 00:54:50,940
if somebody is telling you that they have
some statistics and they do not provide

675
00:54:50,940 --> 00:54:54,540
you with any underlying data and it is not
reproducible you should ignore them.

676
00:54:54,540 --> 00:54:58,360
Consequently what we are working towards
right now is getting to a point where we

677
00:54:58,360 --> 00:55:02,730
will be able to share all of those
findings. The surrogate scores, the

678
00:55:02,730 --> 00:55:06,000
interesting correlations between
observables and fuzzing. All that will be

679
00:55:06,000 --> 00:55:09,200
public as the material comes online.
Signal Angel: Thank you.

680
00:55:09,200 --> 00:55:11,870
C: Thank you.
Herald Angel: Thank you. And microphone

681
00:55:11,870 --> 00:55:14,860
number three please.
Mic3: Hi, thanks so some really

682
00:55:14,860 --> 00:55:18,450
interesting work you presented here. So
there's something I'm not sure I

683
00:55:18,450 --> 00:55:22,910
understand about the approach that you're
taking. If you are evaluating the security

684
00:55:22,910 --> 00:55:26,320
of say a library function or the
implementation of a network protocol for

685
00:55:26,320 --> 00:55:29,780
example you know there'd be a precise
specification you could check that

686
00:55:29,780 --> 00:55:35,190
against. And the techniques you're using
would make sense to me. But it's not so

687
00:55:35,190 --> 00:55:37,970
clear since you've set the goal that
you've set for yourself is to evaluate

688
00:55:37,970 --> 00:55:43,580
security of consumer software. It's not
clear to me whether it's fair to call

689
00:55:43,580 --> 00:55:47,430
these results security scores in the
absence of a threat model so. So my

690
00:55:47,430 --> 00:55:50,350
question is, you know, how is it
meaningful to make a claim that a piece of

691
00:55:50,350 --> 00:55:52,240
software is secure if you don't have a
threat model for it?

692
00:55:52,240 --> 00:55:56,090
C: This is an excellent question and I
anyone who disagrees is they should the

693
00:55:56,090 --> 00:56:01,330
wrong. Security without a threat model is
not security at all. It's absolutely a

694
00:56:01,330 --> 00:56:05,560
true point. So the things that we are
looking for, most of them are things that

695
00:56:05,560 --> 00:56:08,800
you will already find present in your
threat model. And so for example we were

696
00:56:08,800 --> 00:56:12,390
reporting on the presence of things like a
ASLR and lots of other things that get to

697
00:56:12,390 --> 00:56:17,030
the heart of exploitability of a piece of
software. So for example if we are

698
00:56:17,030 --> 00:56:19,870
reviewing a piece of software, that has no
attack surface

699
00:56:19,870 --> 00:56:24,160
then it is canonically not in the threat
model and in that sense it makes no sense

700
00:56:24,160 --> 00:56:29,270
to report on its overall security. On the
other hand, if we're talking about

701
00:56:29,270 --> 00:56:33,470
software like say a word processor, a
browser, anything on your phone, anything

702
00:56:33,470 --> 00:56:36,120
that talks on the network, we're talking
about those kinds of applications then I

703
00:56:36,120 --> 00:56:39,280
would argue that exploit mitigations and
the other things that we are measuring are

704
00:56:39,280 --> 00:56:44,330
almost certainly very relevant. So there's
a sense in which what we are measuring is

705
00:56:44,330 --> 00:56:48,411
the lowest common denominator among what
we imagine or the dominant threat models

706
00:56:48,411 --> 00:56:53,180
for the applications. The hand-wavy
answer, but I promised heuristics so there

707
00:56:53,180 --> 00:56:55,180
you go.
Mic3: Thanks.

708
00:56:55,180 --> 00:57:01,620
C: Thank you.
Herald Angel: Any questions? No raising

709
00:57:01,620 --> 00:57:07,060
hands, okay. And then the herald can ask a
question, because I never can. So the

710
00:57:07,060 --> 00:57:11,920
question is: you mentioned earlier these
security labels and for example what

711
00:57:11,920 --> 00:57:15,880
institution could give out the security
labels? Because as obviously the vendor

712
00:57:15,880 --> 00:57:21,740
has no interest in IT security?
C: Yes it's a very good question. So our

713
00:57:21,740 --> 00:57:25,580
partnership with Consumer Reports. I don't
know if you're familiar with them, but in

714
00:57:25,580 --> 00:57:31,340
the United States Consumer Reports is a
major huge consumer watchdog organization.

715
00:57:31,340 --> 00:57:36,550
They test the safety of automobiles, they
test you know lots of consumer appliances.

716
00:57:36,550 --> 00:57:40,070
All kinds of things both to see if they
function more or less as advertised but

717
00:57:40,070 --> 00:57:45,210
most importantly they're checking for
quality, reliability and safety. So our

718
00:57:45,210 --> 00:57:49,840
partnership with Consumer Reports is all
about us doing our work and then

719
00:57:49,840 --> 00:57:54,060
publishing that. And so for example the
televisions that we presented the data on

720
00:57:54,060 --> 00:57:58,290
all of that was collected and published in
partnership with Consumer Reports.

721
00:57:58,290 --> 00:58:00,970
Herald: Thank you.
C: Thank you.

722
00:58:02,630 --> 00:58:12,430
Herald: Any other questions for stream. I
hear a no. Well in this case people thank

723
00:58:12,430 --> 00:58:16,440
you.
Thank Tim and Parker for their nice talk

724
00:58:16,440 --> 00:58:19,964
and please give them a very very warm hall
round of applause.

725
00:58:19,964 --> 00:58:24,694
<i>applause</i>
C: Thank you. T: Thank you.

726
00:58:24,694 --> 00:58:51,000
subtitles created by c3subtitles.de
in the year 2017. Join, and help us!