37C3 - Writing secure software

33C3 preroll music

basically textbooks have been written

about it countless talks have been

have been Illuminating all of the errors

of our ways and still all those sucky

software is out there but

Fefe over here the hero of our show

has put out has put all of these best

practices into you know into his work to

try to create a secure website he's

going to show us how it's done so that

we can all sleep way better at night and

with that template go back and

and secure our own software and so with

that I'm going to hand it right over to

Fefe give him a round of applause

applause

thank you I have to start

with an apology because I did submit

this talk but it was rejected so the

slides are not at the stage where they

should be these are our slides for a

previous version of the talk it contains

all the material and I tried to update

it more but that destroyed the flow so

we we're stuck with it basically the

difference was the the audience so while

I expect more developers here the other

audience was more and hackers and

business people so I try to get them

from where they are and the main question

usually is "are we there yet?" right

so about me you probably

seen this before I'm a code auditor by

trade I have a small company and

companies show us their code and I show

them bugs I find in them quite easy

but before we start I have a small

celebration to do this actually happened

just a day before the first time I

talked about this so Kaspersky

message they found some malware introduced

tied to libc

which I have written so this is

like a

applause

some of the malware people

know what's good

so basically the main question when I

talk to customers is we spend so much

money on this why isn't it working

and the answer is you're doing it wrong

so I will try to show now what exactly
is wrong

and there's a small preface here people

usually say there's no time to do this

right and that's just wrong you have

exactly as much time per day as other

people who did great things so you can

do great things too you just need to do it

so let's play a little warm-up game

it's called how it started and how

it's going so let's have a demo round

IBM Watson is revolutionizing

10 Industries and it's going like this

whatever happened to IBM Watson that's a

typical pattern in the security industry

right so here's another one how it started

revolutionize security with AI

right we all know where this is going

laugther

right so that's the pattern

let's play IT security mine sweeper

right so everybody here probably

knows who Gartner is they publish

recommendations and they even have a

voting section where people can say

this is the best product in this section

right so let's look at a few of them and

see what happened to people who trusted
Gartner

first is a firewall right so how

it started the number one recommendation

is for Fortinet and they have a lot of

marketing gibberish

laughter

and if you look how it's going it's not

going so good

so let's extend the pattern a bit

why what happened to me in this regard

so I don't need a firewall

I don't have any ports open that I need
blocking right

so you don't need this

strictly speaking you don't need it

next discipline endpoint protection

so it started with Trellix this is the

number one recommendation on Gartner

I hadn't heard of them there like can make

a feed joint venture or something

who cares

they also have great marketing gibberish

and then if you look at what happened

it's like they made it worse

okay so this didn't apply to me

either because I don't use snake oil

let's see the third one password manager

also very popular

how it started recommended LastPass

you probably know where this is going

laugther

yeah they got owned and then

people got owned

so you may notice a pattern here

this didn't apply to me because

I deserve a password authentication use

public key which has been available for

decades right so small bonus

the last one 2FA

Gartner recommends Duo which has

been bought by Cisco but doesn't matter

so if you look at what Duo does

your server asks the cloud for

permission the cloud goes to the telephone

telephone shows a popup you click yes

and then the cloud tells the server it's

okay you can let them in if you look

really closely you can notice the cloud

doesn't have to do the popup it can just

say sure so this comes pre-owned

there is no need to hack anything here

laugther

and something many people don't

realize you don't need two factor

if you have public key that's already the
second factor

Okay, so

yeah let's skip over this briefly

Splunk is the the recommend option here

and they make the organization

more resilient unless you install it

laughter

applause

okay so this one is dear to my heart

because people start arguing about

whether to install patches and

which patch to install first and it used

to be simple you look for problems

then you install the patches and then

it got a bit more complicated and

the result is this right

that's a famous podcast in Germany

it's about municipality who got owned

by ransomware and then had to call the

army for help

inaudible chatter in crowd

and what you should do I'm having

this for completeness install all patches

immediately but that's a separate talk

right so you may notice a pattern here

the IT security industry

recommends something and

if you do it you're [ __ ] so don't do it

in case you can't read this says snake

repellent granules and then there's a

snake sleeping next to it

laugther

coughing

right so if we can't trust the

recommendations of the industry what
shall we do

and so I had a lot of

time on my hands because I didn't have

to clean up after crappy IT security

industry recommendations so what

what did I do with my time

and I decided I need a Blog

some time ago now and I started

thinking what do I need and it's

actually not that much I could have just

shown basically static content a little

search function would be good but it's

optional um I didn't need comments for

legal reasons because people start

posting like links to maware or

whatever I don't want that I don't

need that right so the first version was

actually really easy it was a small

standard web server and I had the

blog entries a static HTML files

one file per month it was actually really

easy if you want to search you just can

ask Google and limit it to my site so

posting was also easy had a little

script that I could run on the server

and I just SSH in and SSH I trust for

authentication so there's no new attack

surface I have that anyway and this is a

great design it's secure it's simple

there's low risk it's also high

performance but you couldn't do a talk

about it at the CCC right so

it's too boring so I started to introduce

risk in my setup

*laughter

so the first idea was I had

written a small web server I could just

implement the blog in the web server

because you know it's my code anyway

but that has downsides if the the blog

is running in the web server then it can

access all the memory of the web server

in particular it can see the TLS private

key and that I don't want people to

extract right so it can't be a module

in the web server

and the the obvious solution is

it has to run in a different user ID on

on Linux I'm using Linux or but any

Unix or Windows would be the same

basically it runs in a different user ID

and then if you if you take over the

process of the blog because there's some

bug in it you couldn't access the TLS

key and while I did that the industry

was doing this

chatter

that's like the running gag of this

talk I show all kinds of interesting

things the industry did and then show

what I did in that time right so

next question

where's the content I could just have

files on disk like static HTML as before

but I think that's not professional enough

right so for a good CCC talk you

need to be more professional

also for a different

project I had just written an LDAP server

so I decided to reuse it and

while I did that the industry did this

I took this photo at the airport of

Jerusalem so this is an actual ad it's

not photoshopped right it's for

Northrop Grumman which is a

military contractor and it's about full

spectrum cyber across all domains

chatter

so why would I write my own LDAP server

mostly because it's small and

because I'm an auditor by trade I know

that if you want a chance to actually

audit the code it needs to be small

because that's a limited resource

the time you can spend on auditing code

right so Postgres is a common SQL

database slapped in the the open LDAP

implementation of the server and tinyldap

is mine and you see it's much slower

and much smaller

yeah so there was more to this

ad campaign I collected a few funny images

right so um if someone manages to

hack the blog CGI or whatever module

I use to to have connect the blog to the

web server they can open any file that

the blog can read right the UID can read

so I should probably do something

about that that was the next step and

the industry was starting to think about

vulnerability management

so there is a mechanism on Unix

on Linux I did a separate talk about that

on the last Congress

it's called seccomp and seccomp it's like

a firewall for sys calls so I can use

seccomp to block open the open sys which

is used to open files but if I have

to use open myself

then I can't block it right so what

to do about that for example my blog

calls local time which converts Unix's

time into the local time zone and for

that it opens a file containing the

description of the system time zone

and that calls open right so if

I just disabled the open system call from

my blog then it couldn't do the time

translation and this is actually

an old problem that also applies to set

ID programs and has has applied to them

for decades so what you can do is you

can reorganize your code so before you

block or before you drop privileges

generally speaking you do the open

calls in this in this example and

then you disable open and then you look

at the the data provided by the attacker

because if the attacker or any untrusted

source is trying to hack you it is via

data it gives you right it's

the environment is compromised so you look

at what kind of uh elements in the

environment are attacker supplied and

before you look at a single byte in them

you do all the dangerous stuff if you can

right so in this case I call local

time once before I drop the open sys call

and then my libc will cache the

time zone data and the next time I call it

after I have looked at the attacker

supplied code there is no need to call

open right so that's a major advantage

of Secom over similar Technologies like

SELinux where all the prohibitions

on sys calls are

applied to the whole process so there is

this is an example and you should make

use of it you should look at your

process and you can see if you have the

source code at least you can see which

parts do I need to do before I can drop

privileges and you move them up right so

that's what I did

this is actually a mockup from

the Estonian cyber security center

so this is real

okay so

next thought so let's

say someone hacks the blog module and

someone else uses the same module but

supplies a password right

this is a common problem in website

in websites there's some kind of login

something you get maybe a session token

or whatever and if someone manages to

take over the middleware

or like the server component

they can see all other connections too

if they are handled by the same

process right that's a major problem

and you can do something about it

so that's the good news here

and in my example it led to me using CGI

instead of fast CGI which is fast CGI

is a newer version of CGI

and the idea with fast CGI is that you

don't spawn a new process for every

request but you have like a Unix domain

socket or another socket to a fast CGI

process and that opens maybe a threat

per request or something but usually

in fast CGI you try to handle the

requests in the same process and then

you can use that process to cach data so

there's a perf advantage to using fast CGI

but for security reasons I don't

I don't use fast CGI so I can't do

caching right so that's a major downside

and you would expect the block to be

really really slow in the end so

first thing I need to use CGI instead of

fast CGI and secondly you could still

use debug APIs so if you use GDB or

another debugger to to look at another

process they use an API called ptrace

but that's a sys call so I can use seccomp

to disallow ptrace if I do those two

and the attacker takes over a blog process

all they can see is the data they supply

themselves right that's a major advantage

Okay so ENISA is actually an EU agency

which I find really disturbing

because they're burning lots of taxpayer

money anyway so let's assume the attacker

can hack my blog they can sill circumvent

any access control I do in the blog

so for example if I have an admin site

or some login site part of the webiste

and it's handled through the same program

and the access control is done in the blog

CGI and someone manages

to hack my blog CGI they could

just skip that so it's really hard

to do access restrictions that can be

circumvented if you do them in your own

code so the solution is not do it in

your own code I don't do any access

restriction in the blog I do it in the

LDAP server so if you connect to my blog

and supply a password then the blog

doesn't know if the password is

right or not there's an for example

there's an interface where you can add

new block entries or you can edit an old

one and for you need to supply

credentials but the block CGI doesn't know

if they are right or not it opens

the connections to the LDAP server with

that credential and then the LDAP server

says yes or no so since we removed

access to the ptraces calls and the

processes are isolated from each other

that means there is nothing to

circumvent here so if someone hacks my

blog the only advantage they get is

they can do the exact same stuff they

could do before basically they can just

talk to the LDAP server

okay so I'm starting to get into

James Bond territory here right

with the attacks they getting more

convoluted right so the industry started

doing threat intelligence feeds which

are useless don't spend money on those

okay so let's say the attacker hacked my

blog and then went to my tinyldap and now

is attacking tinyldap then they can

watch other logins because tinyldap

handles connections from other instances

of the blog too right so the same

problem we had before we just moved the

goal post a little and we need to

prevent this and the obvious solution

is to do the same thing we did

with the blog we have one process of

the LDAP server per request and then we

just allow ptrace right so now you

can't watch even if you get code execution

inside the LDAP server you can't watch

what passwords other people use

you can still see okay the industry

does some [ __ ] again you can still see

the password in the LDAP store right so

the LDAP server has to have a version of

the password to authenticate against and

the industry practice best practice is to

use salted hashes so the password is

not actually in the store

still if someone manages to attack

tinyldap through the blog they can

extract the hashes and try to crack them

but since I'm the only one adding users

I can control the password complexity so

good luck brute forcing that right

okay so this is actually a real problem

not for my blog specifically

but for other web services or services

that are reachable from the internet

what if an attacker doesn't want to steal

my data but it wants to encrypt it

so the ransomware what can you do

about that and my idea was to make

the data store read only so the

LDAP server has a data store that contains

all the blog entries and let's read only

to the add up process you can only read

from it and if you want to write to it

for example to add a new entry it gets

appended to a second file which I call the

journal so SQL databases have a similar

concept and they use it to roll back

transactions I can do the same thing

it's basically a log file

and that means all the differences from

the last time the store was created

the read only store all the differences

are sequentially in the log file

in the journal so that the performance

gets worse the bigger the journal gets

so every now and then I need to combine

the read only part and the journal

a new bigger read only part and

I do that manually

because tinyldap couldn't do it because

I didn't allow tinyldap to write the store

right that was part of the security here

and so with seccomp I can just disable

sys calls I can also install filters so I

can say open is allowed but only if you

use O_APPEND O_APPEND in the open sys

call on Unix means every right you do to

this descriptor is automatically

added to the end so I know if someone

manages to to access the tinyldap

binary and can write to my journal then

the only place the changes can show up

is at the end and that's actually a really

good thing to have because it means

if someone hacks me and adds junk to

my blog I can only remove at the end

and I'm good again compare that to a

usual SQL database if someone wrote

to the database you need to in to play

a backup uh in to restore backup because

they could have changed anything anywhere

right so but tinyldap doesn't even have

file system level permissions to change

anything in the store so I can

re-sleep soundly

yeah the industry spent money on

cyber security mesh architecture

right so the journal integration has

to be done by me manually out of band

so it's not something an automated process

does I do it manually

and when I'm doing it

because it's not that much data it's

like for a week or two I can just read it

again and see if something doesn't look

right this may not be available to all

other scenarios but you have to

realize if you have bigger data it's

usually not all the data that's big

most of it is usually static and read only

and then you have some logs that are

you know billing data that grows and grows

but usually there's part of the data and

this is the part with the you know

identifying information personally or

billing details that stuff is usually

small and mostly static and you could

use this strategy for that too

well yeah okay

so the attacker can still write garbage

to my blog that's still not good

right but since all they can do is append

to the journal I can use my text editor

open the journal and truncate at some

point and then I get all my data back

till the point where they start to [???]

the blog right this is still bad but

it's a very good position to be in

if there's an emergency because you

can basically investigate calmly first

you turn off right write access then you

delete the vandalism and the journal

and you know you haven't lost anything

because if you want to delete an entry

in the blog you could do that too but

that means at the end of the journal you

append a statement saying delete this

record and I can just remove that and I

get the record back right so there's no

way for someone vandalizing my blog to

damage any data that was in it before

all they can do is append junk at the end

and I can live with that right this is

this is should be the guiding thought

between any security you do

if someone hacks you will be in a very

stressful position the boss will be

behind you breathing down your neck are

we done yet? is it fixed? and you want to

have as little to do as possible at that

time you want to to move all the stress

to before you get hacked because then

you have more time

okay the industry did other things again

so what if the attacker doesn't write

garbage to the journal but writes some

exploit to the journal that the next

tinyldap up instance that reads the

journal gets compromised by it

that is a possibility and that would be

bad so agreed that there still a problem

but realize how preposterous the scenario

is so we are talking about an attacker

who found stable zero day in the blog

and then used that and another

stable zero day in tinyldap up to write

to the journal and then have the third

third zero day to compromise the journal

passing code so I mean

yes it is still a problem but we reduced

the risk significantly

and that is what

I'm trying to to tell you here it's not

it's not all or nothing it's good enough

if you can half the risk that's already

very important and you should do it

so as much as you can slice off the risk

the better the better off you will be

if something happens

right because the smaller the code is

that is still attackable the

more you can audit it and be sure it's

good you show it to your friends and

they can audit it too and you

need to save yourself that time because

it happens every now and then that I get

to get to see the whole code base and

the usual code base for commercial

products is like gigabytes of source code

nobody can read that like

I'm good I'm not that good

so this is a good place to be in

I think right so the industry was selling

DDOS mitigation sure whatever

so what happens if someone attacks

the web server that is still a big

problem and it's actually

it's a full damage right

that's the worst that can happen if

someone manages to attack the web server

they can see all traffic coming through

they can look inside TLS secured

connections and they can sniff all the

passwords so that's really bad

unfortunately there is not too much

you can do about that

you could do a separation

so this is something people have been

talking about for a while OpenSSL is

doing this they moved the dangerous crypto

stuff in a second process and use

sandboxing to lock down that process

that could be done but nobody has done

it for OpenSSL yet so OpenSSL doesn't

support that my web server

also supports embed TLS they don't

support that too so I I could spend time

on that and I've been actually

spending some time already but it's not

it's not ready yet but this would be a

good way to reduce the risk and you may

notice that the the tools I'm using to

reduce risks are actually just a handful

there's not it's not you know it's not

witchcraft I'm not inventing new

ways to look at things I'm doing the

same thing again I'm identifying the

part of the code that's dangerous and

then I think about how I can make that

part smaller maybe put it in a different

process lock it down so we need to do

the same thing with the web server

obviously but it's an ongoing process

yeah so again whatever why

haven't I done that yet uh so in my

web server you can it's a build time

decision if you want SSL support or not

and you can see the binary is

significantly bigger if you have SSL

and I'm showing you this because it means

the bulk of the attack surface is the SSL

code it's not my code so if I if I can

put the SSL code in a different process

they still need to see the private key

because that's what TLS needs

the private key otherwise it can't

do the crypto so the bug of the attack

surface would still have access to the

key I can still do it because there

might be bugs in my code and not the

SSL code but that's just 5% of the of

the overall attack surface so

I will probably do it at some point

but it's I don't expect miracles from it

bugs and open SSL will kill me

there's not much I can do about that

laughter

okay so I know what you're thinking

loud laughter

what about kernel bugs?

so I looked at a few of the recent

kernel bugs and it turns out that they

usually apply to sys calls that are rarely

used in regular programs and because

I'm blocking all the sys calls I don't

really need none of them apply to me

right and this is a this is a pattern

with Kernel bugs

there is a project called Sandstorm

that also uses ptrace and seccomp tracing

to reduce the sys call

surface and then puts regular services

into a sandbox for web services and

they evaded all kinds of of Kernel bugs

just because of that so this is

like a zero effort thing because

obviously if you have a list of sys calls

you'd use a white list and you

have a list of things you are

explicitly low and the rest is disabled

not the other way around right

so none of the usual Kernel bugs apply

to me um because of the the seccomp stuff

I already do so Kernel bugs aren't as big

of a problem as you might think at least

I still have them if I haven't patched

but you can't get to them via the blog

so I have a small confession to make

I'm a bit of a troll and that applies

to this project as well so I used the

worst programming language I used C right

so I'm trolling the security people

and then I'm trolling the Java people

who have been saying you should use

multi-threading for performance and not

have one process per request

so I'm doing actually two fork and exec

per request

I'm trolling the database people

I don't have any caching

I don't have connection pools

and the perf people too because I'm

still faster than most of the regular

solutions so there is no there's really

no downside if you if you architect your

software to use this kind of thing

it will be slower than other ways to do it

but most other software isn't as fast

anyway so there's enough headway that

you can use to do security instead of

performance you will still be faster

so let's recap the methodology I used

first I make a list of all the attacks

I can think of and this means

concrete attacks so what could happen

and what would what would

be the problem then right and then

I think for every item on the list

I consider how to prevent this

can I prevent this? what I need to do

and then I do it right so that's easy

it's like this the Feynman problem solving

algorithm in spirit and this

process is called threat modeling it's

it's like a it's dirty word because it

sounds like there's effort involved and

nobody wants to do it but it's really

it's easy it's just these these steps

you look at your software you

consider all the ways it could be attacked

and then you consider what you

could do to prevent the attack or in

some cases you can't prevent the attack

and then you say well that's a risk I have
live with

right so that's called threat modeling

you should try it's awesome

and you saw that I'm trying

to optimize something here I go for a

specific target in this case I want

as little code as possible

the more code there is the more bugs

there will be that's an a very old

insight from I think it was originally

in IBM study and they basically found

that the number of bugs in code is a

function of the lines of code in the code

so there's a little more to it but

basically it's true so and it's not just

any code I want to have less of

if the code is dangerous I particularly

want to have less of it and the the most

important category to to make smaller is

the code that enforces security

guarantees so like one security

guarantee would be you can't log in

if you don't have the right password right

so the code that checks that I want it to

be as small as possible one or two

lines of code if I can manage it and

then it's obvious if it if it's wrong or

not the more complex the code is the

less easy would it be to see if

it's correct or not and that's what you

want in the end you want to be sure the

code is correct so how far did I get

it's actually pretty amazing I think

you can write an LDAP server in 5000 lines

of code the blog is 3500 lines of code

plus the LDAP client library

plus zlib

but I'm only using zlib to compress not to

decompress so most attack scenarios

doesn't don't apply to to my usage of zlib

and the web server is also pretty slow

if you only look at the HTTP code

unfortunately it also contains the

SSL Library which is orders of magnitude

more than my code and that's how you

want it you want the biggest risk not to

be in the new code but in an old code

that someone else already audited if you

can manage it right so this is the

optimization strategy try to have as

little dangerous code as possible sounds

like a no-brainer but if you look at

modern software development you will

find out they do the exact opposite pull

in as many frameworks as as they can

so this strategy is called

TCB minimization you should try it and

I gave a talk about it already it's

actually pretty easy so

I told you what I did to the

to the blog to

diminish the danger that can be done

if someone manages to take it over and

this is actually part of the

TCB minimization process so the blog was a

high risk area and then I took away

privileges and removed excess checks and

in the end even if I give you remote

code execution in the blog process you

can't do anything you couldn't do before

right so it's no longer part of the TCB

the TCB is the part that enforces

security guarantees which the blog CGI

doesn't anymore

so that's what you want to do

you want to end up in the smallest TCB

you can possibly manage and every

step on the way is good so no step is

too small right if you can shave off

even a little routine do it

this is the minimization part of TCB

minimization right I could I was able to

remove the blog from the TCB tinyldap

still has a risk so you saw

the threat model if someone manages to

take over tinyldap they can read the

hashes and try to crack them that's

still bad but I can live with it right

if they vandalize the blog I can undo

the damage without going to the

date library so that's good

if you compare that to the industry

standard you will find that my approach

is much better usually in

the industry you see platform decisions

done by management not by the techies

and it's untroubled by expertise or

risk analysis and you get a

diffusion of responsibility because if

you even if you try to find out who's

responsible for anything you find

well it's that team over there but we

don't really know and then you find out

the team dissolved last week and it's

really horrible and brand new we have

AI tools which is also a diffusion of

responsibility

and then you get people

arguing well it's so bad it can't get

any worse let's go to the cloud where

obviously it gets worse

immediately so I prefer my way

I think in the end it's important to

realize that the the lack of security

you may have in your projects right now

is self-imposed there is no guy with a

shotgun behind you

threatening you can do it you just have

to start right so this is self-imposed

helplessness you can actually help

yourself you just have to start

right how did we get here this is

obviously not a good place to be

like all the software is crappy and

there's a few it's not just that people

are dumb there's a few reasons for that

so back in the day you used to have

bespoke applications that were written

for a specific purpose and they used the

waterfall model and you had the

requirements specification and it was

lots of bureaucracy and really horrible

but it also meant that you knew what

the application had be had to be able to

do so that means you can make sure

anything else is forbidden if you know

what the application needs to be able to

do you can make sure it doesn't do any

other stuff and that is security if you

think about it deny everything that the

application wasn't supposed to be doing

and then that's what an attacker would

do if they take over the machine right

so if you know beforehand what you're

trying to get to you can actually

implement privilege even architecturally

as I've shown you

now we have more of an Ikea model

you buy parts that are designed by

their own teams and the teams designing

the parts don't know what the final

product will look like right in in some

cases even you don't know what the final

product will look like but it's even

worse if you consider that the

team building the part you make your

software from doesn't know what it will

be used for so it has to be as generic

as possible right the more it can be

done with it the better and that's

the opposite of security right security

means understanding what you need to do

and then disallowing the rest and this

means be as generic as you can the parts

are optimized for genericity what's the

name genericism I don't know so they are

optimized to be as flexible as possible

and they are chosen by flexibility

the developer of the part usually

has no idea what it would used for

and that means you can't do least

privilege because you don't know what

the privilege will be that's least so

this is actually a big mess so if

you use parts programmed by other people

you will have to invest extra effort to

find out what kind of stuff you can make

it not do because it will definitely be

able to do more than you need and the

more you can clamp down the more

security you will have it's even

worse if you do agile development

because then by definition you don't

know what the end result will be so

if you don't know that you can't do

security lockdown

so another argument why we got

here is economics of scale so it used to

be that if you build some kind of device

that needs to do something like I don't

know microwave

then you you find parts and

you combine the parts and you solder

them together and then they solve the

problem but these days you don't

solder parts anymore you assemble from

pre-made parts and these are usually

programmable right so a little ARM chip

cost like a tenth of a cent so why use

a special part if you can use an ARM chip

and then program it but that means

you still need to use software that

actually solves the problem the hardware

is generic and that means the hardware

can be hacked and this is turning out to

be a problem right if you had a brake in

in 20 years know it braked right

but now it's programmable

and people haven't realized

how bad that is but it is bad right so

that's that will bite us in the

ass oops

so the response from the industry

has so far been the ostrich method

basically we install stuff that we know

is untrustworthy and so we

install other stuff on top of it that's

also untrustworthy and then we call it

telemetry or big data and to some risk

logging analysis in [???] or whatever

and in the end the attack surface

has mushroomed like a nuclear explosion

right so that's our fault

nobody has forced us to do this you

don't need to do this in your own

projects that's the hopeful message of

this talk in conclusion if you remember

nothing else from this talk remember

that threat modeling is a thing and you

should try it TCB minimization actually

helps least privilege is another facet

of the same thing and if you can use

append only data storage you should

consider it

- blockchain
- yeah not a blockchain

append only data storage

it's not blockchain

laughter

applause

- two more two more

- two more slides

- yeah two more slides

- sorry I'm imposter

- no problem

so the rule of thumb

should be if if the blog of some

unwashed hobbyist from the Internet is

more secure than your IT security then

you should improve your IT security

right that shouldn't happen

all right so that's all from my

talk I think we still have time for

questions do we? yes okay awesome okay

now you can put your hands together

applause

so if you want to ask a question

we have four microphones in the room

1 2 3 4 and I'm going to take a

question the first question from

the internet the internet is saying you

actually got hacked or can you elaborate

on what happened?

yes actually there was an

incident where someone was able to post

stuff to my blog and because I had append

only data storage I shrugged it off

basically so use append only data storage

it's it will save your ass at some point

the problem was a bug in my

access control lists I had used some

some access control list in my LDAP server

and I had a line in it that

I should have removed but I forgot to

remove it and that meant you could post

without having credentials but it

happened and it wasn't bad because my

architecture prevented damage as

people are leaving the room could you

leave very quietly thank you

microphone number one

- yeah is there a second alternative

for Windows and MacOS?

- secure alternative well so

basically you can do the principles

I showed in this talk you can do on

those two so usually you will not be

hacked because your MacOS or

Windows had a bug I that happens too but

the bigger problem is that the software

you wrote had a bug or that you the

software that you use had a bug so I'm

I'm trying to tell you Linux isn't

particularly more secure than Windows

it's just it's basically you can write

secure software and insecure software on

any operating system you should still

use Linux because it has advantages but

if you apply these techniques to

your software it will be secure on

MacOS and windows as well right so this

is not for for end users selecting the

software if you select software you have

to trust the vendor

there's no way around that but if

you write your own software then you can

reduce the risk to a point where you can

live with it and sleep soundly

- sure is there a a technical alternative

or similar similarity like seccomp for

Windows and MacOS so can you drop your

privileges after you have opened a file

for example

- so for MacOS I'm not sure but I know

that FreeBSD NetBSD and OpenBSD have an

equivalent thing I think MacOS has it too

but I'm not sure about that for Windows

there's are sandboxing methods you can

look at the Chrome source code for

example they have a Sandbox it's open

source you can use that to do this kind

of thing

- okay thanks

- so microphone number two except down

that's gone so I might go with

mic number three in that csae

sorry four four yes

- will your next talk be about writing

software secure software in Windows and

if no uh how much assets would you

request to compensate for all the pain?

- no

*laughter

it's not a question of money

laughter

- okay microphone one

- have you tried removing unnecessary

features from openSSL?

- yes actually I've I've done this

pretty early but it's still it's still

much bigger than my code

so for example openSSL has support for

UDP based TLS but there's a lot of

shared ciphers in there you can remove

ciphers you don't need and and that

helps a bit but it's still it's the

biggest part of the web server by far

- I think there was an internet question

was there no doesn't look like it

no yes no no yes okay

then microphone four

- as someone who is connected or

was connected to an industry which has

programming programmable brakes

what is your opinion about things like

like Misra?

- well well so there are standards

in the automotive industry for example

like Misra to make sure you write better

code and it's mostly compliance

so they give you rules like

you shouldn't use recursion in your code

for example and

the functions should would be this big

at most and this is more I mean it

will probably help a bit but it's much

better to to invest in in good

architecture but you may have noticed I

I've said I wrote the code in C and

I said nothing about what I did to make

sure it's it's good code so that's

that's a different dimension that's

orthogonal right

so follow those standards it will it

will make your code a bit better

probably but it won't solve all the

problems and I think personally you

should do both you should make sure or

try to make sure that there's as little

bugs as possible in your code there's

ways to do that I had a talk about that

too but after you do that you should

still have these kind of

architectural guide guard rails that

keep you on track even if someone

manages to take over the process

- so now I think there was an internet

question

- yes the internet is asking

how would it work to like scale this

truly impressive security architecture up

for more use cases and more like

larger theme or would the theme size and

the feature keep ruin it

- yes so

hello hello

- oh no

laughter

- well I'm sorry

applause

postroll music