WEBVTT
00:00:00.090 --> 00:00:13.750
33C3 preroll music
00:00:13.750 --> 00:00:16.299
basically textbooks have been written
00:00:16.299 --> 00:00:19.718
about it countless talks have been
00:00:19.718 --> 00:00:22.480
have been Illuminating all of the errors
00:00:22.480 --> 00:00:26.690
of our ways and still all those sucky
00:00:26.690 --> 00:00:30.400
software is out there but
00:00:30.400 --> 00:00:33.130
Fefe over here the hero of our show
00:00:33.130 --> 00:00:36.700
has put out has put all of these best
00:00:36.700 --> 00:00:39.990
practices into you know into his work to
00:00:39.990 --> 00:00:43.480
try to create a secure website he's
00:00:43.480 --> 00:00:46.859
going to show us how it's done so that
00:00:46.859 --> 00:00:52.489
we can all sleep way better at night and
00:00:52.489 --> 00:00:55.189
with that template go back and
00:00:55.189 --> 00:00:57.303
and secure our own software and so with
00:00:57.303 --> 00:00:59.540
that I'm going to hand it right over to
00:00:59.540 --> 00:01:01.930
Fefe give him a round of applause
00:01:01.930 --> 00:01:12.406
applause
00:01:13.371 --> 00:01:15.153
thank you I have to start
00:01:15.153 --> 00:01:17.580
with an apology because I did submit
00:01:17.580 --> 00:01:19.840
this talk but it was rejected so the
00:01:19.840 --> 00:01:21.880
slides are not at the stage where they
00:01:21.880 --> 00:01:24.320
should be these are our slides for a
00:01:24.320 --> 00:01:26.359
previous version of the talk it contains
00:01:26.359 --> 00:01:28.179
all the material and I tried to update
00:01:28.179 --> 00:01:30.231
it more but that destroyed the flow so
00:01:30.231 --> 00:01:33.334
we we're stuck with it basically the
00:01:33.084 --> 00:01:35.720
difference was the the audience so while
00:01:35.720 --> 00:01:37.580
I expect more developers here the other
00:01:37.580 --> 00:01:39.259
audience was more and hackers and
00:01:39.259 --> 00:01:42.640
business people so I try to get them
00:01:42.640 --> 00:01:45.800
from where they are and the main question
00:01:45.800 --> 00:01:48.382
usually is "are we there yet?" right
00:01:48.382 --> 00:01:50.842
so about me you probably
00:01:50.842 --> 00:01:52.960
seen this before I'm a code auditor by
00:01:52.960 --> 00:01:55.479
trade I have a small company and
00:01:55.229 --> 00:01:57.230
companies show us their code and I show
00:01:57.230 --> 00:02:00.190
them bugs I find in them quite easy
00:02:01.911 --> 00:02:04.000
but before we start I have a small
00:02:04.000 --> 00:02:06.500
celebration to do this actually happened
00:02:06.500 --> 00:02:09.230
just a day before the first time I
00:02:09.230 --> 00:02:11.680
talked about this so Kaspersky
00:02:11.680 --> 00:02:15.440
message they found some malware introduced
00:02:15.440 --> 00:02:16.540
tied to libc
00:02:16.540 --> 00:02:18.340
which I have written so this is
00:02:18.340 --> 00:02:19.270
like a
00:02:19.270 --> 00:02:26.430
applause
00:02:27.257 --> 00:02:28.999
some of the malware people
00:02:28.999 --> 00:02:31.020
know what's good
00:02:31.020 --> 00:02:33.430
so basically the main question when I
00:02:33.430 --> 00:02:35.769
talk to customers is we spend so much
00:02:35.769 --> 00:02:38.860
money on this why isn't it working
00:02:38.860 --> 00:02:42.399
and the answer is you're doing it wrong
00:02:42.399 --> 00:02:46.420
so I will try to show now what exactly
is wrong
00:02:46.420 --> 00:02:49.830
and there's a small preface here people
00:02:49.830 --> 00:02:51.730
usually say there's no time to do this
00:02:51.730 --> 00:02:54.230
right and that's just wrong you have
00:02:54.230 --> 00:02:56.580
exactly as much time per day as other
00:02:56.580 --> 00:02:58.640
people who did great things so you can
00:02:58.640 --> 00:03:01.780
do great things too you just need to do it
00:03:02.620 --> 00:03:05.420
so let's play a little warm-up game
00:03:05.420 --> 00:03:07.050
it's called how it started and how
00:03:07.050 --> 00:03:09.570
it's going so let's have a demo round
00:03:09.570 --> 00:03:11.420
IBM Watson is revolutionizing
00:03:11.420 --> 00:03:14.839
10 Industries and it's going like this
00:03:14.839 --> 00:03:17.219
whatever happened to IBM Watson that's a
00:03:17.219 --> 00:03:19.629
typical pattern in the security industry
00:03:19.629 --> 00:03:23.150
right so here's another one how it started
00:03:23.150 --> 00:03:25.480
revolutionize security with AI
00:03:25.480 --> 00:03:27.261
right we all know where this is going
00:03:27.261 --> 00:03:28.461
laugther
00:03:28.461 --> 00:03:31.230
right so that's the pattern
00:03:31.230 --> 00:03:33.640
let's play IT security mine sweeper
00:03:33.390 --> 00:03:35.256
right so everybody here probably
00:03:35.256 --> 00:03:37.349
knows who Gartner is they publish
00:03:37.349 --> 00:03:39.379
recommendations and they even have a
00:03:39.379 --> 00:03:41.249
voting section where people can say
00:03:41.249 --> 00:03:43.159
this is the best product in this section
00:03:42.909 --> 00:03:45.248
right so let's look at a few of them and
00:03:45.248 --> 00:03:48.040
see what happened to people who trusted
Gartner
00:03:48.040 --> 00:03:51.020
first is a firewall right so how
00:03:51.020 --> 00:03:54.247
it started the number one recommendation
00:03:54.247 --> 00:03:57.175
is for Fortinet and they have a lot of
00:03:57.175 --> 00:03:59.425
marketing gibberish
00:03:59.425 --> 00:04:01.229
laughter
00:04:01.229 --> 00:04:03.159
and if you look how it's going it's not
00:04:03.159 --> 00:04:05.300
going so good
00:04:05.850 --> 00:04:08.090
so let's extend the pattern a bit
00:04:08.090 --> 00:04:10.420
why what happened to me in this regard
00:04:10.420 --> 00:04:11.750
so I don't need a firewall
00:04:11.750 --> 00:04:14.270
I don't have any ports open that I need
blocking right
00:04:14.270 --> 00:04:16.120
so you don't need this
00:04:16.120 --> 00:04:18.559
strictly speaking you don't need it
00:04:18.559 --> 00:04:20.479
next discipline endpoint protection
00:04:20.479 --> 00:04:24.519
so it started with Trellix this is the
00:04:24.519 --> 00:04:26.773
number one recommendation on Gartner
00:04:26.773 --> 00:04:28.769
I hadn't heard of them there like can make
00:04:28.769 --> 00:04:30.429
a feed joint venture or something
00:04:30.429 --> 00:04:31.434
who cares
00:04:31.434 --> 00:04:34.543
they also have great marketing gibberish
00:04:34.543 --> 00:04:36.304
and then if you look at what happened
00:04:36.304 --> 00:04:39.214
it's like they made it worse
00:04:39.214 --> 00:04:42.955
okay so this didn't apply to me
00:04:42.955 --> 00:04:45.305
either because I don't use snake oil
00:04:45.305 --> 00:04:47.295
let's see the third one password manager
00:04:47.295 --> 00:04:48.530
also very popular
00:04:49.730 --> 00:04:52.320
how it started recommended LastPass
00:04:52.320 --> 00:04:54.250
you probably know where this is going
00:04:54.250 --> 00:04:55.747
laugther
00:04:57.129 --> 00:04:59.710
yeah they got owned and then
00:04:59.710 --> 00:05:00.892
people got owned
00:05:02.502 --> 00:05:05.241
so you may notice a pattern here
00:05:05.436 --> 00:05:06.916
this didn't apply to me because
00:05:06.916 --> 00:05:08.916
I deserve a password authentication use
00:05:08.916 --> 00:05:10.810
public key which has been available for
00:05:10.810 --> 00:05:14.150
decades right so small bonus
00:05:14.150 --> 00:05:17.109
the last one 2FA
00:05:17.609 --> 00:05:19.789
Gartner recommends Duo which has
00:05:19.789 --> 00:05:22.039
been bought by Cisco but doesn't matter
00:05:23.589 --> 00:05:25.414
so if you look at what Duo does
00:05:25.414 --> 00:05:27.378
your server asks the cloud for
00:05:27.378 --> 00:05:29.877
permission the cloud goes to the telephone
00:05:29.877 --> 00:05:33.590
telephone shows a popup you click yes
00:05:31.590 --> 00:05:35.100
and then the cloud tells the server it's
00:05:35.100 --> 00:05:37.470
okay you can let them in if you look
00:05:37.470 --> 00:05:39.360
really closely you can notice the cloud
00:05:39.360 --> 00:05:41.520
doesn't have to do the popup it can just
00:05:41.520 --> 00:05:43.871
say sure so this comes pre-owned
00:05:43.871 --> 00:05:45.952
there is no need to hack anything here
00:05:45.952 --> 00:05:47.452
laugther
00:05:47.452 --> 00:05:48.980
and something many people don't
00:05:48.980 --> 00:05:50.596
realize you don't need two factor
00:05:50.596 --> 00:05:53.410
if you have public key that's already the
second factor
00:05:53.944 --> 00:05:55.109
Okay, so
00:05:55.789 --> 00:05:57.808
yeah let's skip over this briefly
00:05:57.808 --> 00:06:00.318
Splunk is the the recommend option here
00:06:00.318 --> 00:06:02.038
and they make the organization
00:06:02.038 --> 00:06:04.438
more resilient unless you install it
00:06:04.438 --> 00:06:07.279
laughter
00:06:07.279 --> 00:06:15.543
applause
00:06:15.543 --> 00:06:17.812
okay so this one is dear to my heart
00:06:17.812 --> 00:06:20.713
because people start arguing about
00:06:20.713 --> 00:06:22.453
whether to install patches and
00:06:22.453 --> 00:06:25.093
which patch to install first and it used
00:06:25.093 --> 00:06:27.683
to be simple you look for problems
00:06:27.683 --> 00:06:29.443
then you install the patches and then
00:06:29.443 --> 00:06:31.533
it got a bit more complicated and
00:06:31.533 --> 00:06:33.423
the result is this right
00:06:33.423 --> 00:06:36.173
that's a famous podcast in Germany
00:06:36.173 --> 00:06:38.693
it's about municipality who got owned
00:06:38.693 --> 00:06:41.673
by ransomware and then had to call the
00:06:41.673 --> 00:06:42.943
army for help
00:06:42.943 --> 00:06:44.460
inaudible chatter in crowd
00:06:44.460 --> 00:06:46.510
and what you should do I'm having
00:06:46.510 --> 00:06:48.470
this for completeness install all patches
00:06:48.470 --> 00:06:50.430
immediately but that's a separate talk
00:06:50.430 --> 00:06:52.705
right so you may notice a pattern here
00:06:52.705 --> 00:06:54.450
the IT security industry
00:06:54.450 --> 00:06:55.630
recommends something and
00:06:55.630 --> 00:06:58.274
if you do it you're [ __ ] so don't do it
00:06:58.274 --> 00:07:01.000
in case you can't read this says snake
00:07:01.000 --> 00:07:03.460
repellent granules and then there's a
00:07:03.460 --> 00:07:05.060
snake sleeping next to it
00:07:05.060 --> 00:07:06.111
laugther
00:07:06.111 --> 00:07:07.390
coughing
00:07:07.921 --> 00:07:10.670
right so if we can't trust the
00:07:10.670 --> 00:07:12.911
recommendations of the industry what
shall we do
00:07:13.449 --> 00:07:15.049
and so I had a lot of
00:07:15.049 --> 00:07:16.929
time on my hands because I didn't have
00:07:16.929 --> 00:07:19.510
to clean up after crappy IT security
00:07:19.510 --> 00:07:21.570
industry recommendations so what
00:07:21.570 --> 00:07:23.770
what did I do with my time
00:07:24.210 --> 00:07:26.630
and I decided I need a Blog
00:07:26.630 --> 00:07:30.440
some time ago now and I started
00:07:30.440 --> 00:07:32.660
thinking what do I need and it's
00:07:32.660 --> 00:07:34.570
actually not that much I could have just
00:07:34.570 --> 00:07:37.590
shown basically static content a little
00:07:37.590 --> 00:07:39.727
search function would be good but it's
00:07:39.727 --> 00:07:42.530
optional um I didn't need comments for
00:07:42.530 --> 00:07:44.920
legal reasons because people start
00:07:44.920 --> 00:07:48.390
posting like links to maware or
00:07:48.390 --> 00:07:50.230
whatever I don't want that I don't
00:07:50.230 --> 00:07:52.162
need that right so the first version was
00:07:52.162 --> 00:07:53.950
actually really easy it was a small
00:07:53.950 --> 00:07:56.141
standard web server and I had the
00:07:56.141 --> 00:07:58.219
blog entries a static HTML files
00:07:58.219 --> 00:08:00.199
one file per month it was actually really
00:08:00.199 --> 00:08:02.090
easy if you want to search you just can
00:08:02.090 --> 00:08:04.870
ask Google and limit it to my site so
00:08:04.870 --> 00:08:07.229
posting was also easy had a little
00:08:07.229 --> 00:08:09.699
script that I could run on the server
00:08:09.699 --> 00:08:12.924
and I just SSH in and SSH I trust for
00:08:12.924 --> 00:08:14.824
authentication so there's no new attack
00:08:14.824 --> 00:08:17.445
surface I have that anyway and this is a
00:08:17.445 --> 00:08:20.074
great design it's secure it's simple
00:08:20.074 --> 00:08:22.190
there's low risk it's also high
00:08:22.190 --> 00:08:24.779
performance but you couldn't do a talk
00:08:24.779 --> 00:08:27.270
about it at the CCC right so
00:08:27.270 --> 00:08:30.130
it's too boring so I started to introduce
00:08:30.130 --> 00:08:31.200
risk in my setup
00:08:31.200 --> 00:08:33.640
*laughter
00:08:34.400 --> 00:08:36.410
so the first idea was I had
00:08:36.410 --> 00:08:38.280
written a small web server I could just
00:08:38.280 --> 00:08:40.360
implement the blog in the web server
00:08:40.360 --> 00:08:43.384
because you know it's my code anyway
00:08:43.384 --> 00:08:46.796
but that has downsides if the the blog
00:08:46.796 --> 00:08:48.935
is running in the web server then it can
00:08:48.935 --> 00:08:50.846
access all the memory of the web server
00:08:50.846 --> 00:08:52.776
in particular it can see the TLS private
00:08:52.776 --> 00:08:55.166
key and that I don't want people to
00:08:55.166 --> 00:08:57.856
extract right so it can't be a module
00:08:57.856 --> 00:09:00.056
in the web server
00:09:00.480 --> 00:09:03.030
and the the obvious solution is
00:09:03.030 --> 00:09:05.510
it has to run in a different user ID on
00:09:05.510 --> 00:09:08.090
on Linux I'm using Linux or but any
00:09:08.090 --> 00:09:09.810
Unix or Windows would be the same
00:09:09.810 --> 00:09:11.860
basically it runs in a different user ID
00:09:11.860 --> 00:09:13.940
and then if you if you take over the
00:09:13.940 --> 00:09:15.989
process of the blog because there's some
00:09:15.989 --> 00:09:18.680
bug in it you couldn't access the TLS
00:09:18.680 --> 00:09:21.770
key and while I did that the industry
00:09:21.770 --> 00:09:23.049
was doing this
00:09:23.049 --> 00:09:23.759
chatter
00:09:23.759 --> 00:09:25.429
that's like the running gag of this
00:09:25.429 --> 00:09:27.520
talk I show all kinds of interesting
00:09:27.520 --> 00:09:29.280
things the industry did and then show
00:09:29.280 --> 00:09:31.209
what I did in that time right so
00:09:31.939 --> 00:09:32.828
next question
00:09:32.828 --> 00:09:34.749
where's the content I could just have
00:09:34.749 --> 00:09:37.418
files on disk like static HTML as before
00:09:37.418 --> 00:09:39.819
but I think that's not professional enough
00:09:39.569 --> 00:09:41.829
right so for a good CCC talk you
00:09:41.829 --> 00:09:44.059
need to be more professional
00:09:44.059 --> 00:09:45.260
also for a different
00:09:45.260 --> 00:09:47.488
project I had just written an LDAP server
00:09:47.488 --> 00:09:50.543
so I decided to reuse it and
00:09:50.543 --> 00:09:52.400
while I did that the industry did this
00:09:52.400 --> 00:09:54.080
I took this photo at the airport of
00:09:53.830 --> 00:09:55.731
Jerusalem so this is an actual ad it's
00:09:55.731 --> 00:09:57.210
not photoshopped right it's for
00:09:57.210 --> 00:09:59.040
Northrop Grumman which is a
00:09:59.040 --> 00:10:02.760
military contractor and it's about full
00:10:02.760 --> 00:10:05.700
spectrum cyber across all domains
00:10:05.700 --> 00:10:06.933
chatter
00:10:06.933 --> 00:10:09.770
so why would I write my own LDAP server
00:10:09.770 --> 00:10:11.870
mostly because it's small and
00:10:11.870 --> 00:10:14.650
because I'm an auditor by trade I know
00:10:14.650 --> 00:10:17.630
that if you want a chance to actually
00:10:17.630 --> 00:10:19.570
audit the code it needs to be small
00:10:19.570 --> 00:10:22.039
because that's a limited resource
00:10:22.039 --> 00:10:24.110
the time you can spend on auditing code
00:10:24.110 --> 00:10:27.419
right so Postgres is a common SQL
00:10:27.419 --> 00:10:30.122
database slapped in the the open LDAP
00:10:30.122 --> 00:10:32.621
implementation of the server and tinyldap
00:10:32.621 --> 00:10:35.112
is mine and you see it's much slower
00:10:35.112 --> 00:10:36.630
and much smaller
00:10:38.750 --> 00:10:40.609
yeah so there was more to this
00:10:40.609 --> 00:10:43.760
ad campaign I collected a few funny images
00:10:45.080 --> 00:10:48.959
right so um if someone manages to
00:10:48.709 --> 00:10:52.069
hack the blog CGI or whatever module
00:10:52.069 --> 00:10:54.779
I use to to have connect the blog to the
00:10:54.779 --> 00:10:57.399
web server they can open any file that
00:10:57.399 --> 00:11:00.280
the blog can read right the UID can read
00:11:00.280 --> 00:11:02.820
so I should probably do something
00:11:02.820 --> 00:11:05.510
about that that was the next step and
00:11:05.510 --> 00:11:07.690
the industry was starting to think about
00:11:07.690 --> 00:11:09.180
vulnerability management
00:11:11.070 --> 00:11:13.360
so there is a mechanism on Unix
00:11:13.360 --> 00:11:15.450
on Linux I did a separate talk about that
00:11:15.450 --> 00:11:16.630
on the last Congress
00:11:16.630 --> 00:11:19.132
it's called seccomp and seccomp it's like
00:11:19.132 --> 00:11:21.371
a firewall for sys calls so I can use
00:11:21.371 --> 00:11:24.372
seccomp to block open the open sys which
00:11:24.372 --> 00:11:26.812
is used to open files but if I have
00:11:26.812 --> 00:11:29.092
to use open myself
00:11:29.092 --> 00:11:31.722
then I can't block it right so what
00:11:31.722 --> 00:11:33.452
to do about that for example my blog
00:11:33.452 --> 00:11:35.672
calls local time which converts Unix's
00:11:35.672 --> 00:11:38.092
time into the local time zone and for
00:11:38.092 --> 00:11:40.372
that it opens a file containing the
00:11:40.372 --> 00:11:43.826
description of the system time zone
00:11:43.826 --> 00:11:46.646
and that calls open right so if
00:11:46.646 --> 00:11:49.332
I just disabled the open system call from
00:11:49.332 --> 00:11:51.057
my blog then it couldn't do the time
00:11:51.057 --> 00:11:54.356
translation and this is actually
00:11:54.356 --> 00:11:57.506
an old problem that also applies to set
00:11:57.506 --> 00:12:00.108
ID programs and has has applied to them
00:12:00.108 --> 00:12:03.027
for decades so what you can do is you
00:12:03.027 --> 00:12:05.818
can reorganize your code so before you
00:12:05.818 --> 00:12:08.478
block or before you drop privileges
00:12:08.478 --> 00:12:11.356
generally speaking you do the open
00:12:11.356 --> 00:12:14.158
calls in this in this example and
00:12:14.158 --> 00:12:16.597
then you disable open and then you look
00:12:16.597 --> 00:12:18.970
at the the data provided by the attacker
00:12:18.970 --> 00:12:21.079
because if the attacker or any untrusted
00:12:21.079 --> 00:12:23.590
source is trying to hack you it is via
00:12:23.590 --> 00:12:25.704
data it gives you right it's
00:12:25.704 --> 00:12:27.884
the environment is compromised so you look
00:12:27.884 --> 00:12:29.844
at what kind of uh elements in the
00:12:29.844 --> 00:12:31.764
environment are attacker supplied and
00:12:31.764 --> 00:12:33.804
before you look at a single byte in them
00:12:33.804 --> 00:12:35.924
you do all the dangerous stuff if you can
00:12:35.924 --> 00:12:38.203
right so in this case I call local
00:12:38.203 --> 00:12:42.213
time once before I drop the open sys call
00:12:42.213 --> 00:12:44.904
and then my libc will cache the
00:12:44.904 --> 00:12:47.938
time zone data and the next time I call it
00:12:47.938 --> 00:12:49.868
after I have looked at the attacker
00:12:49.868 --> 00:12:51.877
supplied code there is no need to call
00:12:51.877 --> 00:12:53.988
open right so that's a major advantage
00:12:53.988 --> 00:12:57.488
of Secom over similar Technologies like
00:12:57.488 --> 00:13:03.200
SELinux where all the prohibitions
00:13:03.200 --> 00:13:04.450
on sys calls are
00:13:04.450 --> 00:13:06.850
applied to the whole process so there is
00:13:06.850 --> 00:13:08.656
this is an example and you should make
00:13:08.656 --> 00:13:10.249
use of it you should look at your
00:13:10.249 --> 00:13:12.120
process and you can see if you have the
00:13:12.120 --> 00:13:13.944
source code at least you can see which
00:13:13.944 --> 00:13:16.249
parts do I need to do before I can drop
00:13:16.249 --> 00:13:18.689
privileges and you move them up right so
00:13:18.689 --> 00:13:19.849
that's what I did
00:13:22.120 --> 00:13:24.669
this is actually a mockup from
00:13:24.669 --> 00:13:27.450
the Estonian cyber security center
00:13:28.760 --> 00:13:29.962
so this is real
00:13:30.952 --> 00:13:31.952
okay so
00:13:31.952 --> 00:13:34.959
next thought so let's
00:13:34.959 --> 00:13:38.129
say someone hacks the blog module and
00:13:38.129 --> 00:13:40.400
someone else uses the same module but
00:13:40.400 --> 00:13:43.141
supplies a password right
00:13:43.141 --> 00:13:44.955
this is a common problem in website
00:13:44.955 --> 00:13:46.845
in websites there's some kind of login
00:13:46.845 --> 00:13:48.704
something you get maybe a session token
00:13:48.704 --> 00:13:51.514
or whatever and if someone manages to
00:13:51.514 --> 00:13:54.024
take over the middleware
00:13:54.024 --> 00:13:55.574
or like the server component
00:13:55.584 --> 00:13:58.891
they can see all other connections too
00:13:58.891 --> 00:14:00.420
if they are handled by the same
00:14:00.420 --> 00:14:03.460
process right that's a major problem
00:14:03.460 --> 00:14:06.340
and you can do something about it
00:14:06.340 --> 00:14:08.312
so that's the good news here
00:14:09.682 --> 00:14:13.019
and in my example it led to me using CGI
00:14:13.019 --> 00:14:15.599
instead of fast CGI which is fast CGI
00:14:15.599 --> 00:14:17.953
is a newer version of CGI
00:14:17.953 --> 00:14:20.910
and the idea with fast CGI is that you
00:14:20.910 --> 00:14:24.189
don't spawn a new process for every
00:14:24.189 --> 00:14:26.877
request but you have like a Unix domain
00:14:26.877 --> 00:14:29.890
socket or another socket to a fast CGI
00:14:29.890 --> 00:14:32.180
process and that opens maybe a threat
00:14:32.180 --> 00:14:35.550
per request or something but usually
00:14:35.550 --> 00:14:37.450
in fast CGI you try to handle the
00:14:37.450 --> 00:14:39.440
requests in the same process and then
00:14:39.440 --> 00:14:41.590
you can use that process to cach data so
00:14:41.590 --> 00:14:45.140
there's a perf advantage to using fast CGI
00:14:45.140 --> 00:14:47.300
but for security reasons I don't
00:14:47.300 --> 00:14:50.220
I don't use fast CGI so I can't do
00:14:50.220 --> 00:14:52.700
caching right so that's a major downside
00:14:52.700 --> 00:14:54.450
and you would expect the block to be
00:14:54.450 --> 00:14:56.790
really really slow in the end so
00:14:56.790 --> 00:14:59.139
first thing I need to use CGI instead of
00:14:59.139 --> 00:15:01.949
fast CGI and secondly you could still
00:15:01.949 --> 00:15:05.159
use debug APIs so if you use GDB or
00:15:05.159 --> 00:15:07.700
another debugger to to look at another
00:15:07.700 --> 00:15:10.199
process they use an API called ptrace
00:15:10.199 --> 00:15:12.860
but that's a sys call so I can use seccomp
00:15:12.860 --> 00:15:16.394
to disallow ptrace if I do those two
00:15:16.394 --> 00:15:20.299
and the attacker takes over a blog process
00:15:20.299 --> 00:15:22.529
all they can see is the data they supply
00:15:22.529 --> 00:15:26.840
themselves right that's a major advantage
00:15:27.879 --> 00:15:30.079
Okay so ENISA is actually an EU agency
00:15:30.079 --> 00:15:31.569
which I find really disturbing
00:15:31.569 --> 00:15:33.480
because they're burning lots of taxpayer
00:15:33.480 --> 00:15:38.302
money anyway so let's assume the attacker
00:15:38.302 --> 00:15:41.013
can hack my blog they can sill circumvent
00:15:41.013 --> 00:15:43.333
any access control I do in the blog
00:15:43.333 --> 00:15:46.302
so for example if I have an admin site
00:15:46.302 --> 00:15:49.453
or some login site part of the webiste
00:15:49.453 --> 00:15:52.128
and it's handled through the same program
00:15:52.128 --> 00:15:55.069
and the access control is done in the blog
00:15:55.069 --> 00:15:56.939
CGI and someone manages
00:15:56.939 --> 00:15:59.190
to hack my blog CGI they could
00:15:59.190 --> 00:16:03.280
just skip that so it's really hard
00:16:03.280 --> 00:16:05.640
to do access restrictions that can be
00:16:05.640 --> 00:16:07.817
circumvented if you do them in your own
00:16:07.817 --> 00:16:09.972
code so the solution is not do it in
00:16:09.972 --> 00:16:13.421
your own code I don't do any access
00:16:13.421 --> 00:16:15.702
restriction in the blog I do it in the
00:16:15.702 --> 00:16:18.431
LDAP server so if you connect to my blog
00:16:18.431 --> 00:16:20.525
and supply a password then the blog
00:16:20.525 --> 00:16:22.000
doesn't know if the password is
00:16:22.000 --> 00:16:24.400
right or not there's an for example
00:16:24.400 --> 00:16:26.216
there's an interface where you can add
00:16:26.216 --> 00:16:28.130
new block entries or you can edit an old
00:16:28.130 --> 00:16:29.739
one and for you need to supply
00:16:29.739 --> 00:16:31.740
credentials but the block CGI doesn't know
00:16:31.740 --> 00:16:33.404
if they are right or not it opens
00:16:33.404 --> 00:16:35.264
the connections to the LDAP server with
00:16:35.264 --> 00:16:37.344
that credential and then the LDAP server
00:16:37.344 --> 00:16:40.853
says yes or no so since we removed
00:16:40.853 --> 00:16:44.434
access to the ptraces calls and the
00:16:44.434 --> 00:16:46.613
processes are isolated from each other
00:16:46.613 --> 00:16:48.234
that means there is nothing to
00:16:48.234 --> 00:16:50.394
circumvent here so if someone hacks my
00:16:50.394 --> 00:16:52.733
blog the only advantage they get is
00:16:52.733 --> 00:16:54.769
they can do the exact same stuff they
00:16:54.769 --> 00:16:56.628
could do before basically they can just
00:16:56.628 --> 00:16:58.038
talk to the LDAP server
00:16:59.628 --> 00:17:01.229
okay so I'm starting to get into
00:17:01.229 --> 00:17:04.243
James Bond territory here right
00:17:04.243 --> 00:17:05.874
with the attacks they getting more
00:17:05.874 --> 00:17:08.884
convoluted right so the industry started
00:17:08.884 --> 00:17:10.653
doing threat intelligence feeds which
00:17:10.653 --> 00:17:12.634
are useless don't spend money on those
00:17:13.100 --> 00:17:15.820
okay so let's say the attacker hacked my
00:17:15.820 --> 00:17:19.070
blog and then went to my tinyldap and now
00:17:19.070 --> 00:17:21.820
is attacking tinyldap then they can
00:17:21.820 --> 00:17:24.060
watch other logins because tinyldap
00:17:24.060 --> 00:17:26.552
handles connections from other instances
00:17:26.552 --> 00:17:28.970
of the blog too right so the same
00:17:28.970 --> 00:17:30.840
problem we had before we just moved the
00:17:30.840 --> 00:17:33.119
goal post a little and we need to
00:17:33.119 --> 00:17:36.029
prevent this and the obvious solution
00:17:36.029 --> 00:17:38.118
is to do the same thing we did
00:17:38.118 --> 00:17:41.369
with the blog we have one process of
00:17:41.369 --> 00:17:44.794
the LDAP server per request and then we
00:17:44.794 --> 00:17:48.793
just allow ptrace right so now you
00:17:48.793 --> 00:17:51.349
can't watch even if you get code execution
00:17:51.349 --> 00:17:53.590
inside the LDAP server you can't watch
00:17:53.590 --> 00:17:55.520
what passwords other people use
00:17:55.520 --> 00:17:58.614
you can still see okay the industry
00:17:58.614 --> 00:18:01.150
does some [ __ ] again you can still see
00:18:01.150 --> 00:18:04.216
the password in the LDAP store right so
00:18:04.216 --> 00:18:06.196
the LDAP server has to have a version of
00:18:06.196 --> 00:18:08.277
the password to authenticate against and
00:18:08.277 --> 00:18:11.000
the industry practice best practice is to
00:18:11.000 --> 00:18:12.820
use salted hashes so the password is
00:18:12.820 --> 00:18:14.083
not actually in the store
00:18:14.569 --> 00:18:17.169
still if someone manages to attack
00:18:17.169 --> 00:18:19.749
tinyldap through the blog they can
00:18:19.749 --> 00:18:21.689
extract the hashes and try to crack them
00:18:21.689 --> 00:18:24.728
but since I'm the only one adding users
00:18:24.728 --> 00:18:27.530
I can control the password complexity so
00:18:27.530 --> 00:18:29.780
good luck brute forcing that right
00:18:32.410 --> 00:18:37.729
okay so this is actually a real problem
00:18:37.729 --> 00:18:39.400
not for my blog specifically
00:18:39.400 --> 00:18:41.597
but for other web services or services
00:18:41.597 --> 00:18:43.310
that are reachable from the internet
00:18:43.310 --> 00:18:45.259
what if an attacker doesn't want to steal
00:18:45.259 --> 00:18:47.762
my data but it wants to encrypt it
00:18:47.762 --> 00:18:50.052
so the ransomware what can you do
00:18:50.052 --> 00:18:53.866
about that and my idea was to make
00:18:53.866 --> 00:18:55.916
the data store read only so the
00:18:55.916 --> 00:18:58.075
LDAP server has a data store that contains
00:18:58.075 --> 00:19:00.555
all the blog entries and let's read only
00:19:00.555 --> 00:19:03.046
to the add up process you can only read
00:19:03.046 --> 00:19:05.129
from it and if you want to write to it
00:19:05.129 --> 00:19:08.248
for example to add a new entry it gets
00:19:08.248 --> 00:19:10.279
appended to a second file which I call the
00:19:10.279 --> 00:19:13.300
journal so SQL databases have a similar
00:19:13.300 --> 00:19:15.670
concept and they use it to roll back
00:19:15.670 --> 00:19:17.650
transactions I can do the same thing
00:19:17.650 --> 00:19:19.160
it's basically a log file
00:19:19.160 --> 00:19:23.045
and that means all the differences from
00:19:23.045 --> 00:19:25.526
the last time the store was created
00:19:25.526 --> 00:19:27.626
the read only store all the differences
00:19:27.626 --> 00:19:29.646
are sequentially in the log file
00:19:29.646 --> 00:19:32.647
in the journal so that the performance
00:19:32.647 --> 00:19:34.847
gets worse the bigger the journal gets
00:19:34.847 --> 00:19:37.330
so every now and then I need to combine
00:19:37.330 --> 00:19:39.538
the read only part and the journal
00:19:39.538 --> 00:19:41.786
a new bigger read only part and
00:19:41.786 --> 00:19:43.466
I do that manually
00:19:45.729 --> 00:19:48.470
because tinyldap couldn't do it because
00:19:48.470 --> 00:19:50.469
I didn't allow tinyldap to write the store
00:19:50.469 --> 00:19:52.450
right that was part of the security here
00:19:53.010 --> 00:19:56.510
and so with seccomp I can just disable
00:19:56.510 --> 00:19:59.000
sys calls I can also install filters so I
00:19:59.000 --> 00:20:01.136
can say open is allowed but only if you
00:20:01.136 --> 00:20:03.449
use O_APPEND O_APPEND in the open sys
00:20:03.449 --> 00:20:06.440
call on Unix means every right you do to
00:20:06.440 --> 00:20:09.126
this descriptor is automatically
00:20:09.126 --> 00:20:12.425
added to the end so I know if someone
00:20:12.425 --> 00:20:16.026
manages to to access the tinyldap
00:20:16.026 --> 00:20:18.815
binary and can write to my journal then
00:20:18.815 --> 00:20:21.046
the only place the changes can show up
00:20:21.046 --> 00:20:23.176
is at the end and that's actually a really
00:20:23.176 --> 00:20:25.316
good thing to have because it means
00:20:25.316 --> 00:20:27.756
if someone hacks me and adds junk to
00:20:27.756 --> 00:20:30.002
my blog I can only remove at the end
00:20:30.002 --> 00:20:32.642
and I'm good again compare that to a
00:20:32.642 --> 00:20:35.372
usual SQL database if someone wrote
00:20:35.372 --> 00:20:38.221
to the database you need to in to play
00:20:38.221 --> 00:20:41.176
a backup uh in to restore backup because
00:20:41.176 --> 00:20:43.146
they could have changed anything anywhere
00:20:43.366 --> 00:20:45.476
right so but tinyldap doesn't even have
00:20:45.476 --> 00:20:47.336
file system level permissions to change
00:20:47.336 --> 00:20:48.906
anything in the store so I can
00:20:48.906 --> 00:20:51.125
re-sleep soundly
00:20:51.630 --> 00:20:53.623
yeah the industry spent money on
00:20:53.623 --> 00:20:55.503
cyber security mesh architecture
00:20:57.160 --> 00:20:59.380
right so the journal integration has
00:20:59.380 --> 00:21:01.420
to be done by me manually out of band
00:21:01.420 --> 00:21:04.130
so it's not something an automated process
00:21:04.130 --> 00:21:06.100
does I do it manually
00:21:06.100 --> 00:21:07.819
and when I'm doing it
00:21:08.340 --> 00:21:10.360
because it's not that much data it's
00:21:10.360 --> 00:21:12.420
like for a week or two I can just read it
00:21:12.420 --> 00:21:14.600
again and see if something doesn't look
00:21:14.600 --> 00:21:19.120
right this may not be available to all
00:21:19.120 --> 00:21:20.990
other scenarios but you have to
00:21:20.990 --> 00:21:22.759
realize if you have bigger data it's
00:21:22.759 --> 00:21:25.119
usually not all the data that's big
00:21:25.119 --> 00:21:27.140
most of it is usually static and read only
00:21:27.140 --> 00:21:30.000
and then you have some logs that are
00:21:30.000 --> 00:21:32.750
you know billing data that grows and grows
00:21:32.750 --> 00:21:35.149
but usually there's part of the data and
00:21:35.149 --> 00:21:38.540
this is the part with the you know
00:21:38.540 --> 00:21:41.589
identifying information personally or
00:21:41.589 --> 00:21:45.520
billing details that stuff is usually
00:21:45.520 --> 00:21:48.120
small and mostly static and you could
00:21:48.120 --> 00:21:51.440
use this strategy for that too
00:21:53.170 --> 00:21:56.629
well yeah okay
00:21:57.079 --> 00:21:59.320
so the attacker can still write garbage
00:21:59.320 --> 00:22:01.389
to my blog that's still not good
00:22:01.389 --> 00:22:03.730
right but since all they can do is append
00:22:03.730 --> 00:22:06.481
to the journal I can use my text editor
00:22:06.481 --> 00:22:09.001
open the journal and truncate at some
00:22:09.001 --> 00:22:11.434
point and then I get all my data back
00:22:11.434 --> 00:22:13.784
till the point where they start to [???]
00:22:13.784 --> 00:22:16.234
the blog right this is still bad but
00:22:16.234 --> 00:22:18.620
it's a very good position to be in
00:22:18.620 --> 00:22:21.139
if there's an emergency because you
00:22:21.139 --> 00:22:23.750
can basically investigate calmly first
00:22:23.750 --> 00:22:26.240
you turn off right write access then you
00:22:26.240 --> 00:22:29.439
delete the vandalism and the journal
00:22:29.439 --> 00:22:32.599
and you know you haven't lost anything
00:22:32.599 --> 00:22:34.740
because if you want to delete an entry
00:22:34.740 --> 00:22:36.890
in the blog you could do that too but
00:22:36.890 --> 00:22:38.930
that means at the end of the journal you
00:22:38.940 --> 00:22:41.200
append a statement saying delete this
00:22:41.200 --> 00:22:43.313
record and I can just remove that and I
00:22:43.313 --> 00:22:45.730
get the record back right so there's no
00:22:45.730 --> 00:22:48.820
way for someone vandalizing my blog to
00:22:48.820 --> 00:22:50.940
damage any data that was in it before
00:22:50.940 --> 00:22:53.620
all they can do is append junk at the end
00:22:53.620 --> 00:22:56.020
and I can live with that right this is
00:22:56.020 --> 00:22:58.390
this is should be the guiding thought
00:22:58.390 --> 00:23:00.670
between any security you do
00:23:00.670 --> 00:23:03.279
if someone hacks you will be in a very
00:23:03.279 --> 00:23:05.440
stressful position the boss will be
00:23:05.440 --> 00:23:07.749
behind you breathing down your neck are
00:23:07.749 --> 00:23:09.889
we done yet? is it fixed? and you want to
00:23:09.889 --> 00:23:12.410
have as little to do as possible at that
00:23:12.410 --> 00:23:14.672
time you want to to move all the stress
00:23:14.672 --> 00:23:17.279
to before you get hacked because then
00:23:17.279 --> 00:23:18.740
you have more time
00:23:19.840 --> 00:23:22.080
okay the industry did other things again
00:23:24.760 --> 00:23:27.940
so what if the attacker doesn't write
00:23:27.940 --> 00:23:30.452
garbage to the journal but writes some
00:23:30.452 --> 00:23:33.111
exploit to the journal that the next
00:23:33.111 --> 00:23:35.312
tinyldap up instance that reads the
00:23:35.312 --> 00:23:37.982
journal gets compromised by it
00:23:39.430 --> 00:23:42.699
that is a possibility and that would be
00:23:42.699 --> 00:23:45.909
bad so agreed that there still a problem
00:23:46.409 --> 00:23:49.595
but realize how preposterous the scenario
00:23:49.595 --> 00:23:51.734
is so we are talking about an attacker
00:23:51.734 --> 00:23:54.655
who found stable zero day in the blog
00:23:54.655 --> 00:23:57.105
and then used that and another
00:23:57.105 --> 00:23:59.639
stable zero day in tinyldap up to write
00:23:59.639 --> 00:24:02.281
to the journal and then have the third
00:24:03.051 --> 00:24:06.290
third zero day to compromise the journal
00:24:06.290 --> 00:24:08.706
passing code so I mean
00:24:08.706 --> 00:24:11.266
yes it is still a problem but we reduced
00:24:11.266 --> 00:24:13.800
the risk significantly
00:24:14.160 --> 00:24:15.160
and that is what
00:24:15.160 --> 00:24:18.320
I'm trying to to tell you here it's not
00:24:18.320 --> 00:24:20.704
it's not all or nothing it's good enough
00:24:20.704 --> 00:24:24.077
if you can half the risk that's already
00:24:24.077 --> 00:24:26.040
very important and you should do it
00:24:26.040 --> 00:24:30.620
so as much as you can slice off the risk
00:24:30.620 --> 00:24:32.869
the better the better off you will be
00:24:32.869 --> 00:24:34.389
if something happens
00:24:34.649 --> 00:24:37.698
right because the smaller the code is
00:24:37.698 --> 00:24:40.290
that is still attackable the
00:24:40.290 --> 00:24:42.160
more you can audit it and be sure it's
00:24:42.160 --> 00:24:44.169
good you show it to your friends and
00:24:44.169 --> 00:24:46.679
they can audit it too and you
00:24:46.679 --> 00:24:48.714
need to save yourself that time because
00:24:48.714 --> 00:24:50.714
it happens every now and then that I get
00:24:50.714 --> 00:24:52.904
to get to see the whole code base and
00:24:52.904 --> 00:24:54.554
the usual code base for commercial
00:24:54.554 --> 00:24:57.123
products is like gigabytes of source code
00:24:57.123 --> 00:24:59.523
nobody can read that like
00:24:59.523 --> 00:25:01.207
I'm good I'm not that good
00:25:02.587 --> 00:25:05.407
so this is a good place to be in
00:25:05.407 --> 00:25:07.536
I think right so the industry was selling
00:25:07.536 --> 00:25:10.256
DDOS mitigation sure whatever
00:25:10.326 --> 00:25:11.950
so what happens if someone attacks
00:25:11.950 --> 00:25:14.905
the web server that is still a big
00:25:14.905 --> 00:25:18.261
problem and it's actually
00:25:20.421 --> 00:25:22.562
it's a full damage right
00:25:22.562 --> 00:25:24.231
that's the worst that can happen if
00:25:24.231 --> 00:25:26.151
someone manages to attack the web server
00:25:26.151 --> 00:25:28.431
they can see all traffic coming through
00:25:28.431 --> 00:25:30.421
they can look inside TLS secured
00:25:30.421 --> 00:25:32.307
connections and they can sniff all the
00:25:32.307 --> 00:25:34.721
passwords so that's really bad
00:25:34.979 --> 00:25:36.930
unfortunately there is not too much
00:25:36.930 --> 00:25:38.619
you can do about that
00:25:40.919 --> 00:25:44.256
you could do a separation
00:25:44.256 --> 00:25:46.024
so this is something people have been
00:25:46.024 --> 00:25:47.955
talking about for a while OpenSSL is
00:25:47.955 --> 00:25:49.977
doing this they moved the dangerous crypto
00:25:49.977 --> 00:25:51.914
stuff in a second process and use
00:25:51.914 --> 00:25:54.218
sandboxing to lock down that process
00:25:54.428 --> 00:25:56.289
that could be done but nobody has done
00:25:56.289 --> 00:25:58.649
it for OpenSSL yet so OpenSSL doesn't
00:25:58.649 --> 00:26:00.689
support that my web server
00:26:00.689 --> 00:26:02.929
also supports embed TLS they don't
00:26:02.929 --> 00:26:05.158
support that too so I I could spend time
00:26:05.158 --> 00:26:06.589
on that and I've been actually
00:26:06.589 --> 00:26:09.095
spending some time already but it's not
00:26:09.095 --> 00:26:10.959
it's not ready yet but this would be a
00:26:10.959 --> 00:26:13.279
good way to reduce the risk and you may
00:26:13.279 --> 00:26:15.629
notice that the the tools I'm using to
00:26:15.629 --> 00:26:17.779
reduce risks are actually just a handful
00:26:17.959 --> 00:26:20.704
there's not it's not you know it's not
00:26:20.704 --> 00:26:23.310
witchcraft I'm not inventing new
00:26:23.310 --> 00:26:25.589
ways to look at things I'm doing the
00:26:25.589 --> 00:26:27.776
same thing again I'm identifying the
00:26:27.776 --> 00:26:29.905
part of the code that's dangerous and
00:26:29.905 --> 00:26:32.517
then I think about how I can make that
00:26:32.517 --> 00:26:34.667
part smaller maybe put it in a different
00:26:34.667 --> 00:26:37.296
process lock it down so we need to do
00:26:37.296 --> 00:26:38.936
the same thing with the web server
00:26:38.936 --> 00:26:40.910
obviously but it's an ongoing process
00:26:42.660 --> 00:26:46.710
yeah so again whatever why
00:26:46.710 --> 00:26:49.400
haven't I done that yet uh so in my
00:26:49.400 --> 00:26:51.375
web server you can it's a build time
00:26:51.375 --> 00:26:53.474
decision if you want SSL support or not
00:26:53.474 --> 00:26:55.055
and you can see the binary is
00:26:55.055 --> 00:26:57.525
significantly bigger if you have SSL
00:26:57.525 --> 00:26:59.535
and I'm showing you this because it means
00:26:59.535 --> 00:27:01.805
the bulk of the attack surface is the SSL
00:27:01.805 --> 00:27:04.730
code it's not my code so if I if I can
00:27:04.730 --> 00:27:07.438
put the SSL code in a different process
00:27:07.438 --> 00:27:10.740
they still need to see the private key
00:27:10.740 --> 00:27:12.267
because that's what TLS needs
00:27:12.267 --> 00:27:13.886
the private key otherwise it can't
00:27:13.886 --> 00:27:15.927
do the crypto so the bug of the attack
00:27:15.927 --> 00:27:17.739
surface would still have access to the
00:27:17.739 --> 00:27:19.530
key I can still do it because there
00:27:19.530 --> 00:27:21.480
might be bugs in my code and not the
00:27:21.480 --> 00:27:24.929
SSL code but that's just 5% of the of
00:27:24.929 --> 00:27:27.310
the overall attack surface so
00:27:27.730 --> 00:27:29.843
I will probably do it at some point
00:27:29.843 --> 00:27:32.125
but it's I don't expect miracles from it
00:27:32.125 --> 00:27:35.025
bugs and open SSL will kill me
00:27:35.025 --> 00:27:37.241
there's not much I can do about that
00:27:39.696 --> 00:27:40.696
laughter
00:27:41.820 --> 00:27:44.160
okay so I know what you're thinking
00:27:44.220 --> 00:27:47.390
loud laughter
00:27:47.530 --> 00:27:50.829
what about kernel bugs?
00:27:50.829 --> 00:27:52.455
so I looked at a few of the recent
00:27:52.455 --> 00:27:54.679
kernel bugs and it turns out that they
00:27:54.679 --> 00:27:56.991
usually apply to sys calls that are rarely
00:27:56.991 --> 00:28:00.113
used in regular programs and because
00:28:00.113 --> 00:28:01.930
I'm blocking all the sys calls I don't
00:28:01.930 --> 00:28:04.220
really need none of them apply to me
00:28:04.220 --> 00:28:07.193
right and this is a this is a pattern
00:28:07.193 --> 00:28:09.593
with Kernel bugs
00:28:09.593 --> 00:28:12.050
there is a project called Sandstorm
00:28:13.060 --> 00:28:16.879
that also uses ptrace and seccomp tracing
00:28:16.879 --> 00:28:19.049
to reduce the sys call
00:28:19.339 --> 00:28:22.266
surface and then puts regular services
00:28:22.266 --> 00:28:25.240
into a sandbox for web services and
00:28:25.240 --> 00:28:28.290
they evaded all kinds of of Kernel bugs
00:28:28.290 --> 00:28:30.309
just because of that so this is
00:28:30.309 --> 00:28:32.040
like a zero effort thing because
00:28:32.040 --> 00:28:34.740
obviously if you have a list of sys calls
00:28:34.740 --> 00:28:36.480
you'd use a white list and you
00:28:36.480 --> 00:28:38.110
have a list of things you are
00:28:38.110 --> 00:28:40.197
explicitly low and the rest is disabled
00:28:40.197 --> 00:28:42.368
not the other way around right
00:28:42.478 --> 00:28:44.478
so none of the usual Kernel bugs apply
00:28:44.478 --> 00:28:47.056
to me um because of the the seccomp stuff
00:28:47.056 --> 00:28:49.337
I already do so Kernel bugs aren't as big
00:28:49.337 --> 00:28:51.818
of a problem as you might think at least
00:28:51.818 --> 00:28:54.017
I still have them if I haven't patched
00:28:54.017 --> 00:28:56.436
but you can't get to them via the blog
00:28:57.269 --> 00:28:59.509
so I have a small confession to make
00:28:59.509 --> 00:29:01.669
I'm a bit of a troll and that applies
00:29:01.669 --> 00:29:05.010
to this project as well so I used the
00:29:05.010 --> 00:29:09.719
worst programming language I used C right
00:29:09.719 --> 00:29:11.983
so I'm trolling the security people
00:29:11.983 --> 00:29:13.746
and then I'm trolling the Java people
00:29:13.746 --> 00:29:15.414
who have been saying you should use
00:29:15.414 --> 00:29:17.270
multi-threading for performance and not
00:29:17.270 --> 00:29:18.604
have one process per request
00:29:18.604 --> 00:29:21.307
so I'm doing actually two fork and exec
00:29:21.307 --> 00:29:22.377
per request
00:29:23.178 --> 00:29:25.133
I'm trolling the database people
00:29:25.133 --> 00:29:26.442
I don't have any caching
00:29:26.442 --> 00:29:28.042
I don't have connection pools
00:29:28.459 --> 00:29:30.290
and the perf people too because I'm
00:29:30.290 --> 00:29:32.130
still faster than most of the regular
00:29:32.130 --> 00:29:34.639
solutions so there is no there's really
00:29:34.639 --> 00:29:36.873
no downside if you if you architect your
00:29:36.873 --> 00:29:38.874
software to use this kind of thing
00:29:39.444 --> 00:29:41.943
it will be slower than other ways to do it
00:29:41.943 --> 00:29:44.343
but most other software isn't as fast
00:29:44.343 --> 00:29:47.494
anyway so there's enough headway that
00:29:47.494 --> 00:29:49.724
you can use to do security instead of
00:29:49.724 --> 00:29:51.923
performance you will still be faster
00:29:53.319 --> 00:29:56.150
so let's recap the methodology I used
00:29:57.280 --> 00:29:59.549
first I make a list of all the attacks
00:29:59.549 --> 00:30:01.276
I can think of and this means
00:30:01.276 --> 00:30:03.301
concrete attacks so what could happen
00:30:03.301 --> 00:30:04.558
and what would what would
00:30:04.558 --> 00:30:06.958
be the problem then right and then
00:30:06.958 --> 00:30:09.118
I think for every item on the list
00:30:09.118 --> 00:30:11.430
I consider how to prevent this
00:30:11.430 --> 00:30:13.964
can I prevent this? what I need to do
00:30:13.964 --> 00:30:15.864
and then I do it right so that's easy
00:30:15.864 --> 00:30:17.946
it's like this the Feynman problem solving
00:30:17.946 --> 00:30:20.323
algorithm in spirit and this
00:30:20.323 --> 00:30:23.086
process is called threat modeling it's
00:30:23.086 --> 00:30:25.241
it's like a it's dirty word because it
00:30:25.241 --> 00:30:27.290
sounds like there's effort involved and
00:30:27.290 --> 00:30:29.060
nobody wants to do it but it's really
00:30:29.060 --> 00:30:30.913
it's easy it's just these these steps
00:30:30.913 --> 00:30:32.893
you look at your software you
00:30:32.893 --> 00:30:35.039
consider all the ways it could be attacked
00:30:35.039 --> 00:30:36.468
and then you consider what you
00:30:36.468 --> 00:30:38.226
could do to prevent the attack or in
00:30:38.226 --> 00:30:40.083
some cases you can't prevent the attack
00:30:40.083 --> 00:30:42.621
and then you say well that's a risk I have
live with
00:30:42.621 --> 00:30:44.459
right so that's called threat modeling
00:30:44.459 --> 00:30:46.069
you should try it's awesome
00:30:48.155 --> 00:30:50.119
and you saw that I'm trying
00:30:50.119 --> 00:30:52.490
to optimize something here I go for a
00:30:52.490 --> 00:30:55.209
specific target in this case I want
00:30:55.209 --> 00:30:57.130
as little code as possible
00:30:57.840 --> 00:30:59.910
the more code there is the more bugs
00:30:59.910 --> 00:31:01.929
there will be that's an a very old
00:31:02.469 --> 00:31:04.830
insight from I think it was originally
00:31:04.830 --> 00:31:06.795
in IBM study and they basically found
00:31:06.795 --> 00:31:08.755
that the number of bugs in code is a
00:31:08.755 --> 00:31:11.124
function of the lines of code in the code
00:31:11.124 --> 00:31:12.764
so there's a little more to it but
00:31:12.764 --> 00:31:15.334
basically it's true so and it's not just
00:31:15.334 --> 00:31:17.174
any code I want to have less of
00:31:17.669 --> 00:31:19.529
if the code is dangerous I particularly
00:31:19.529 --> 00:31:22.309
want to have less of it and the the most
00:31:22.309 --> 00:31:25.046
important category to to make smaller is
00:31:25.046 --> 00:31:27.256
the code that enforces security
00:31:27.256 --> 00:31:29.496
guarantees so like one security
00:31:29.496 --> 00:31:31.466
guarantee would be you can't log in
00:31:31.466 --> 00:31:33.505
if you don't have the right password right
00:31:33.505 --> 00:31:35.514
so the code that checks that I want it to
00:31:35.514 --> 00:31:38.272
be as small as possible one or two
00:31:38.272 --> 00:31:40.520
lines of code if I can manage it and
00:31:40.520 --> 00:31:42.625
then it's obvious if it if it's wrong or
00:31:42.625 --> 00:31:45.175
not the more complex the code is the
00:31:45.175 --> 00:31:47.552
less easy would it be to see if
00:31:47.552 --> 00:31:49.421
it's correct or not and that's what you
00:31:49.421 --> 00:31:51.321
want in the end you want to be sure the
00:31:51.321 --> 00:31:53.433
code is correct so how far did I get
00:31:53.433 --> 00:31:55.332
it's actually pretty amazing I think
00:31:55.332 --> 00:31:58.053
you can write an LDAP server in 5000 lines
00:31:58.053 --> 00:32:02.594
of code the blog is 3500 lines of code
00:32:02.594 --> 00:32:04.992
plus the LDAP client library
00:32:04.992 --> 00:32:06.452
plus zlib
00:32:06.682 --> 00:32:09.159
but I'm only using zlib to compress not to
00:32:09.159 --> 00:32:11.480
decompress so most attack scenarios
00:32:11.480 --> 00:32:13.997
doesn't don't apply to to my usage of zlib
00:32:13.997 --> 00:32:16.758
and the web server is also pretty slow
00:32:16.758 --> 00:32:18.424
if you only look at the HTTP code
00:32:18.424 --> 00:32:21.223
unfortunately it also contains the
00:32:21.223 --> 00:32:23.627
SSL Library which is orders of magnitude
00:32:23.627 --> 00:32:26.006
more than my code and that's how you
00:32:28.039 --> 00:32:31.840
want it you want the biggest risk not to
00:32:28.039 --> 00:32:34.519
be in the new code but in an old code
00:32:31.840 --> 00:32:36.440
that someone else already audited if you
00:32:34.519 --> 00:32:38.760
can manage it right so this is the
00:32:36.440 --> 00:32:40.840
optimization strategy try to have as
00:32:38.760 --> 00:32:42.960
little dangerous code as possible sounds
00:32:40.840 --> 00:32:44.679
like a no-brainer but if you look at
00:32:42.960 --> 00:32:47.279
modern software development you will
00:32:44.679 --> 00:32:50.120
find out they do the exact opposite pull
00:32:47.279 --> 00:32:53.159
in as many Frameworks as as they
00:32:50.120 --> 00:32:55.639
can so this strategy is called TCB
00:32:53.159 --> 00:32:57.159
minimization you should try it and I
00:32:55.639 --> 00:33:01.240
gave a talk about it already it's
00:32:57.159 --> 00:33:05.080
actually pretty easy so um I told you
00:33:01.240 --> 00:33:08.080
what I did to the to the blog to uh uh
00:33:05.080 --> 00:33:10.120
diminish the danger that can be done uh
00:33:08.080 --> 00:33:11.919
if someone manages to take it over and
00:33:10.120 --> 00:33:15.000
this is actually part of the TCB
00:33:11.919 --> 00:33:18.279
minimization process so the blog was a
00:33:15.000 --> 00:33:21.440
high risk area and then I took away
00:33:18.279 --> 00:33:24.000
Privileges and removed exess checks and
00:33:21.440 --> 00:33:26.240
in the end even if I give you remote
00:33:24.000 --> 00:33:28.200
code execution in the blog process you
00:33:26.240 --> 00:33:30.679
can't do anything you couldn't do before
00:33:28.200 --> 00:33:33.519
right so it's no longer part of the TCB
00:33:30.679 --> 00:33:35.559
the TCB is the part that uh enforces
00:33:33.519 --> 00:33:36.880
security guarantees which the block CGI
00:33:35.559 --> 00:33:39.440
doesn't
00:33:36.880 --> 00:33:41.360
anymore so that's what you want to do
00:33:39.440 --> 00:33:44.200
you want to end up in the smallest TCB
00:33:41.360 --> 00:33:47.200
you can possibly manage and uh every
00:33:44.200 --> 00:33:49.360
step on the way is good so no step is
00:33:47.200 --> 00:33:51.880
too small right if you can shave off
00:33:49.360 --> 00:33:54.639
even a little routine do
00:33:51.880 --> 00:33:56.960
it this is the minimization part of TCB
00:33:54.639 --> 00:33:59.799
minimization right I could I was able to
00:33:56.960 --> 00:34:03.639
remove the block from the TCB tiny El up
00:33:59.799 --> 00:34:05.360
still still has a risk so I I you saw
00:34:03.639 --> 00:34:07.279
the threat model if someone manages to
00:34:05.360 --> 00:34:08.639
take over tiny El up they can read the
00:34:07.279 --> 00:34:11.440
hashes and try to crack them that's
00:34:08.639 --> 00:34:14.639
still bad um but I can live with it
00:34:11.440 --> 00:34:17.399
right uh if they vandalize the block I
00:34:14.639 --> 00:34:19.960
can undo the damage without going to the
00:34:17.399 --> 00:34:22.280
tape Library so that's
00:34:19.960 --> 00:34:23.960
good if you compare that to the industry
00:34:22.280 --> 00:34:26.720
standard you you will find that my
00:34:23.960 --> 00:34:28.560
Approach is much better um usually in
00:34:26.720 --> 00:34:31.200
the industry you see platform decisions
00:34:28.560 --> 00:34:33.480
done by management not by the techies
00:34:31.200 --> 00:34:35.399
and um it's untroubled by expertise or
00:34:33.480 --> 00:34:37.800
risk analysis and you you get a
00:34:35.399 --> 00:34:39.720
diffusion of responsibility because if
00:34:37.800 --> 00:34:41.599
you even if you try to find out who's
00:34:39.720 --> 00:34:43.240
responsible for anything you find uh
00:34:41.599 --> 00:34:44.960
well it's that team over there but we
00:34:43.240 --> 00:34:47.040
don't really know and then you find out
00:34:44.960 --> 00:34:48.159
the team dissolved last week and it's
00:34:47.040 --> 00:34:50.919
really
00:34:48.159 --> 00:34:54.560
horrible and brand new we have ai tools
00:34:50.919 --> 00:34:54.560
which is also a diffusion of
00:34:55.200 --> 00:34:59.000
responsibility and then you get people
00:34:57.160 --> 00:35:00.880
arguing well it's so bad it can't get
00:34:59.000 --> 00:35:02.760
any worse let's go to the cloud where
00:35:00.880 --> 00:35:07.079
obviously it gets worse
00:35:02.760 --> 00:35:08.520
immediately so I prefer my way um I
00:35:07.079 --> 00:35:10.640
think in the end it's important to
00:35:08.520 --> 00:35:12.920
realize that the the lack of security
00:35:10.640 --> 00:35:16.440
you may have in your projects right now
00:35:12.920 --> 00:35:18.400
is self-imposed there is no guy with a
00:35:16.440 --> 00:35:20.480
shotgun behind you
00:35:18.400 --> 00:35:23.800
threatening you can do it you just have
00:35:20.480 --> 00:35:25.640
to start right so this is self-imposed
00:35:23.800 --> 00:35:28.800
helplessness you can actually help
00:35:25.640 --> 00:35:28.800
yourself you just have to start
00:35:29.440 --> 00:35:34.160
right how did we get here this is
00:35:32.079 --> 00:35:36.119
obviously not a good good place to be
00:35:34.160 --> 00:35:37.800
like all the software is crappy and
00:35:36.119 --> 00:35:40.200
there's a few it's not just that people
00:35:37.800 --> 00:35:43.440
are dumb there's a few reasons for that
00:35:40.200 --> 00:35:45.359
so um back in the day you used to have
00:35:43.440 --> 00:35:48.200
bespoke applications that were written
00:35:45.359 --> 00:35:50.079
for a specific purpose and they used the
00:35:48.200 --> 00:35:52.359
waterfall model and you had the
00:35:50.079 --> 00:35:55.560
requirements specification and it was
00:35:52.359 --> 00:35:58.079
lots of bureaucracy and really horrible
00:35:55.560 --> 00:36:00.200
but it also Al meant that you knew what
00:35:58.079 --> 00:36:02.880
the application had be had to be able to
00:36:00.200 --> 00:36:06.240
do so that means you can make sure
00:36:02.880 --> 00:36:08.079
anything else is forbidden if you know
00:36:06.240 --> 00:36:10.040
what the application needs to be able to
00:36:08.079 --> 00:36:12.400
do you can make sure it doesn't do any
00:36:10.040 --> 00:36:15.520
other stuff and that is security if you
00:36:12.400 --> 00:36:17.280
think about it deny everything that the
00:36:15.520 --> 00:36:19.280
application wasn't supposed to be doing
00:36:17.280 --> 00:36:22.200
and then that's what an attacker would
00:36:19.280 --> 00:36:24.680
do if they take over the machine right
00:36:22.200 --> 00:36:26.240
so if you know beforehand what you're
00:36:24.680 --> 00:36:28.680
trying to get to you can actually
00:36:26.240 --> 00:36:30.319
implement privilege even architecturally
00:36:28.680 --> 00:36:32.920
as I've shown
00:36:30.319 --> 00:36:35.720
you now we have more of an Ikea model
00:36:32.920 --> 00:36:37.560
you buy parts that are uh designed by
00:36:35.720 --> 00:36:39.359
their own teams and the teams designing
00:36:37.560 --> 00:36:42.440
the parts don't know what the final
00:36:39.359 --> 00:36:44.240
product will look like right in in some
00:36:42.440 --> 00:36:45.640
cases even you don't know what the final
00:36:44.240 --> 00:36:47.920
product will look like but it's even
00:36:45.640 --> 00:36:49.880
worse if you consider that the the the
00:36:47.920 --> 00:36:51.480
team building the part you make your
00:36:49.880 --> 00:36:53.760
software from doesn't know what it will
00:36:51.480 --> 00:36:56.359
be used for so it has to be as generic
00:36:53.760 --> 00:36:57.839
as possible Right the more it can be
00:36:56.359 --> 00:37:00.680
done with with it the better and that's
00:36:57.839 --> 00:37:03.119
the opposite of security right security
00:37:00.680 --> 00:37:05.359
means understanding what you need to do
00:37:03.119 --> 00:37:08.599
and then disallowing the rest and this
00:37:05.359 --> 00:37:11.440
means be as generic as you can the parts
00:37:08.599 --> 00:37:12.400
are optimized for genericity Gen what's
00:37:11.440 --> 00:37:15.599
the
00:37:12.400 --> 00:37:17.680
name genericism I don't know so they are
00:37:15.599 --> 00:37:21.319
optimized to be as flexible as possible
00:37:17.680 --> 00:37:21.319
and they are chosen by
00:37:21.599 --> 00:37:25.079
flexibility the developer of the part
00:37:23.640 --> 00:37:27.599
usually has no idea what it would used
00:37:25.079 --> 00:37:31.040
for uh and that means you can't do least
00:37:27.599 --> 00:37:33.760
privilege because um you don't know what
00:37:31.040 --> 00:37:36.319
the privilege will be that's least so
00:37:33.760 --> 00:37:38.520
this this is actually a big mess so if
00:37:36.319 --> 00:37:40.480
you use Parts programmed by other people
00:37:38.520 --> 00:37:42.680
you will have to invest extra effort to
00:37:40.480 --> 00:37:45.480
find out what kind of stuff you can make
00:37:42.680 --> 00:37:47.599
it not do because it will definitely be
00:37:45.480 --> 00:37:49.440
able to do more than you need and the
00:37:47.599 --> 00:37:52.040
more you can clamp down the more
00:37:49.440 --> 00:37:53.720
security you will have uh it's even
00:37:52.040 --> 00:37:55.079
worse if you do Agile development
00:37:53.720 --> 00:37:58.079
because then by definition you don't
00:37:55.079 --> 00:37:59.520
know what the end result will be so if
00:37:58.079 --> 00:38:00.880
you don't know that you can't do
00:37:59.520 --> 00:38:03.319
security
00:38:00.880 --> 00:38:05.640
lockdown so another argument why we got
00:38:03.319 --> 00:38:07.520
here is economics of scale so it used to
00:38:05.640 --> 00:38:10.880
be that if you build some kind of device
00:38:07.520 --> 00:38:13.280
that needs to do something like I don't
00:38:10.880 --> 00:38:17.400
know uh a
00:38:13.280 --> 00:38:19.680
microwave then you you find parts and
00:38:17.400 --> 00:38:21.359
you combine the parts and you solder
00:38:19.680 --> 00:38:24.119
them together and then they solve the
00:38:21.359 --> 00:38:27.160
problem but these days uh you don't
00:38:24.119 --> 00:38:29.680
solder parts anymore you assemble from
00:38:27.160 --> 00:38:32.280
pre-made parts and these are usually
00:38:29.680 --> 00:38:35.280
programmable right so a little arm chip
00:38:32.280 --> 00:38:37.040
cost like a tenth of a scent so why use
00:38:35.280 --> 00:38:38.800
a special part if you can use an arm
00:38:37.040 --> 00:38:40.880
chip and then program it but that means
00:38:38.800 --> 00:38:43.000
you still need to use software that
00:38:40.880 --> 00:38:44.640
actually solves the problem the hardware
00:38:43.000 --> 00:38:47.000
is generic and that means the hardware
00:38:44.640 --> 00:38:49.800
can be hacked and this is turning out to
00:38:47.000 --> 00:38:53.359
be a problem right if you had a break in
00:38:49.800 --> 00:38:54.640
in 20 years youo um it it breaked right
00:38:53.359 --> 00:38:57.040
but now it's
00:38:54.640 --> 00:38:59.040
programmable and people have realized
00:38:57.040 --> 00:39:01.200
how bad that is but it is bad right so
00:38:59.040 --> 00:39:05.480
that's that will bite Us in the
00:39:01.200 --> 00:39:07.680
ass oops so um the response from the
00:39:05.480 --> 00:39:10.440
industry has so far been the ostrich
00:39:07.680 --> 00:39:13.000
method basically we we install stuff
00:39:10.440 --> 00:39:14.880
that we know is untrustworthy and so we
00:39:13.000 --> 00:39:17.680
install other stuff on top of it that's
00:39:14.880 --> 00:39:20.720
also untrustworthy and then we call it
00:39:17.680 --> 00:39:24.119
Telemetry or big data and to some risk
00:39:20.720 --> 00:39:26.599
uh logging analysis in in aze or
00:39:24.119 --> 00:39:29.640
whatever uh and in the end the attack
00:39:26.599 --> 00:39:31.839
surface has mushroomed like a nuclear
00:39:29.640 --> 00:39:34.240
explosion right so that's our fault
00:39:31.839 --> 00:39:36.000
nobody has forced us to do this you
00:39:34.240 --> 00:39:39.079
don't need to do this in your own
00:39:36.000 --> 00:39:41.119
projects that's the hopeful message of
00:39:39.079 --> 00:39:42.640
this talk in conclusion if you remember
00:39:41.119 --> 00:39:44.079
nothing else from this talk remember
00:39:42.640 --> 00:39:46.520
that threat modeling is a thing and you
00:39:44.079 --> 00:39:48.480
should try it TCB minimization actually
00:39:46.520 --> 00:39:51.680
helps least privilege is another facet
00:39:48.480 --> 00:39:53.800
of the same thing and if you can uh use
00:39:51.680 --> 00:39:56.440
a pendon data storage you should
00:39:53.800 --> 00:39:58.359
consider it hm blockchain yeah not
00:39:56.440 --> 00:40:00.560
blockchain a pend only data storage it's
00:39:58.359 --> 00:40:00.560
not
00:40:00.630 --> 00:40:08.820
[Applause]
00:40:09.000 --> 00:40:13.240
[Music]
00:40:10.720 --> 00:40:15.200
blockchain so two more you two more
00:40:13.240 --> 00:40:18.160
slides yeah two more slides sorry I'm an
00:40:15.200 --> 00:40:20.480
imposter no problem so the rule of thumb
00:40:18.160 --> 00:40:23.480
should be if if the blog of some
00:40:20.480 --> 00:40:26.160
unwashed hobbyist from the Internet is
00:40:23.480 --> 00:40:28.040
more secure than your it security then
00:40:26.160 --> 00:40:30.359
you should improve your it
00:40:28.040 --> 00:40:33.760
security right that shouldn't
00:40:30.359 --> 00:40:35.400
happen all right so that's all from my
00:40:33.760 --> 00:40:38.319
talk I think we still have time for
00:40:35.400 --> 00:40:41.560
questions do we yes okay awesome okay
00:40:38.319 --> 00:40:41.560
now you can put your hand
00:40:45.040 --> 00:40:49.599
[Applause]
00:40:47.280 --> 00:40:51.280
together so if you want to ask a
00:40:49.599 --> 00:40:55.720
question we have four microphones in the
00:40:51.280 --> 00:40:56.880
room 1 2 3 4 and I'm going to take a a
00:40:55.720 --> 00:40:59.760
question the first first question from
00:40:56.880 --> 00:41:02.359
the internet the internet is saying you
00:40:59.760 --> 00:41:03.400
actually got hacked or can you elaborate
00:41:02.359 --> 00:41:05.599
on what
00:41:03.400 --> 00:41:07.119
happened Yes actually there was an
00:41:05.599 --> 00:41:08.680
incident where someone was able to post
00:41:07.119 --> 00:41:11.119
stuff to my blog and because I had a
00:41:08.680 --> 00:41:14.640
pend only data storage I Shrugged it off
00:41:11.119 --> 00:41:16.520
basically so use use a pendon data
00:41:14.640 --> 00:41:19.480
storage it's it will save your ass at
00:41:16.520 --> 00:41:22.079
some point the problem was a bug in my
00:41:19.480 --> 00:41:23.960
uh Access Control lists I had used some
00:41:22.079 --> 00:41:26.440
some Access Control list in my alab
00:41:23.960 --> 00:41:27.880
server and I had a line in it that I
00:41:26.440 --> 00:41:29.760
should have removed but I forgot to
00:41:27.880 --> 00:41:33.200
remove it and that meant you could post
00:41:29.760 --> 00:41:35.200
without having credentials but um it
00:41:33.200 --> 00:41:38.040
happened and it wasn't bad because my
00:41:35.200 --> 00:41:39.599
architecture prevented damage um as
00:41:38.040 --> 00:41:42.440
people are leaving the room could you
00:41:39.599 --> 00:41:44.760
leave very quietly thank you um
00:41:42.440 --> 00:41:47.119
microphone number one yeah is there a
00:41:44.760 --> 00:41:50.520
second alternative for Windows and Mac
00:41:47.119 --> 00:41:52.720
OS a secure alternative well so
00:41:50.520 --> 00:41:56.359
basically you can do the the principles
00:41:52.720 --> 00:42:00.000
I um I showed in this talk you can do on
00:41:56.359 --> 00:42:02.560
those two so usually you will not be
00:42:00.000 --> 00:42:05.359
hacked because your your Mac OS or
00:42:02.560 --> 00:42:07.079
Windows had a bug I that happens too but
00:42:05.359 --> 00:42:09.319
the bigger problem is that the software
00:42:07.079 --> 00:42:11.800
you wrote had a bug or that you the
00:42:09.319 --> 00:42:14.480
software that you use had a bug so I'm
00:42:11.800 --> 00:42:16.560
I'm trying to tell you Linux isn't uh
00:42:14.480 --> 00:42:18.520
particularly more secure than Windows
00:42:16.560 --> 00:42:20.599
it's just it's basically you can write
00:42:18.520 --> 00:42:22.839
secure software and insecure software on
00:42:20.599 --> 00:42:25.160
any operating system you should still
00:42:22.839 --> 00:42:26.720
use Linux because it has advantages but
00:42:25.160 --> 00:42:28.880
if you apply these Tech techniques to
00:42:26.720 --> 00:42:31.720
your software it will be secure on on
00:42:28.880 --> 00:42:34.480
Mac OS and windows as well right so this
00:42:31.720 --> 00:42:36.040
is not for for end users selecting the
00:42:34.480 --> 00:42:37.319
software if you select software you have
00:42:36.040 --> 00:42:39.520
to trust the
00:42:37.319 --> 00:42:42.200
vendor there's no way around that but if
00:42:39.520 --> 00:42:44.280
you write your own software then you can
00:42:42.200 --> 00:42:46.960
reduce the risk to a point where you can
00:42:44.280 --> 00:42:49.119
live with it and sleep soundly sure is
00:42:46.960 --> 00:42:51.359
there a a technical alternative or
00:42:49.119 --> 00:42:53.119
similar similarity like sa comp for
00:42:51.359 --> 00:42:54.760
Windows and Mac OS so can you drop your
00:42:53.119 --> 00:42:57.960
privileges after you have opened a file
00:42:54.760 --> 00:42:59.960
for example uh uh so for meos I'm not
00:42:57.960 --> 00:43:02.680
sure but I know that that free BSD net
00:42:59.960 --> 00:43:05.440
BSD and open BSD have an an equivalent
00:43:02.680 --> 00:43:08.119
thing I think uh Macos has it too but
00:43:05.440 --> 00:43:09.920
I'm I'm not sure about that for Windows
00:43:08.119 --> 00:43:11.559
there's are sandboxing methods you can
00:43:09.920 --> 00:43:13.359
look at the Chrome source code for
00:43:11.559 --> 00:43:16.440
example they have a Sandbox it's open
00:43:13.359 --> 00:43:18.960
source you can use that to do this kind
00:43:16.440 --> 00:43:21.720
of thing okay thanks so microphone
00:43:18.960 --> 00:43:23.800
number two except down that's gone so
00:43:21.720 --> 00:43:27.160
microphone number three in that
00:43:23.800 --> 00:43:29.480
case this is four I sorry four four yes
00:43:27.160 --> 00:43:31.720
um will your next talk be about writing
00:43:29.480 --> 00:43:33.559
software secure software in Windows and
00:43:31.720 --> 00:43:35.559
if no uh how much assets would you
00:43:33.559 --> 00:43:38.119
request to compensate for all the
00:43:35.559 --> 00:43:41.839
pain
00:43:38.119 --> 00:43:45.960
no it's not a question of
00:43:41.839 --> 00:43:48.359
money okay uh microphone one um have you
00:43:45.960 --> 00:43:49.440
tried removing unnecessary features from
00:43:48.359 --> 00:43:52.240
open
00:43:49.440 --> 00:43:54.680
SSL uh Yes actually I've I've done this
00:43:52.240 --> 00:43:56.680
pretty pretty early but it's still it's
00:43:54.680 --> 00:44:00.000
still much bigger than my code
00:43:56.680 --> 00:44:03.440
so um for example op SSL has support for
00:44:00.000 --> 00:44:05.119
UDP based TLs but there's a lot of
00:44:03.440 --> 00:44:06.960
shared cyers in there you can remove
00:44:05.119 --> 00:44:08.720
ciphers you don't need and and that
00:44:06.960 --> 00:44:11.880
helps a bit but it's still it's the
00:44:08.720 --> 00:44:14.720
biggest part of the web server by far I
00:44:11.880 --> 00:44:18.200
think there was an internet question was
00:44:14.720 --> 00:44:21.640
there no doesn't look like
00:44:18.200 --> 00:44:22.839
yes no yes no no yes okay uh then
00:44:21.640 --> 00:44:27.200
microphone
00:44:22.839 --> 00:44:29.640
four as someone who is uh connected or
00:44:27.200 --> 00:44:31.880
was connected to an industry which has
00:44:29.640 --> 00:44:34.200
programming programmable
00:44:31.880 --> 00:44:37.960
brakes
00:44:34.200 --> 00:44:39.480
um what is your opinion about things
00:44:37.960 --> 00:44:42.440
like
00:44:39.480 --> 00:44:44.079
mizra well well so there are standards
00:44:42.440 --> 00:44:45.240
in the automotive industry for example
00:44:44.079 --> 00:44:48.040
like misra
00:44:45.240 --> 00:44:50.359
to make sure you write better code and
00:44:48.040 --> 00:44:52.520
it's mostly compliance so they give you
00:44:50.359 --> 00:44:55.280
rules like um you shouldn't use
00:44:52.520 --> 00:44:56.960
recursion in your code for example and
00:44:55.280 --> 00:44:59.000
the functions should would be this big
00:44:56.960 --> 00:45:01.640
at at most and this is more I mean it
00:44:59.000 --> 00:45:03.440
will probably help a bit but it's much
00:45:01.640 --> 00:45:05.800
better to to invest in in good
00:45:03.440 --> 00:45:09.440
architecture but you may have noticed I
00:45:05.800 --> 00:45:11.200
I've said I wrote the code in C and I
00:45:09.440 --> 00:45:13.800
said nothing about what I did to make
00:45:11.200 --> 00:45:15.880
sure it's it's good code so that's
00:45:13.800 --> 00:45:17.559
that's a different dimension that's
00:45:15.880 --> 00:45:20.800
orthogonal right
00:45:17.559 --> 00:45:22.280
so follow those standards it will it
00:45:20.800 --> 00:45:25.040
will make your code a bit better
00:45:22.280 --> 00:45:26.640
probably um but it won't solve all the
00:45:25.040 --> 00:45:29.040
problems and I think personally you
00:45:26.640 --> 00:45:30.760
should do both you should make sure or
00:45:29.040 --> 00:45:32.520
try to make sure that there's as little
00:45:30.760 --> 00:45:34.160
bugs as possible in your code there's
00:45:32.520 --> 00:45:36.079
ways to do that I had to talk about that
00:45:34.160 --> 00:45:37.760
too but after you do that you should
00:45:36.079 --> 00:45:40.200
still have these kind of
00:45:37.760 --> 00:45:41.720
architectural guide guard rails that
00:45:40.200 --> 00:45:44.079
keep you on track even if someone
00:45:41.720 --> 00:45:46.240
manages to take over the
00:45:44.079 --> 00:45:47.280
process so now I think there was an
00:45:46.240 --> 00:45:50.599
internet
00:45:47.280 --> 00:45:53.520
question yes uh the internet is asking
00:45:50.599 --> 00:45:55.559
how would it work to like scale This
00:45:53.520 --> 00:45:58.839
truly impressive security architecture
00:45:55.559 --> 00:46:01.400
up for more use cases and more like
00:45:58.839 --> 00:46:04.880
larger theme or would the theme size and
00:46:01.400 --> 00:46:09.040
the feature keep ruin it yes
00:46:04.880 --> 00:46:09.040
so oh no oh
00:46:09.070 --> 00:46:15.839
[Laughter]
00:46:12.319 --> 00:46:15.839
no well I'm
00:46:24.800 --> 00:46:27.800
sorry
00:46:28.470 --> 00:46:36.780
[Music]
00:46:37.760 --> 00:46:40.760
la