WEBVTT

00:00:00.000 --> 00:00:30.000
Dear viewer, these subtitles were generated
by a machine via the service YouTube
and therefore are (very) buggy.
If you are capable, please help us to
create good quality subtitles:
https://c3subtitles.de/talk/3028 Thanks!

00:00:00.090 --> 00:00:16.240
[Music]

00:00:14.080 --> 00:00:20.439
um basically textbooks have been written

00:00:16.240 --> 00:00:22.359
about it um countless talks have been uh

00:00:20.439 --> 00:00:23.640
have been Illuminating all of the errors

00:00:22.359 --> 00:00:26.760
of our

00:00:23.640 --> 00:00:28.160
ways um and still all those sucky

00:00:26.760 --> 00:00:30.519
software is out

00:00:28.160 --> 00:00:34.440
there um but

00:00:30.519 --> 00:00:37.040
FIFA over here the hero of our show uh

00:00:34.440 --> 00:00:40.520
has put out has put all of these best

00:00:37.040 --> 00:00:43.640
practices into you know into his work to

00:00:40.520 --> 00:00:46.719
try to create a um secure website he's

00:00:43.640 --> 00:00:50.399
going to show us how it's done so that

00:00:46.719 --> 00:00:55.359
we can all sleep way better at night and

00:00:50.399 --> 00:00:57.559
um um and with that template go back and

00:00:55.359 --> 00:00:59.559
and secure our own software and so with

00:00:57.559 --> 00:01:02.879
that I'm going to hand it right over to

00:00:59.559 --> 00:01:02.879
Fifi give him a round of

00:01:04.910 --> 00:01:10.170
[Applause]

00:01:12.560 --> 00:01:17.600
applause thank you um I have to start

00:01:15.159 --> 00:01:19.840
with an apology because I did submit

00:01:17.600 --> 00:01:22.200
this talk but it was rejected so the

00:01:19.840 --> 00:01:24.320
slides are not at the stage where they

00:01:22.200 --> 00:01:26.200
should be these are our slides for a

00:01:24.320 --> 00:01:28.439
previous version of the talk it contains

00:01:26.200 --> 00:01:30.240
all the material and I tried to update

00:01:28.439 --> 00:01:33.240
it more but that destroyed the flow so

00:01:30.240 --> 00:01:35.399
we we're stuck with it basically um the

00:01:33.240 --> 00:01:37.280
difference was the the audience so while

00:01:35.399 --> 00:01:39.079
I expect more developers here the other

00:01:37.280 --> 00:01:42.640
audience was more and hackers and

00:01:39.079 --> 00:01:45.479
business people so I try to get them

00:01:42.640 --> 00:01:48.040
from where they are and uh the main

00:01:45.479 --> 00:01:50.560
question usually is Are We There Yet

00:01:48.040 --> 00:01:53.200
right so about me you probably probably

00:01:50.560 --> 00:01:55.479
seen this before I'm a code auditor by

00:01:53.200 --> 00:01:57.439
trade I have a small company and

00:01:55.479 --> 00:02:01.840
companies show us their code and I show

00:01:57.439 --> 00:02:01.840
them bugs I find in Indians quite easy

00:02:02.000 --> 00:02:06.320
but before we start I have a small

00:02:04.000 --> 00:02:09.599
celebration to do this actually happened

00:02:06.320 --> 00:02:11.760
just a day before the first time I

00:02:09.599 --> 00:02:14.239
talked about this uh so kasperski

00:02:11.760 --> 00:02:15.440
message they found some mware anded Ed

00:02:14.239 --> 00:02:18.120
diet

00:02:15.440 --> 00:02:19.270
Lipsy which I have written so this is

00:02:18.120 --> 00:02:25.080
like a

00:02:19.270 --> 00:02:25.080
[Applause]

00:02:26.680 --> 00:02:31.080
Knighthood some of the malware people

00:02:28.879 --> 00:02:33.480
know what's good

00:02:31.080 --> 00:02:35.879
so um basically the main question when I

00:02:33.480 --> 00:02:37.879
talk to customers is uh we spend so much

00:02:35.879 --> 00:02:40.480
money on this why isn't it

00:02:37.879 --> 00:02:44.159
working and the the answer is you're

00:02:40.480 --> 00:02:47.200
you're doing it wrong so um I will try

00:02:44.159 --> 00:02:50.040
to show no what exactly is wrong and

00:02:47.200 --> 00:02:52.000
there's a small preface here uh people

00:02:50.040 --> 00:02:54.120
usually say there's no time to do this

00:02:52.000 --> 00:02:56.560
briide and that's just wrong you have

00:02:54.120 --> 00:02:58.640
exactly as much time per day as other

00:02:56.560 --> 00:03:00.000
people who did great things so you can

00:02:58.640 --> 00:03:01.760
do great things too you just just need

00:03:00.000 --> 00:03:05.480
to do

00:03:01.760 --> 00:03:07.080
it so let's play a little warm-up game

00:03:05.480 --> 00:03:10.000
uh it's called how it started how it's

00:03:07.080 --> 00:03:12.440
going so let's have a demo round IBM

00:03:10.000 --> 00:03:14.959
Watson is revolutionizing 10

00:03:12.440 --> 00:03:17.319
Industries and it's going like this

00:03:14.959 --> 00:03:20.319
whatever happened to IBM Watson that's a

00:03:17.319 --> 00:03:21.959
typical pattern in the security industry

00:03:20.319 --> 00:03:25.480
right so here's another one how it

00:03:21.959 --> 00:03:27.760
started revolutionize security with AI

00:03:25.480 --> 00:03:30.239
right we all know where this is

00:03:27.760 --> 00:03:33.640
going right so that's the p

00:03:30.239 --> 00:03:35.319
um let's play it security mind sweeper

00:03:33.640 --> 00:03:37.400
right so uh everybody here probably

00:03:35.319 --> 00:03:39.519
knows who Gartner is they publish

00:03:37.400 --> 00:03:41.239
recommendations and they even have a

00:03:39.519 --> 00:03:43.239
voting section where people can say this

00:03:41.239 --> 00:03:45.319
is the best product in this section

00:03:43.239 --> 00:03:47.120
right so let's look at a few of them and

00:03:45.319 --> 00:03:50.840
see what happened to people who trusted

00:03:47.120 --> 00:03:53.879
Gartner first is a firewall right so how

00:03:50.840 --> 00:03:55.360
it started the number one recommendation

00:03:53.879 --> 00:04:01.560
is for

00:03:55.360 --> 00:04:03.159
net and they have a lot of marketing G

00:04:01.560 --> 00:04:04.720
and if you look how it's going it's not

00:04:03.159 --> 00:04:08.120
going so

00:04:04.720 --> 00:04:09.760
good so let's extend the pattern a bit

00:04:08.120 --> 00:04:11.680
why what happened to me in in this

00:04:09.760 --> 00:04:13.120
regard so I I don't need a firewall I

00:04:11.680 --> 00:04:16.120
don't have any ports open that I need

00:04:13.120 --> 00:04:18.799
blocking right so you don't need this

00:04:16.120 --> 00:04:21.199
strictly speaking you don't need it next

00:04:18.799 --> 00:04:24.479
discipline endpoint protection

00:04:21.199 --> 00:04:27.120
so it started with TRX this is the

00:04:24.479 --> 00:04:28.479
number one recommendation on Gartner I I

00:04:27.120 --> 00:04:30.199
hadn't heard of them there like can make

00:04:28.479 --> 00:04:33.479
a feed joint venture or something thing

00:04:30.199 --> 00:04:35.919
who cares they also have great marketing

00:04:33.479 --> 00:04:37.000
go and then if you look at what happened

00:04:35.919 --> 00:04:39.280
it's

00:04:37.000 --> 00:04:42.919
like they made it

00:04:39.280 --> 00:04:45.320
worse um okay so this didn't apply to me

00:04:42.919 --> 00:04:47.160
either because I don't use snake oil

00:04:45.320 --> 00:04:48.800
let's see the third one password manager

00:04:47.160 --> 00:04:52.080
also very

00:04:48.800 --> 00:04:55.240
popular how it started recommended last

00:04:52.080 --> 00:04:55.240
pass you probably know where this is

00:04:56.479 --> 00:05:01.560
going yeah they got owned and then

00:04:59.759 --> 00:05:04.759
people got

00:05:01.560 --> 00:05:07.080
owned so um you may notice a pattern

00:05:04.759 --> 00:05:08.800
here uh this didn't apply to me because

00:05:07.080 --> 00:05:10.880
I deser a password authentication use

00:05:08.800 --> 00:05:14.520
public key which has been available for

00:05:10.880 --> 00:05:16.440
decades right so small bonus the last

00:05:14.520 --> 00:05:19.639
one to

00:05:16.440 --> 00:05:22.639
FAA uh Gartner recommends Duo which has

00:05:19.639 --> 00:05:25.639
been bought by Cisco but doesn't

00:05:22.639 --> 00:05:27.400
matter so if you look at what Duo does

00:05:25.639 --> 00:05:29.160
your server asks the cloud for

00:05:27.400 --> 00:05:30.199
permission the cloud goes to the

00:05:29.160 --> 00:05:33.479
telephone

00:05:30.199 --> 00:05:35.240
telephone shows a popup you click yes

00:05:33.479 --> 00:05:37.240
and then the cloud tells the server it's

00:05:35.240 --> 00:05:39.160
okay you can let them in if you look

00:05:37.240 --> 00:05:40.680
really closely you can notice the cloud

00:05:39.160 --> 00:05:44.080
doesn't have to do the popup can just

00:05:40.680 --> 00:05:47.039
say sure so this comes pre-owned there

00:05:44.080 --> 00:05:49.120
is no need to hack anything

00:05:47.039 --> 00:05:50.600
here and something many people don't

00:05:49.120 --> 00:05:51.960
realize you don't need two Factor if you

00:05:50.600 --> 00:05:53.400
have public key that's already the

00:05:51.960 --> 00:05:55.479
second

00:05:53.400 --> 00:05:57.720
Factor okay

00:05:55.479 --> 00:06:00.759
so yeah let's skip over this briefly

00:05:57.720 --> 00:06:02.199
Splunk is the the recommend option here

00:06:00.759 --> 00:06:06.039
and they make the organization more

00:06:02.199 --> 00:06:06.039
resilient um unless you install

00:06:08.360 --> 00:06:11.519
[Applause]

00:06:14.840 --> 00:06:20.639
it okay um so this one is dear to my

00:06:17.639 --> 00:06:22.240
heart because um people start arguing

00:06:20.639 --> 00:06:24.960
about whether to install patches and

00:06:22.240 --> 00:06:27.840
which patch to install first and it used

00:06:24.960 --> 00:06:29.520
to be simple you you look for problems

00:06:27.840 --> 00:06:30.560
then you install the patches and then it

00:06:29.520 --> 00:06:33.240
a bit more

00:06:30.560 --> 00:06:36.440
complicated and the result is this right

00:06:33.240 --> 00:06:40.000
that's a famous podcast in in German uh

00:06:36.440 --> 00:06:41.800
it's about municipality who got owned by

00:06:40.000 --> 00:06:43.800
by ransomware and then had to call the

00:06:41.800 --> 00:06:46.360
Army for

00:06:43.800 --> 00:06:47.840
help and what you should do I'm having

00:06:46.360 --> 00:06:49.160
this for completeness install all

00:06:47.840 --> 00:06:51.840
patches immediately but that's a

00:06:49.160 --> 00:06:54.520
separate talk right so um you may notice

00:06:51.840 --> 00:06:56.039
a pattern here the it security industry

00:06:54.520 --> 00:06:59.000
recommends something and if you do it

00:06:56.039 --> 00:07:01.000
you're [ __ ] so don't do it um in case

00:06:59.000 --> 00:07:03.560
you can't read this this says snake

00:07:01.000 --> 00:07:06.720
repellent granules and then there's a

00:07:03.560 --> 00:07:06.720
snake sleeping next to

00:07:07.520 --> 00:07:12.319
it right so um if we can trust the

00:07:10.960 --> 00:07:15.400
recommendations of the industry what

00:07:12.319 --> 00:07:16.919
shall we do and um so I had a lot of

00:07:15.400 --> 00:07:19.520
time on my hands because I didn't have

00:07:16.919 --> 00:07:21.319
to clean up after crappy it security

00:07:19.520 --> 00:07:23.720
industry recommendations so what that

00:07:21.319 --> 00:07:26.960
what did I do with my

00:07:23.720 --> 00:07:30.840
time and uh I decided I need a Blog uh

00:07:26.960 --> 00:07:32.560
some time ago now um and I started

00:07:30.840 --> 00:07:34.280
thinking what do I need and it's

00:07:32.560 --> 00:07:37.520
actually not that much I could have just

00:07:34.280 --> 00:07:39.400
shown basically static content a little

00:07:37.520 --> 00:07:42.240
search function would be good but it's

00:07:39.400 --> 00:07:44.720
optional um I didn't need comments for

00:07:42.240 --> 00:07:48.360
legal reasons because people start

00:07:44.720 --> 00:07:50.120
posting like uh links to maware or

00:07:48.360 --> 00:07:51.960
whatever I don't want that um I don't

00:07:50.120 --> 00:07:53.840
need that right so the first version was

00:07:51.960 --> 00:07:55.800
actually really easy it was a small

00:07:53.840 --> 00:07:58.599
standard web server and I had the the

00:07:55.800 --> 00:08:00.199
blog entries a static HTML files one

00:07:58.599 --> 00:08:01.759
file per month it was actually really

00:08:00.199 --> 00:08:05.440
easy if you want to search you just can

00:08:01.759 --> 00:08:07.120
ask Google and limit it to my site so

00:08:05.440 --> 00:08:09.479
posting was also easy had a little

00:08:07.120 --> 00:08:12.879
script that uh I could run on the server

00:08:09.479 --> 00:08:14.879
and I just ssh in and SSH I trust for

00:08:12.879 --> 00:08:17.479
authentication so there's no new attack

00:08:14.879 --> 00:08:20.400
surface I have that anyway and this is a

00:08:17.479 --> 00:08:23.039
great design it's secure it's simple

00:08:20.400 --> 00:08:25.000
there's low risk it's also high

00:08:23.039 --> 00:08:27.879
performance but you couldn't do a talk

00:08:25.000 --> 00:08:30.080
about it at the CCC right so it's too

00:08:27.879 --> 00:08:32.280
boring so I started to produce risk in

00:08:30.080 --> 00:08:32.280
my

00:08:33.640 --> 00:08:38.240
setup so the first idea was I had

00:08:36.360 --> 00:08:40.640
written a small web server I could just

00:08:38.240 --> 00:08:44.039
implement the blog in the web server

00:08:40.640 --> 00:08:46.839
because you know it's my code anyway um

00:08:44.039 --> 00:08:49.080
but that has downsides if the the blog

00:08:46.839 --> 00:08:50.839
is running in the web server then it can

00:08:49.080 --> 00:08:52.920
access all the memory of the web server

00:08:50.839 --> 00:08:55.240
in particular it can see the TLs private

00:08:52.920 --> 00:08:58.240
key and that I don't want people to

00:08:55.240 --> 00:09:00.560
extract right so it can't be a module in

00:08:58.240 --> 00:09:02.760
the web server

00:09:00.560 --> 00:09:05.360
and the the obvious solution is it the

00:09:02.760 --> 00:09:08.000
it has to run in a different user ID on

00:09:05.360 --> 00:09:09.760
on Linux I'm using Linux or but any any

00:09:08.000 --> 00:09:12.079
Unix or Windows would be the same

00:09:09.760 --> 00:09:14.000
basically it runs in a different user ID

00:09:12.079 --> 00:09:15.800
and then if you if you take over the

00:09:14.000 --> 00:09:18.279
process of the blog because there's some

00:09:15.800 --> 00:09:19.360
bug in it you couldn't access the the

00:09:18.279 --> 00:09:21.760
TLs

00:09:19.360 --> 00:09:23.040
key and while I did that the industry

00:09:21.760 --> 00:09:25.279
was doing

00:09:23.040 --> 00:09:27.360
this that's like the running gag of this

00:09:25.279 --> 00:09:28.760
talk I show all kinds of interesting

00:09:27.360 --> 00:09:29.640
things the industry did and then show

00:09:28.760 --> 00:09:32.760
what I did

00:09:29.640 --> 00:09:34.519
in that time right so um next question

00:09:32.760 --> 00:09:37.600
where's the content I could just have

00:09:34.519 --> 00:09:39.079
files on disk like static HTML as before

00:09:37.600 --> 00:09:41.760
but I think that's not professional

00:09:39.079 --> 00:09:43.399
enough right so for a good CCC talk you

00:09:41.760 --> 00:09:45.360
need to be more

00:09:43.399 --> 00:09:46.920
professional also for a different

00:09:45.360 --> 00:09:51.000
project I had just written an elabs

00:09:46.920 --> 00:09:52.600
server so I decided to reuse it and uh

00:09:51.000 --> 00:09:54.040
while I did that the industry did this I

00:09:52.600 --> 00:09:55.839
I took this photo at the airport of

00:09:54.040 --> 00:09:57.560
Jerusalem so this is an actual ad it's

00:09:55.839 --> 00:09:59.800
not photoshopped right it's for north of

00:09:57.560 --> 00:10:02.760
gramman which is a um

00:09:59.800 --> 00:10:06.720
military contractor and it's about full

00:10:02.760 --> 00:10:06.720
spectrum cyber across all

00:10:06.800 --> 00:10:12.040
domains so why would I write my own elab

00:10:09.360 --> 00:10:14.880
server mostly because it's small and um

00:10:12.040 --> 00:10:17.640
because I'm an auditor by trade I know

00:10:14.880 --> 00:10:20.560
that if you want a chance to actually

00:10:17.640 --> 00:10:22.320
audit the code it needs to be small

00:10:20.560 --> 00:10:24.279
because that's a limited resource the

00:10:22.320 --> 00:10:27.360
time you can spend on auditing code

00:10:24.279 --> 00:10:30.399
right so postgress is a common SQL

00:10:27.360 --> 00:10:32.440
database uh slapd is the the open Lup

00:10:30.399 --> 00:10:34.839
implementation of the server and Tiny

00:10:32.440 --> 00:10:37.160
Lup is mine and you see it's much slower

00:10:34.839 --> 00:10:37.160
uh much

00:10:38.440 --> 00:10:44.240
smaller yeah so there was more to this

00:10:40.519 --> 00:10:44.240
ad campaign I collected a few funny

00:10:44.320 --> 00:10:52.360
images right so um if someone manages to

00:10:48.959 --> 00:10:54.959
hack the blog CGI or whatever module I

00:10:52.360 --> 00:10:57.399
use to to have connect the blog to the

00:10:54.959 --> 00:11:00.399
web server they can open any file that

00:10:57.399 --> 00:11:02.720
the blog can read right the uid can read

00:11:00.399 --> 00:11:05.880
so um I should probably do something

00:11:02.720 --> 00:11:07.560
about that that was the next step and

00:11:05.880 --> 00:11:08.750
the industry was starting to think about

00:11:07.560 --> 00:11:10.240
vulnerability

00:11:08.750 --> 00:11:12.519
[Music]

00:11:10.240 --> 00:11:14.440
management so there is a mechanism on

00:11:12.519 --> 00:11:16.600
Unix on Linux I did a separate talk

00:11:14.440 --> 00:11:19.120
about that uh on the last Congress it's

00:11:16.600 --> 00:11:21.000
called Secom and Secom can it's like a

00:11:19.120 --> 00:11:24.279
firewall for CS calls so I can use

00:11:21.000 --> 00:11:27.160
seccom to block open the open CIS which

00:11:24.279 --> 00:11:29.600
is used to open files um but if I have

00:11:27.160 --> 00:11:31.880
to use open myself

00:11:29.600 --> 00:11:33.480
then um I can't block it right so what

00:11:31.880 --> 00:11:35.760
you do about that for example my blog

00:11:33.480 --> 00:11:38.360
calls local time which converts unix's

00:11:35.760 --> 00:11:40.480
time into the local time zone and for

00:11:38.360 --> 00:11:44.920
that it opens a file containing the

00:11:40.480 --> 00:11:47.040
description of the uh system time zone

00:11:44.920 --> 00:11:49.360
and that's that calls open right so if I

00:11:47.040 --> 00:11:52.000
just disabled the open system call from

00:11:49.360 --> 00:11:54.720
my blog then it couldn't do the time

00:11:52.000 --> 00:11:57.639
translation and uh this is actually an

00:11:54.720 --> 00:12:00.079
old problem that also uh applies to set

00:11:57.639 --> 00:12:03.040
ID programs and has has applied to them

00:12:00.079 --> 00:12:05.959
for decades so what you can do is you

00:12:03.040 --> 00:12:08.720
can reorganize your code so before you

00:12:05.959 --> 00:12:11.680
block or before you drop privileges

00:12:08.720 --> 00:12:14.480
generally speaking you do uh the open

00:12:11.680 --> 00:12:16.760
calls in this in this example um and

00:12:14.480 --> 00:12:19.199
then you disable open and then you look

00:12:16.760 --> 00:12:21.120
at the the data provided by the attacker

00:12:19.199 --> 00:12:23.639
because if the attacker or any untrusted

00:12:21.120 --> 00:12:26.160
source is trying to hack you it is via

00:12:23.639 --> 00:12:27.680
data it gives you right it's the the

00:12:26.160 --> 00:12:29.480
environment is compromised so you look

00:12:27.680 --> 00:12:31.760
at what kind of uh elements in the

00:12:29.480 --> 00:12:33.680
environment are attacker supplied and

00:12:31.760 --> 00:12:35.720
before you look at a single bite in them

00:12:33.680 --> 00:12:38.440
you do all the dangerous stuff if you

00:12:35.720 --> 00:12:42.199
can right so in this case I call local

00:12:38.440 --> 00:12:44.959
time once before I drop the open CIS

00:12:42.199 --> 00:12:47.760
call and then my lipy will cach the the

00:12:44.959 --> 00:12:50.000
time zone data and the next time I call

00:12:47.760 --> 00:12:51.800
it after I have looked at the attacker

00:12:50.000 --> 00:12:54.279
supplied code there is no need to call

00:12:51.800 --> 00:12:57.600
open right so that's a major advantage

00:12:54.279 --> 00:13:01.560
of Secom over similar Technologies like

00:12:57.600 --> 00:13:04.360
SE Linux where where the all the the the

00:13:01.560 --> 00:13:07.440
the um prohibitions on CIS calls are

00:13:04.360 --> 00:13:08.720
applied to the whole process so there is

00:13:07.440 --> 00:13:09.839
this is an example and you should make

00:13:08.720 --> 00:13:11.839
use of it you should look at your

00:13:09.839 --> 00:13:13.680
process and you can see if you have the

00:13:11.839 --> 00:13:16.360
source code at least you can see which

00:13:13.680 --> 00:13:18.560
parts do I need to do before I can drop

00:13:16.360 --> 00:13:21.000
Privileges and you move them up right so

00:13:18.560 --> 00:13:25.040
that's what I

00:13:21.000 --> 00:13:27.519
did um this is actually uh a mockup from

00:13:25.040 --> 00:13:30.240
the Estonian cyber security

00:13:27.519 --> 00:13:34.959
Center so this is

00:13:30.240 --> 00:13:38.399
real okay so um next thought so let's

00:13:34.959 --> 00:13:40.639
say someone hacks the blog uh module and

00:13:38.399 --> 00:13:41.880
someone else uses the same module but

00:13:40.639 --> 00:13:44.040
supplies a

00:13:41.880 --> 00:13:46.160
password right this is a common problem

00:13:44.040 --> 00:13:47.800
in website in websites there's some kind

00:13:46.160 --> 00:13:50.560
of login something you get maybe a

00:13:47.800 --> 00:13:53.480
session token or whatever um and if

00:13:50.560 --> 00:13:56.040
someone manages to take over the the

00:13:53.480 --> 00:13:58.920
middleware or like the server component

00:13:56.040 --> 00:14:01.079
they can see uh all other connections

00:13:58.920 --> 00:14:03.360
too if they are handled by the same

00:14:01.079 --> 00:14:05.880
process right that's a that's a major

00:14:03.360 --> 00:14:08.880
problem um and you can do something

00:14:05.880 --> 00:14:12.199
about it so that's the good news

00:14:08.880 --> 00:14:14.560
here uh and in in my example it led to

00:14:12.199 --> 00:14:18.440
me using CGI instead of fast CGI which

00:14:14.560 --> 00:14:21.040
is fast CGI is a newer version of CGI

00:14:18.440 --> 00:14:24.440
and the idea with fast CGI is that you

00:14:21.040 --> 00:14:27.079
don't spawn a new process for every

00:14:24.440 --> 00:14:30.320
request but you have like a Unix domain

00:14:27.079 --> 00:14:32.199
socket or another socket to a fast CGI

00:14:30.320 --> 00:14:35.680
process and that opens maybe a threat

00:14:32.199 --> 00:14:37.600
per request or something but um usually

00:14:35.680 --> 00:14:39.360
in fast CGI you try to handle the

00:14:37.600 --> 00:14:42.440
requests in the same process and then

00:14:39.360 --> 00:14:44.720
you can use that process to cach data so

00:14:42.440 --> 00:14:47.720
there's a perf advantage to using fast

00:14:44.720 --> 00:14:50.680
CGI but for security reasons um I don't

00:14:47.720 --> 00:14:53.040
I don't use fast CGI so I can't do

00:14:50.680 --> 00:14:54.360
caching right so that's a major downside

00:14:53.040 --> 00:14:57.000
and you would expect the block to be

00:14:54.360 --> 00:14:59.040
really really slow in the end um so

00:14:57.000 --> 00:15:02.079
first thing I need to use CGI instead of

00:14:59.040 --> 00:15:05.519
fast CGI and secondly you could still

00:15:02.079 --> 00:15:07.759
use debug apis so if you use GDB or

00:15:05.519 --> 00:15:10.680
another debugger to to look at another

00:15:07.759 --> 00:15:12.519
process they use an API called p trce u

00:15:10.680 --> 00:15:17.000
but that's a CIS call so I can use set

00:15:12.519 --> 00:15:19.920
comp to disallow pce if I do those two

00:15:17.000 --> 00:15:21.839
and the attacker takes over a Blog

00:15:19.920 --> 00:15:24.320
process all they can see is the data

00:15:21.839 --> 00:15:26.920
they Supply themselves right that's a

00:15:24.320 --> 00:15:26.920
major

00:15:27.279 --> 00:15:31.519
advantage Okay so Ina is actually in U

00:15:29.800 --> 00:15:33.600
agency which I find really disturbing

00:15:31.519 --> 00:15:38.040
because they're burning lots of taxpayer

00:15:33.600 --> 00:15:40.399
money anyway so let's assume um the

00:15:38.040 --> 00:15:42.720
attacker can hack my blog they can still

00:15:40.399 --> 00:15:45.040
circumvent any access control I do in

00:15:42.720 --> 00:15:49.079
the blog so for example if I have an

00:15:45.040 --> 00:15:51.360
admin site or some login site part of

00:15:49.079 --> 00:15:54.000
the website um and it's handled through

00:15:51.360 --> 00:15:56.399
the same program and the access control

00:15:54.000 --> 00:15:59.000
is done in the blog CGI and someone

00:15:56.399 --> 00:16:03.600
manages to hack my blog CGI they could

00:15:59.000 --> 00:16:06.000
just skip that so um it's really hard to

00:16:03.600 --> 00:16:07.880
do access restrictions that can be

00:16:06.000 --> 00:16:09.759
circumvented if you do them in your own

00:16:07.880 --> 00:16:13.440
code so the solution is not do it in

00:16:09.759 --> 00:16:15.639
your own code um I don't do any access

00:16:13.440 --> 00:16:18.880
restriction in the blog I do it in the

00:16:15.639 --> 00:16:20.639
elab server so if you connect to my blog

00:16:18.880 --> 00:16:22.160
and Supply a password then the blog

00:16:20.639 --> 00:16:24.440
doesn't know if the password is right or

00:16:22.160 --> 00:16:25.680
not right there's an an an for example

00:16:24.440 --> 00:16:27.560
there's an interface where you can add

00:16:25.680 --> 00:16:29.279
new block entries or you can edit an old

00:16:27.560 --> 00:16:31.040
one and for you need to supply

00:16:29.279 --> 00:16:33.000
credentials but the block CGI doesn't

00:16:31.040 --> 00:16:34.680
know if they are right or not it opens

00:16:33.000 --> 00:16:36.920
the connections to the elab server with

00:16:34.680 --> 00:16:40.880
that credential and then the elab server

00:16:36.920 --> 00:16:44.759
says yes or no so since we uh removed

00:16:40.880 --> 00:16:46.800
access to the P SS uh and the the

00:16:44.759 --> 00:16:48.079
processes are isolated from each other

00:16:46.800 --> 00:16:50.040
that means there is nothing to

00:16:48.079 --> 00:16:52.680
circumvent here so if someone hacks my

00:16:50.040 --> 00:16:54.639
blog the only Advantage uh they get is

00:16:52.680 --> 00:16:56.240
they can do the exact same stuff they

00:16:54.639 --> 00:16:59.639
could do before basically they can just

00:16:56.240 --> 00:17:02.399
talk to the L server

00:16:59.639 --> 00:17:04.360
okay so I'm starting to get into uh

00:17:02.399 --> 00:17:06.839
James Bond territory here right with the

00:17:04.360 --> 00:17:09.000
attacks they getting more

00:17:06.839 --> 00:17:10.520
convoluted right so the industry started

00:17:09.000 --> 00:17:13.199
doing threat intelligence feeds which

00:17:10.520 --> 00:17:15.760
are useless don't spend money on those

00:17:13.199 --> 00:17:19.280
okay so let's say the attacker hacked my

00:17:15.760 --> 00:17:22.000
blog and then went to my tiny UB and now

00:17:19.280 --> 00:17:24.120
is attacking tiny elab then they can

00:17:22.000 --> 00:17:26.360
watch other logins because tiny Elder

00:17:24.120 --> 00:17:29.080
handles connections from other instances

00:17:26.360 --> 00:17:30.679
of the blog too right so the same

00:17:29.080 --> 00:17:33.200
problem we had before we just moved the

00:17:30.679 --> 00:17:35.679
gold post a little and we need to

00:17:33.200 --> 00:17:37.840
prevent this and the the obvious

00:17:35.679 --> 00:17:41.799
solution is to do the same thing we did

00:17:37.840 --> 00:17:44.840
with the blog um we have one process of

00:17:41.799 --> 00:17:48.799
the elab server per request and then we

00:17:44.840 --> 00:17:50.840
just allow P Trace right so now you

00:17:48.799 --> 00:17:52.559
can't watch even if you get code

00:17:50.840 --> 00:17:54.880
execution inside the elab server you

00:17:52.559 --> 00:17:58.960
can't watch what passwords other people

00:17:54.880 --> 00:18:01.240
use you can still see okay does some

00:17:58.960 --> 00:18:04.360
[ __ ] again you can still see the

00:18:01.240 --> 00:18:06.480
password in the UB store right so the

00:18:04.360 --> 00:18:08.360
elab server has to has a version of the

00:18:06.480 --> 00:18:10.760
password to authenticate against and the

00:18:08.360 --> 00:18:12.840
industry practice best practice is to

00:18:10.760 --> 00:18:14.360
use salted hashers so the password is

00:18:12.840 --> 00:18:17.080
not actually in the

00:18:14.360 --> 00:18:19.600
store still if someone manages to attack

00:18:17.080 --> 00:18:22.080
tiny elab through the blog they can

00:18:19.600 --> 00:18:24.880
extract the hashes and try to crack them

00:18:22.080 --> 00:18:27.919
but since I'm the only one adding users

00:18:24.880 --> 00:18:31.640
I can control the password complexity so

00:18:27.919 --> 00:18:34.640
good luck frood forcing that

00:18:31.640 --> 00:18:34.640
right

00:18:34.760 --> 00:18:39.400
okay so uh this is actually a real

00:18:37.559 --> 00:18:41.679
problem not not for my blog specifically

00:18:39.400 --> 00:18:43.320
but for other web services or services

00:18:41.679 --> 00:18:44.760
that are reachable from the internet

00:18:43.320 --> 00:18:46.799
what if an attacker doesn't want to

00:18:44.760 --> 00:18:50.240
steal my data but it wants to encrypt

00:18:46.799 --> 00:18:54.080
them so the ransomware what can you do

00:18:50.240 --> 00:18:56.400
about that and um my idea was to make

00:18:54.080 --> 00:18:58.000
the data store read only so the UB

00:18:56.400 --> 00:19:00.679
server has a data store that contains

00:18:58.000 --> 00:19:03.159
all the blog entries and let's read only

00:19:00.679 --> 00:19:05.440
to the add up process you can only read

00:19:03.159 --> 00:19:08.200
from it and if you want to write to it

00:19:05.440 --> 00:19:10.039
for example to add a new entry it gets

00:19:08.200 --> 00:19:10.919
appended to a second file which I call

00:19:10.039 --> 00:19:13.559
the

00:19:10.919 --> 00:19:15.880
journal so SQL databases have a similar

00:19:13.559 --> 00:19:17.760
concept and they use it to to roll back

00:19:15.880 --> 00:19:19.320
transactions I can do the same thing

00:19:17.760 --> 00:19:22.200
it's basically a log

00:19:19.320 --> 00:19:25.159
file and that means um all the

00:19:22.200 --> 00:19:27.360
differences from the last time the store

00:19:25.159 --> 00:19:29.400
was created the Ron store all the

00:19:27.360 --> 00:19:32.240
differences are sequentially in the log

00:19:29.400 --> 00:19:34.320
file in the journal so that that the

00:19:32.240 --> 00:19:36.480
performance gets worse the bigger the

00:19:34.320 --> 00:19:39.480
journal gets so every now and then I

00:19:36.480 --> 00:19:41.600
need to combine the readon part and the

00:19:39.480 --> 00:19:44.120
journal to a new bigger readon part and

00:19:41.600 --> 00:19:44.120
I do that

00:19:44.679 --> 00:19:49.640
manually um because tiny elab couldn't

00:19:47.880 --> 00:19:51.039
do it because I didn't allow tiny elab

00:19:49.640 --> 00:19:54.960
to write the store right that was part

00:19:51.039 --> 00:19:57.120
of the security here and uh so um with

00:19:54.960 --> 00:19:59.000
set comp I can just disable whole CIS

00:19:57.120 --> 00:20:00.880
calls I can also install filters so I

00:19:59.000 --> 00:20:03.679
can say open is allowed but only if you

00:20:00.880 --> 00:20:06.440
use o append o append in the open sis

00:20:03.679 --> 00:20:09.280
call on Unix means every right you do to

00:20:06.440 --> 00:20:12.600
this uh descriptor is automatically

00:20:09.280 --> 00:20:16.159
added to the end so I know if someone

00:20:12.600 --> 00:20:18.840
manages to to access the tiny Elda

00:20:16.159 --> 00:20:20.799
binary and can write to my journal then

00:20:18.840 --> 00:20:22.320
the only place the changes can show up

00:20:20.799 --> 00:20:24.600
is at the end and that's actually a

00:20:22.320 --> 00:20:27.200
really good good thing to have because

00:20:24.600 --> 00:20:29.840
it means if someone hacks me and adds

00:20:27.200 --> 00:20:32.720
junk to my blog I can only remove at the

00:20:29.840 --> 00:20:35.360
end and I'm good again compare that to a

00:20:32.720 --> 00:20:38.320
usual SQL database um if someone wrote

00:20:35.360 --> 00:20:40.919
to the database you need to in to to

00:20:38.320 --> 00:20:42.760
play a backup uh in to restore backup

00:20:40.919 --> 00:20:45.600
because they could have changed anything

00:20:42.760 --> 00:20:47.000
anywhere right so but tiny adup doesn't

00:20:45.600 --> 00:20:48.840
even have file system level permissions

00:20:47.000 --> 00:20:50.880
to change anything in the store so I can

00:20:48.840 --> 00:20:53.320
re re uh sleep

00:20:50.880 --> 00:20:56.440
soundly yeah the industry spent money on

00:20:53.320 --> 00:20:56.440
cyber security mesh

00:20:56.480 --> 00:21:00.480
architecture right so the journal

00:20:58.880 --> 00:21:02.280
integration has to be done by me

00:21:00.480 --> 00:21:05.440
manually out of band so it's not

00:21:02.280 --> 00:21:08.880
something an automated process does um I

00:21:05.440 --> 00:21:10.360
do it manually and when I'm doing it um

00:21:08.880 --> 00:21:12.520
because it's not that much data it's

00:21:10.360 --> 00:21:14.600
like for a week or two I can just read

00:21:12.520 --> 00:21:16.480
it again and see if something doesn't

00:21:14.600 --> 00:21:19.120
look

00:21:16.480 --> 00:21:21.080
right this may not be available to all

00:21:19.120 --> 00:21:22.760
other scenarios but uh you have to

00:21:21.080 --> 00:21:25.200
realize if you have bigger data it's

00:21:22.760 --> 00:21:27.039
usually not all the data that's big most

00:21:25.200 --> 00:21:29.960
of it is usually static and readon and

00:21:27.039 --> 00:21:32.840
then you have some logs that are or you

00:21:29.960 --> 00:21:35.400
know billing data that grows and grows

00:21:32.840 --> 00:21:37.799
but usually there's part of the data and

00:21:35.400 --> 00:21:40.600
this is the the part with the you know

00:21:37.799 --> 00:21:43.679
um uh identifying information personally

00:21:40.600 --> 00:21:46.120
identifying information or you know Bill

00:21:43.679 --> 00:21:48.120
billing details that stuff is usually

00:21:46.120 --> 00:21:51.440
small and mostly static and you could

00:21:48.120 --> 00:21:51.440
use this strategy for that

00:21:52.760 --> 00:21:58.799
too well yeah

00:21:56.159 --> 00:22:01.600
okay so the attack can still write

00:21:58.799 --> 00:22:03.919
garbage to my blog that's still not good

00:22:01.600 --> 00:22:06.760
right but since all they can do is a pen

00:22:03.919 --> 00:22:09.240
to the journal I can use my text editor

00:22:06.760 --> 00:22:11.760
open the journal and truncate at some

00:22:09.240 --> 00:22:13.840
point and then I get all my data back

00:22:11.760 --> 00:22:16.360
till the point where they started puting

00:22:13.840 --> 00:22:18.720
the blog right this is still bad but

00:22:16.360 --> 00:22:21.400
it's it's a very good position to be in

00:22:18.720 --> 00:22:23.919
if there's an uh emergency because you

00:22:21.400 --> 00:22:26.080
can basically investigate calmly first

00:22:23.919 --> 00:22:30.000
you turn off right AIS then you you

00:22:26.080 --> 00:22:32.919
delete the vandalism and the journal and

00:22:30.000 --> 00:22:34.679
um you know you haven't lost anything

00:22:32.919 --> 00:22:37.120
because if you want to delete an entry

00:22:34.679 --> 00:22:39.360
in the blog you could do that too but

00:22:37.120 --> 00:22:41.200
that means at the end of the journal you

00:22:39.360 --> 00:22:43.240
append a statement saying delete this

00:22:41.200 --> 00:22:45.799
record and I can just remove that and I

00:22:43.240 --> 00:22:48.960
get the record back right so there's no

00:22:45.799 --> 00:22:51.120
way for someone vandalizing my blog to U

00:22:48.960 --> 00:22:53.320
damage any data that was in it before

00:22:51.120 --> 00:22:56.000
all they can do is a pen junk at the end

00:22:53.320 --> 00:22:58.400
and I can live with that right this is

00:22:56.000 --> 00:23:01.200
this is should be the guiding thought

00:22:58.400 --> 00:23:03.480
between any security you do um if

00:23:01.200 --> 00:23:05.559
someone hacks you you will be in a very

00:23:03.480 --> 00:23:07.720
stressful position the boss will be

00:23:05.559 --> 00:23:10.279
behind you breathing down your neck are

00:23:07.720 --> 00:23:12.559
We Done Yet is it fixed and you want to

00:23:10.279 --> 00:23:14.600
have as little to do as possible at that

00:23:12.559 --> 00:23:17.279
time you want to to move all the stress

00:23:14.600 --> 00:23:19.120
to before you get hacked because then

00:23:17.279 --> 00:23:22.520
you have more

00:23:19.120 --> 00:23:24.760
time okay the industry did other things

00:23:22.520 --> 00:23:28.039
again

00:23:24.760 --> 00:23:30.880
um so what if the attacker doesn't write

00:23:28.039 --> 00:23:33.360
garbage to the journal but writes some

00:23:30.880 --> 00:23:35.279
exploit to the journal that the next

00:23:33.360 --> 00:23:38.520
tiny El up instance that reads the

00:23:35.279 --> 00:23:41.120
journal gets compromised

00:23:38.520 --> 00:23:43.480
by that is a

00:23:41.120 --> 00:23:46.799
possibility and that would be

00:23:43.480 --> 00:23:49.279
bad so agreed that there still a problem

00:23:46.799 --> 00:23:51.200
but uh realize how Preposterous the

00:23:49.279 --> 00:23:54.039
scenario is so we are talking about an

00:23:51.200 --> 00:23:57.000
attacker who found stable zero day in

00:23:54.039 --> 00:23:59.600
the blog and then used that and another

00:23:57.000 --> 00:24:01.679
stable zero day in tiny ad up to write

00:23:59.600 --> 00:24:05.600
to the journal and then have the

00:24:01.679 --> 00:24:09.360
third uh third zero day to compromise

00:24:05.600 --> 00:24:11.440
the the journal passing code so I mean

00:24:09.360 --> 00:24:13.440
yes it is still a problem but we reduced

00:24:11.440 --> 00:24:15.320
the risk

00:24:13.440 --> 00:24:18.320
significantly uh and that is what I'm

00:24:15.320 --> 00:24:20.640
trying to to tell you here uh it's not

00:24:18.320 --> 00:24:22.600
it's not all or nothing it's good enough

00:24:20.640 --> 00:24:25.440
if you can half the

00:24:22.600 --> 00:24:28.760
risk that's already very important and

00:24:25.440 --> 00:24:32.200
you should do it so as much as you can

00:24:28.760 --> 00:24:34.039
uh slice off the risk the better the

00:24:32.200 --> 00:24:37.320
better off you will be if something

00:24:34.039 --> 00:24:40.320
happens right because the smaller the

00:24:37.320 --> 00:24:42.200
code is that is still attackable the

00:24:40.320 --> 00:24:44.000
more you can audit it and be sure it's

00:24:42.200 --> 00:24:46.799
good you show it to your friends and

00:24:44.000 --> 00:24:48.919
they can audit it too uh and and you

00:24:46.799 --> 00:24:50.480
need to save yourself that time because

00:24:48.919 --> 00:24:52.880
it happens every now and then that I get

00:24:50.480 --> 00:24:54.640
to get to see the whole code base and

00:24:52.880 --> 00:24:56.480
the usual code base for commercial

00:24:54.640 --> 00:24:59.799
products is like gigabytes of source

00:24:56.480 --> 00:25:02.039
code nobody can read that like I'm I'm

00:24:59.799 --> 00:25:05.440
good I'm not that

00:25:02.039 --> 00:25:07.000
good so um this is a good place to be in

00:25:05.440 --> 00:25:10.760
I think right so the industry was

00:25:07.000 --> 00:25:13.240
selling dos mitigation sure whatever so

00:25:10.760 --> 00:25:15.760
what happens if someone attacks the web

00:25:13.240 --> 00:25:18.760
server that is still a big

00:25:15.760 --> 00:25:22.799
problem um and it's

00:25:18.760 --> 00:25:24.200
actually uh it it's a full damage right

00:25:22.799 --> 00:25:25.919
that's the worst that can happen if

00:25:24.200 --> 00:25:28.399
someone manages to attack the web server

00:25:25.919 --> 00:25:30.679
they can see all traffic coming through

00:25:28.399 --> 00:25:32.399
they can look inside TLS secured

00:25:30.679 --> 00:25:34.399
connections and they can sniff all the

00:25:32.399 --> 00:25:37.039
passwords so that's really

00:25:34.399 --> 00:25:40.200
bad unfortunately there is not too much

00:25:37.039 --> 00:25:44.679
you can do about that

00:25:40.200 --> 00:25:45.840
um you could do uh um a separation so

00:25:44.679 --> 00:25:47.919
this is something people have been

00:25:45.840 --> 00:25:49.480
talking about for a while open S AG is

00:25:47.919 --> 00:25:51.919
doing this they moved the dangerous

00:25:49.480 --> 00:25:54.840
crypto stuff in a second process and use

00:25:51.919 --> 00:25:56.399
sandboxing to lock down that process uh

00:25:54.840 --> 00:25:58.440
that could be done but nobody has done

00:25:56.399 --> 00:26:00.960
it for open SSL yet so so open SSL

00:25:58.440 --> 00:26:02.960
doesn't support that um my web server

00:26:00.960 --> 00:26:05.200
also supports embed TLS they don't

00:26:02.960 --> 00:26:07.399
support that too so I I could spend time

00:26:05.200 --> 00:26:09.200
on that and I've been actually um

00:26:07.399 --> 00:26:11.000
spending some time already but it's not

00:26:09.200 --> 00:26:13.320
it's not ready yet but this would be a

00:26:11.000 --> 00:26:15.600
good way to reduce the risk and you may

00:26:13.320 --> 00:26:18.600
notice that the the tools I'm using to

00:26:15.600 --> 00:26:20.840
reduce risks are actually just a handful

00:26:18.600 --> 00:26:23.440
there's not it's not you know it's not

00:26:20.840 --> 00:26:25.760
witchcraft I'm I'm not inventing new

00:26:23.440 --> 00:26:28.039
ways to look at things I'm doing the

00:26:25.760 --> 00:26:30.000
same thing again I'm identifying the

00:26:28.039 --> 00:26:32.679
part of the code that's dangerous and

00:26:30.000 --> 00:26:34.640
then I think about how I can make that

00:26:32.679 --> 00:26:37.440
part smaller maybe put it in a different

00:26:34.640 --> 00:26:38.679
process lock it down so we need to do

00:26:37.440 --> 00:26:42.000
the same thing with the web server

00:26:38.679 --> 00:26:46.640
obviously um but it's an ongoing

00:26:42.000 --> 00:26:49.600
process yeah so again whatever um why

00:26:46.640 --> 00:26:51.399
haven't I done that yet uh so in my web

00:26:49.600 --> 00:26:53.360
server you can it's a build time

00:26:51.399 --> 00:26:55.159
decision if you want SSL support or not

00:26:53.360 --> 00:26:57.600
and you can see the binary is

00:26:55.159 --> 00:26:59.360
significantly bigger if you have SSL and

00:26:57.600 --> 00:27:01.320
I'm showing you this because it means

00:26:59.360 --> 00:27:04.520
the the bulk of the attack surface is

00:27:01.320 --> 00:27:06.840
the SSL code it's not my code so if I if

00:27:04.520 --> 00:27:10.320
I can put the SSL code in a different

00:27:06.840 --> 00:27:11.880
process they still need to see the the

00:27:10.320 --> 00:27:13.679
private key because that's what TLS

00:27:11.880 --> 00:27:16.000
needs the private key otherwise it can't

00:27:13.679 --> 00:27:17.679
do the crypto so the bug of the attack

00:27:16.000 --> 00:27:19.919
surface would still have access to the

00:27:17.679 --> 00:27:21.480
key I can still do it because there

00:27:19.919 --> 00:27:24.840
might be bucks in my code and not the

00:27:21.480 --> 00:27:28.039
SSL code but that's just 5% of the of

00:27:24.840 --> 00:27:30.000
the overall attack surface so um

00:27:28.039 --> 00:27:32.480
it I will probably do it at some point

00:27:30.000 --> 00:27:35.799
but it's I don't expect miracles from it

00:27:32.480 --> 00:27:38.919
bugs and open SSL will kill kill me

00:27:35.799 --> 00:27:38.919
there's not much I can do about

00:27:41.480 --> 00:27:45.640
that okay so I know what you're

00:27:46.960 --> 00:27:52.399
thinking what about colel

00:27:50.039 --> 00:27:54.679
bugs so I looked at a few of the recent

00:27:52.399 --> 00:27:57.039
kernel bugs and it turns out that they

00:27:54.679 --> 00:28:00.159
usually apply to SSS that are rarely

00:27:57.039 --> 00:28:01.919
used in regular programs and uh because

00:28:00.159 --> 00:28:05.200
I'm blocking all the CIS calls I don't

00:28:01.919 --> 00:28:07.279
really need none of them apply to me

00:28:05.200 --> 00:28:10.720
right and this is a this is a pattern

00:28:07.279 --> 00:28:11.960
with Colonel bugs um uh there is a a

00:28:10.720 --> 00:28:15.600
project called

00:28:11.960 --> 00:28:19.519
Sandstorm um that also uses p trce and

00:28:15.600 --> 00:28:22.679
and Secom tracing to reduce the csol U

00:28:19.519 --> 00:28:25.240
surface and then puts regular Services

00:28:22.679 --> 00:28:28.200
into a Sandbox for for web services and

00:28:25.240 --> 00:28:30.360
they uh evaded all kinds of of Kernel

00:28:28.200 --> 00:28:32.519
bucks just because of that so this is

00:28:30.360 --> 00:28:34.320
like a zero effort thing because

00:28:32.519 --> 00:28:36.760
obviously if you have a list of CIS

00:28:34.320 --> 00:28:37.840
calls you'd use a white list and you you

00:28:36.760 --> 00:28:39.600
have a list of things you are

00:28:37.840 --> 00:28:42.519
explicitely low and the rest is is

00:28:39.600 --> 00:28:44.600
disabled not the other way around right

00:28:42.519 --> 00:28:47.480
so none of the usual kernel bugs apply

00:28:44.600 --> 00:28:49.519
to me um because of the the seom stuff I

00:28:47.480 --> 00:28:51.960
already do so kernel bugs aren't as big

00:28:49.519 --> 00:28:54.200
of a problem as you might think at least

00:28:51.960 --> 00:28:56.399
I still have them if I haven't patched

00:28:54.200 --> 00:28:58.960
but you can't get to them via the

00:28:56.399 --> 00:29:01.039
blog so I have a small confession to

00:28:58.960 --> 00:29:04.679
make uh I'm a bit of a troll and that

00:29:01.039 --> 00:29:06.960
applies to this project as well so um I

00:29:04.679 --> 00:29:10.799
use the worst programming

00:29:06.960 --> 00:29:12.679
language I used C right so I'm trolling

00:29:10.799 --> 00:29:14.399
the security people and then I'm

00:29:12.679 --> 00:29:15.760
trolling the Java people who have been

00:29:14.399 --> 00:29:17.440
saying you should use multi-threading

00:29:15.760 --> 00:29:20.399
for performance and not have one process

00:29:17.440 --> 00:29:24.360
per request so I'm doing actually two

00:29:20.399 --> 00:29:25.960
fork and xx per request um I'm trolling

00:29:24.360 --> 00:29:28.679
the database people I don't have any

00:29:25.960 --> 00:29:30.279
caching I don't have connection pool TOs

00:29:28.679 --> 00:29:32.320
and the perf people too because I'm

00:29:30.279 --> 00:29:34.640
still faster than most of the regular

00:29:32.320 --> 00:29:36.679
Solutions so there is no there's really

00:29:34.640 --> 00:29:39.799
no downside if you if you architect your

00:29:36.679 --> 00:29:42.120
software to use this kind of thing um it

00:29:39.799 --> 00:29:44.399
will be slower than other ways to do it

00:29:42.120 --> 00:29:47.559
but most other software isn't as fast

00:29:44.399 --> 00:29:49.600
anyway so there's enough Headway that

00:29:47.559 --> 00:29:52.320
you can use to do security instead of

00:29:49.600 --> 00:29:54.679
performance you will still be

00:29:52.320 --> 00:29:58.240
faster so let's recap the the

00:29:54.679 --> 00:30:00.679
methodology I used um first I make a

00:29:58.240 --> 00:30:02.679
list of all the attacks I can think of

00:30:00.679 --> 00:30:04.360
and this means concrete attacks so what

00:30:02.679 --> 00:30:07.000
could happen and what would what would

00:30:04.360 --> 00:30:09.480
be the problem then right and then I

00:30:07.000 --> 00:30:11.880
think for every item on the list I

00:30:09.480 --> 00:30:14.000
consider how to prevent this can I

00:30:11.880 --> 00:30:16.039
prevent this uh what what I need to do

00:30:14.000 --> 00:30:17.640
and then I do it right so that's easy

00:30:16.039 --> 00:30:20.360
it's like this the fine man problem

00:30:17.640 --> 00:30:23.200
solving algorithm in spirit and this

00:30:20.360 --> 00:30:25.519
process is called threat modeling it's

00:30:23.200 --> 00:30:27.320
it's like a it's dirty word because it

00:30:25.519 --> 00:30:28.760
sounds like there's effort involved and

00:30:27.320 --> 00:30:31.480
nobody wants to do it but it's really

00:30:28.760 --> 00:30:32.880
it's easy it's just these these steps

00:30:31.480 --> 00:30:34.360
you you look at your software you

00:30:32.880 --> 00:30:36.279
consider all the ways it could be

00:30:34.360 --> 00:30:38.240
attacked and then you consider what you

00:30:36.279 --> 00:30:39.960
could do to prevent the attack or in

00:30:38.240 --> 00:30:41.320
some cases you can't prevent the attack

00:30:39.960 --> 00:30:43.720
and then you say well that's the risk I

00:30:41.320 --> 00:30:47.240
have to live with right so that's called

00:30:43.720 --> 00:30:50.360
threat moding you should try it it's

00:30:47.240 --> 00:30:52.519
awesome and um you saw that I'm trying

00:30:50.360 --> 00:30:55.320
to optimize something here I go for a

00:30:52.519 --> 00:30:57.919
specific Target in this case I want as

00:30:55.320 --> 00:30:59.840
little code as possible

00:30:57.919 --> 00:31:02.840
um the more code there is the more bugs

00:30:59.840 --> 00:31:04.639
there will be that's an a very old uh

00:31:02.840 --> 00:31:07.000
Insight from I think it was originally

00:31:04.639 --> 00:31:08.880
in IBM study and they basically found

00:31:07.000 --> 00:31:10.480
that the number of bugs in code is a

00:31:08.880 --> 00:31:12.639
function of the lines of code in the

00:31:10.480 --> 00:31:15.399
code so there's a little more to it but

00:31:12.639 --> 00:31:17.679
basically it's true so and it's not just

00:31:15.399 --> 00:31:19.519
any code I want to have less of um if

00:31:17.679 --> 00:31:22.159
the code is dangerous I particularly

00:31:19.519 --> 00:31:25.159
want to have less of it and the the most

00:31:22.159 --> 00:31:27.360
important category to to make smaller is

00:31:25.159 --> 00:31:29.880
the the code that enforces security

00:31:27.360 --> 00:31:31.720
guarantees so like one security

00:31:29.880 --> 00:31:33.320
guarantee would be you can't log in if

00:31:31.720 --> 00:31:35.320
you don't have the right password right

00:31:33.320 --> 00:31:38.559
so the code that checks that I wanted to

00:31:35.320 --> 00:31:40.720
be as small as possible um one or two

00:31:38.559 --> 00:31:42.799
lines of code if if I can manage it and

00:31:40.720 --> 00:31:45.360
then it's obvious if it if it's wrong or

00:31:42.799 --> 00:31:47.720
not the more complex the code is the

00:31:45.360 --> 00:31:49.080
less less easy would it be to see if

00:31:47.720 --> 00:31:51.039
it's correct or not and that's what you

00:31:49.080 --> 00:31:53.519
want in the end you want to be sure the

00:31:51.039 --> 00:31:55.440
code is correct so how far did I get

00:31:53.519 --> 00:31:57.279
it's actually pretty amazing I think um

00:31:55.440 --> 00:32:01.000
you can write an elabs server in five

00:31:57.279 --> 00:32:04.279
,000 lines of code the blog is 3.5 lines

00:32:01.000 --> 00:32:07.320
of kilo lines of code um plus the Ed

00:32:04.279 --> 00:32:09.159
client Library plus zet lip um but I'm

00:32:07.320 --> 00:32:11.320
only using zet lip to compress not to

00:32:09.159 --> 00:32:13.880
decompress so most attack scenarios

00:32:11.320 --> 00:32:16.279
doesn't don't apply to to my usage of Z

00:32:13.880 --> 00:32:19.000
Li um and the web server is also pretty

00:32:16.279 --> 00:32:21.320
slow if you only look at the HTTP code

00:32:19.000 --> 00:32:23.639
unfortunately uh it also contains the

00:32:21.320 --> 00:32:25.600
SSL Library which is orders of magnitude

00:32:23.639 --> 00:32:28.039
more than my code and that's how you

00:32:25.600 --> 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