Dear viewer, these subtitles were generated by a machine via the service Trint and therefore are (very) buggy. If you are capable, please help us to create good quality subtitles: https://c3subtitles.de/talk/881 Thanks!
Let's have a big hand for 11
spangle.
Also, OK, yes,
so as previously mentioned by terrorists,
are all of these created equally a
survey of Colonel Variabilities
Strafford? Who am I?
My name is Julie Fundamental.
I work for a company called Bioactive.
I did spend the last five years in
America, but I recently moved back to
Belgium a couple of weeks ago.
I am a computer expert and
I do fantastical review I
Brigstock for a profit.
I've been going to this U.S.
Congress since 1983 three.
It's been a while and I've spoken a
couple of times before.
I think this will be my seven or eight
time and let's see
how this goes.
Right. So my meditation is sort of split
into three, four ish pieces.
There's was an intro which will be the
next slide, and then there's a little bit
of data that I'll show and then
there's lack of data. So I want to test a
couple of things. And then once I've
tested that and get some results
to present my results and my conclusions.
Oh, right.
So what did you talk about, because you
couldn't vulnerability's it's a
comparison between the different
current bisdee flavors.
As for what I expect from the audience,
if you really expect
some basic Unix kernel
ish knowledge, not too deep, but some
would be nice people that I
think might appreciate the stock.
Or, you know, if you're a low level
security issues. Yes.
If you're you is the biggest geek and
then if you're Linux guy, you might like
this, too.
And then generally people are curious
about OS internal security,
I think might enjoy this presentation
or move on. I have to mention, you know,
some people that I call just
standing on the shoulders of giants
because you don't do this by yourself,
you build upon work by others.
So there's a number of people that have
done interesting musicale security
research over the last decade
and a half, maybe two decades.
Some of them might even be at a Congress.
So Silvio
Bunch others that did some really
interesting work.
So really, this just sort of started with
a post to a mailing list years and
years ago by Theodorus,
who, if you don't know who he is, is the
the main guy behind OpenBSD.
And I remember reading this 12 years ago,
and it's been sort of stuck in my head
since then.
And it's basically a quote from Theo
where he goes, you know, if the Linux
people actually cared about quality, you
know, as the obviously people do, they
wouldn't they would not have had as many
local root security holes as they had
last year, which is that year, which is
2005. And goes how many is it like
20 or so.
And so I think that was
you know, when you make that sort of, oh,
20 or so, I was like, really?
You know, is that true? Is what's the
data behind that? Can we look at some of
this?
And so I basically started looking at
the last almost 20
years of Linux kernel vulnerabilities and
what the numbers are.
And so I went to KVI details and they
basically keep a record of his stuff.
And it goes back to 1999.
And if you look at it, you know, the
first three or four years, it's, you
know, in the teens and then Sirnak,
2004, 2005, it sort of jumps up,
goes up into the hundreds.
And then this actually is this table is
from July of this year.
So 2070 numbers are correct.
And so in July
2017, it was three hundred
forty six abilities.
But as of today, because I checked
earlier, it was 434
political vulnerabilities.
And so as you see, these numbers
are kind of sort of growing
now.
CVT doesn't have the same numbers for
like BSD kernel issues.
They have like general abused the
numbers, but that that's all encompassing
to OS. And I wanted to specific
because the kernel numbers.
And so what I did is I sort of scraped
off freebees the MusicNet because the
numbers I sort of put them into a nice
little table.
And if you look at the
tables here for the BSD, you'll
see that the first couple of years are
kind of on par with Linux, but then the
links ones kind of explode
and the easy ones will sort of more
or less the same, either single digits
or low teens.
It doesn't really go over 17.
And that's that was only just a
year ago.
So if you look at these numbers, two
observation was pretty, pretty astute
observation.
In fact, 20 was a low estimate.
It turns out it was significantly more.
And so you see that numbers for the
analytics over the years
are not the same or not on the same
level.
And so what I asked is, are they on equal
footing? Like, obviously
there's a really large family
behind Luse. Colonel, if you look at the
BSD, you know, that's a small group of
developers, a small group of users that
are using these things and compiling
themselves and and so forth.
And so I wonder if that is
if that's the reason or if there is a
reason why the numbers aren't the same or
if it really is, as you said, if it's
good quality.
And obviously, one of the things I
consider as well, maybe it's too many
eyeballs thing and I know there's
Meribel thing is, you know,
very convoluted thing, but but there's
some truth to that.
And so I was wondering if there's some
truth to it in this case.
Well, and the only way to really do that
is to to test it,
to go and see what what
what the code is really like.
And sure enough, there's a guy that
did this 15
years ago, Sylvia,
and confrontation about this
2003, 14 years ago.
And basically they
did an audit of the kernel and
sort of drew some clues from that.
And one of the things that he said was he
said, well,
there really isn't much difference
between the colonel and the colonels
in terms of security auditing.
They're equally broken.
It's easy enough to find bugs in both of
them and the same kind of bugs.
Now, that was 15 years ago.
Have things changed since then?
The other thing I said was that he only
spent a couple of days and then three
months on Linux.
And so if you spend longer
on the BSD, would that have
we've got more bugs or would you sort of
hit a limit? Right.
And then third one is if you look at his
presentation and this is 15 years ago,
he mostly looked for a mostly
found Trivellato flows
and Infl and nothing
else. And so the only ahead is what if
I expand the number of bugs that look for
what if you will, look for, you know,
race conditions and things like that.
And so the data is interesting, but it's
kind of a little bit outdated and a
bit too limited at the time.
I think it was perfect for
today's purposes. It's not quite good
enough.
And so the only way to really figure out
if those numbers line up or don't line
up what the reason is, is I have to dig
in myself.
And so I spent April, May, June
and July of this year looking at
the code.
I don't know exactly how much time I
spend on each one of them, but I would
say they're more or less equal.
And so basically what I did is I asked
myself if I was going to look for bugs,
where would the bugs be?
Where do I think they would make
mistakes?
And so I made a list of sort of attack
surfaces that I wanted to go look at.
And none of these are, I think, overly
surprising, obviously, to the
common stuff is like, yeah, obviously,
I'm going to take a look at some of these
calls and I'll take a look at the DSP
stack and then, yeah, I'll take
a look at some drivers and I'll look at
the complete code and a trap handlers in
the filesystems and, you know, other
networking stuff.
And I essentially spend three months
looking at that.
And so when I want to do is I want to
jump over some of the things that in each
of those areas that I found
and as were discussed at
briefly and I have a couple of demos
in here as well.
And then once I've run through that, I'll
sort of run you through my results and my
conclusions.
So, yeah, so let's dove in the system,
cause obviously this is
a attack surface.
I don't think it should be anybody that,
you know, if you're looking for Syria,
because the first thing you want to do is
look at system calls, because that's the
thing where user talks, the
kernel.
And the first thing that that you can see
or can observe is that
among the three big BSD,
there's a difference in the amount of
system calls that are implemented.
Right. VBAC has well over five hundred
net boards, almost five hundred, and
obviously has, you know, about 300 and
change.
So right then and there, there's a
clear difference between attack surface
between three of them.
Right.
But but even sort of regardless of tax,
it was my assumption was, given
that these are so obvious and so well
tested, they're less likely
to contain security bugs.
And so, you know, I go along and I
start looking and I start looking at
system calls. I start playing with them.
And sure enough, this is not system
call and it's the census log.
And you get to give you a number of
bytes. And basically that
gets passed on eventually to Malac.
And I think about
ancient code.
Nobody has this.
If you pass it on to Mallach, you
get an institutional panic.
And sure enough, that's what happens if
you do just log in and give it a real
value.
The thing blows up
and actually have a demo of this.
I don't know how this is going to work on
the screens. Let's see if I can get this
to work.
And.
Yeah, on.
Uh.
Yeah, OK.
Crap, it's not marrying on my screen, so
it's kind of annoying to see this.
Hold on.
OK.
So there's obviously and this is my
example and sure enough, boom,
that caused the kernel panic.
OK,
so that's the Similac and that's the
kernel panic. There you go.
And so what's happening is basically
uses this the this log says call
and you pass it on about value and cause
panic and malac.
This is not me. This is one
I haven't looked at the little ones.
I know it's been fixed since, but it's
been there will be six points here.
So it's a fairly recent
bug.
So and here's the second example.
This is a system call on
previously called Kaldi Stat, which
basically gives you statistics about
kernel drivers.
And this thing basically creates as
this stat bar from the stack
fills it out and then sends it back to
user land, but it doesn't fill out
everything. And so you get initialize
bytes in there.
This has been found.
And if you use the 11 but
it's been in there for over
just over a decade,
doesn't fully initialize a structure and
basically sits back to Ireland.
And then I
let me see if I can show you the name of
this to.
This is KDDI leak and then.
And then basically all these bites are on
his memory that's basically flashing over
the screen.
So that's that's basically bag number
two, where you get to basically lead a
whole bunch of
initialized Crameri.
So basically my previous assumption was
wrong, right? When I said that,
I assumed that because the system calls
so well tested that it's like less
like bugs in them. Well, that turns out
to be entirely wrong.
You can find bugs in the system causing
the BSD within,
you know, fairly quickly, fairly easily.
Bugs that aren't too esoteric
or too too weird, fairly straight,
straightforward bugs, especially
in newly assistant calls.
But even the older stuff, as you
can see, a 10 year old system called in
previously still had a trivial
info leak. So those things do occur.
Right, so now that we know there are bugs
in system calls and they're fairly
defined, let's move on to Giuseppe Stack.
This one again. My assumption is it's
very well tested and less likely to have
bugs because we all know the
risk has been around for ages since
the 80s at least, and it's incredibly
well tested and highly
unlikely to find bugs in there.
And for those who know what this is, all
things like before and every 600
ICMP, IP, SEC,
Internet and things like that,
it's been around forever.
And so my assumption is unlikely
to have bugs in there.
So I start looking around and I found
something which is restack, which
basically
passes, parses
packets. And then it's a little
bit convoluted, I guess.
But basically the idea is that you take
it back and you start parsing it.
And then if it contains
the exact right tag and
the right error message, basically it
actually does this thing.
We're so into BSD,
the way these Biersack works, they have
this thing called EMBOSS and it's
basically it's for management around data
that you send in and out.
And so there's a whole bunch of APIs
around it. Right. And the idea is that if
you don't use the API correctly, things
go really wrong.
And so in this case, you see this thing
called and pull down.
And basically, if Pull-down fails,
it will freedom. But you passed it.
And in this case, you'll see over of my
fields there's error code where basically
to do what you done and then in done,
they're basically free, except if
the thing failed, DMSO retreat.
So this is even though the code to live
the read, it's a relatively easy
bug you trigger it affects
is the six point one.
But it has been there since 2004, so it's
been around for over a decade.
It turns out when I was looking at this
and I found a bug, I checked Stuxnet
because it turns out that these guys have
the same bug, but they fixed it,
but they never release any kind of
advisory for it.
And so clearly, I had never told you guys
about it.
And so they fixed
it means you guys won't fix it.
But I emailed him about it.
And so this bug was, you know,
look for this work was relatively
easy to find. And so, again, my previous
assumption was wrong.
Bugs and Giuseppe's attack do occur
with some frequency in particular
new record. But also, it turns out
and buffs are hard, very
complicated, and it's error prone.
The APIs aren't overly consistent,
about half of them sort of when they fail
the freedom of the other half.
When they fail, they don't forget about
things like that where it turns out
if you have to use them barfs, it's
not quite that easy.
You have to know what you're doing.
And there's a number of cases that I
found where that doesn't happen
and all sort of circle back to
AmBev misuse later
on when I talk about the wi fi stack.
But anyway, it turns out
Habsburgs,
right? So moving on, I
looked at some of the drivers, obviously,
because it turns out that there
is a whole lot of drivers among the uses
for all sorts of things, really.
And given that Unix testing where
everything is a file, the way you find
your drivers, you go to Dev and then
Endeavor will have some kind of name and
then you can do file you open them and
then you can file operations on that
thing. Right. So open read right.
Close and so forth.
But obviously I octal is the
one that you want to look at because
that's generally where most of the
interesting attack surface will be.
So this is this is the
dev krypto on that BSD,
which has this thing where you
basically have this very,
very trivial indro flow and then here
you get memory corruption.
And it's that this is just one snippet.
But if you look at the actual driver,
it's like an octal command
bug. I have to command Sanberg Command
Sanberg seven or eight times the same
trivial 04 shows up
and then sure enough, you trigger it.
So the one I showed was this desire,
but there are seven or eight others.
And then again, let me see
if I can.
If I can demo this.
Yeah, I think so running.
No, I mean, it'll be commemorated in
Philly in a time it won't actually crash
because the memories guaranteed to be
there, it's just an unrealized.
So this is an episode
and then quickdraw flow and then
boom, sure, at the moment, Hatice, you
get memory corruption when I was.
Yeah, so this is a classic control flow
leading to memory corruption. This is
definitely explainable.
And then this is a similar driver
on the street because this is a driver
called Kasim, which basically
gives you access.
It shows you, Colonel, symbols for
freebasing.
It's an official driver you can load.
And they have this interesting thing
where they do they implement
that car. When they do open, they
basically in the to the
driver of driver
files, specific data,
they basically take a copy of a pointer
that's very specific to your process.
And then when you do unmap, they find
that pointer and they basically use it.
There is an interesting issue here
with expired pointers where if you if
I open the device and then
I pass that file scripter along to a
different process and I kill the original
process and then that process
doesn't EMAP, it's basically using
that original pointer to the actual
process, but the original process is
dead. So you have this wild pointed.
It's being used.
This is essentially an expired pointer.
And this is very problematic, it turns
out, because you basically
you're using a weapon I can point
anywhere to read and write to.
And and I wanted to I can't
live because my export kind of sucks.
And it takes three or four days to
actually hit the bug.
I could probably optimize it.
I just haven't.
And so you have to do with a screenshot.
But this is essentially what happens if
you hit the bug and then sure enough,
yeah. If you look at this here, up to
nine days,
one hour. So it took nine days to
actually hit the bug, but I did hit
it.
So that's it for the driver stuff,
and there are many, many, many more
driver examples, but I figure two's
enough so compact
coexisting in the BSD where basically
they allow the US to sort of
emulate a different OS.
So if you have a binary that you can file
for Linux and you're running on
previously and you turn on the previously
compatibility layer and
you make sure that you have the right
libraries and stuff installed, then your
Linux binary will run perfectly or more
or less perfectly on
on your free Musea or Net BSD.
And so you have these kind of the FDA and
the FDA waivers for different operating
systems.
And so especially NEPI, as he has quite
a few of them
free because he has less of them and
Otomi as he pretty much killed most of
them.
But it's essentially their free to
different OS or older version of us.
Or you know, you have 64 bit
and you're supporting 32 bit for to do
all that stuff goes through combat layer
and basically that's basically
has to eliminate a whole bunch of system
costs.
And when you I found a really
nice quote by Tío about combat layers
where it says, well, you know, the people
that rely on the that layers don't care
enough to maintain it. And the people who
work on Moelis don't care about combat
layers because they don't use them.
And the cultures are aligned in the same
direction and basically
says compactly is rot very quickly
and then it's absolutely true.
And so an example of this is
this is SVR for Campath
code on Nepsa.
That's your is ancient.
Nobody nobody's use that in probably 20
years, but it's there and they
support it. And this is the thing called
streams, which is
it's kind of like sockets, but
not and streams have been dead
for a long time.
But that vessel supports it in a server
for combat.
And they have this thing where basically
the
dysfunction that
gets called, which is
a pointer and basically
the content of which
is defined by Juland.
And what they do is they basically grab
the value off of it, uses an offset
and then basically sort of dereference
the thing and read data out of it.
So this is basically arbitrary, you know,
read anything from memory out of
boundary's
that obviously can cause
a kernel crash or potentially in Fleak.
But the really interesting thing about
this code is if you throw all the way up
and you look at the comments, it says,
yes, this is gross.
So they know their code sucks.
This code has been around since 1996,
so it's been there for 20 years.
I mean, there may be people in the room.
They're younger than this bug.
But, yeah, this is this really crappy
code. And this is what you meant when you
said rats really quickly.
They were 21 years ago.
They never look back. It's there probably
hasn't been used in 1996 to.
And then so when I told him about it and
they fixed it, the long message basically
said, well, we fixed a multitude of
holes in our stream code.
And then they said we should have never
enabled us by default.
And then it's a minefield.
And so what I do is
when I fix this thing, they also change
their kernel config and it turn to shit
off by default, which,
you know.
Right, so next year, that or
trap handlers and think about trap
handlers is that trap handlers
basically do this thing where they handle
any kind of sort of exception or false,
which can be division by zero or a system
call or break point or envelopment access
or a very, very long list of things.
And this is essentially mostly this is
sort of hardware sort of coming to us
and saying, hey, this kind of fall
happened and you have to deal with it.
Some can be triggered by your some can
only be triggered by HeartWare, something
only be triggered by kernel.
The code to handle this and this is
usually incredibly, incredibly nasty.
It's terrifying to just read this code.
I can't imagine writing it.
And it's very specific.
Like the intel ones are different from
the yard, which is very different from
MIPS and so on. And even among
the intel
earlier to leaders, there's many changes
in between.
And so I didn't really feel
like orange is code because
I like my sanity.
And so I was like, OK, how about I just
fuzz it well and then it comes out.
OK, well how do you fuzz exceptions?
And I'm like, well I don't really
know how to for specific exceptions,
but what if I just execute random
instructions? Surely
those things will hit some kind of
exception.
And when I say random structures, I mean
like super random, like I don't even know
what the structures are. Basically what I
do is I read from the random
and then I and that page I make
executable Falkoff a process
basically put into it.
Let the process do its thing.
It will die usually
after section two or three.
The thing is dead, but you just keep
doing that and loop in loop and loop
and it generates all sorts of weird
traps that the kernel now has to handle.
And sure enough, if you do this on that
freebie is the you you hit a couple of
bugs. There's a Z
in there, even though I wasn't using then
there's some send signal bug.
There's all sorts of weird things that
happen. So this is one of them.
This is not a one of them.
And I could but
I don't know. The thing is, because it's
so random, you never know when when it
hits.
But essentially this is all the code
it takes. I mean, I have more advanced
versions of this, but this is really all
it takes to cause it.
So if you write something like this and
you run it on the BSD and
it will hit kernel bugs.
Anyway, that's a wrap and happy with
that, because I don't want to talk
about Rafaela's,
so, yeah, the next thing I was looking at
are
filesystems.
And so the attacks festoons.
Obviously, the easy part of the
attack surface is sort of the,
oh, you know, you mount the USB
stick or whatever, and then it has to
pass the filesystem. And that's true, I
believe, in my view that's attack
surface. But it turns out in recent
years there's significantly new
attack servers to filesystems.
And this comes in the form of Few's.
I don't know if you guys know what Fuze
is essentially usually
on file systems.
And so what that means is all of a
sudden, all these Unix
layers that have been around for many,
many years that in previous years only
took data from trusted
drivers and kernel data structures
were, you know, more
or less trusted, like the data in there
you figured was more or less accurate
because it was given to you by kernel.
All of a sudden all that data is handed
to the fifth layer by a useless process
and the assumption that the data in there
is trusted is no longer valid.
And so if you start looking at the future
implications for the BSD, the first thing
I thought was like, oh well, it's Fuze.
It's pretty sure it's what inflation.
And they all do the same thing.
That isn't true.
Turns out all three Busey's,
they're entirely different future
implications.
There is no cochaired read, all three of
them totally different.
My understanding is my view of from
looking at the code is that the deposition
is the most complete in terms of
features.
The freebees you one seems to be the one
where the arguments are the most
controlled and constraint in terms
of the amount of validation being done.
And then the ones basically the
has the most minimal amount of
data or features implemented compared to
the other two.
If you look at Fuze, it actually
supported. But all three
of these do not when they are equal, but
they implement pretty much any other
facet of operation read.
Right, to get attributes.
It attributes that type of stuff.
And so, for example, this
is this is the OMB as the
get get Getsy
system gets called by to call
and basically they'll do this thing where
they go to the VFW later and say get
attribute.
And then they fill out this
feature structure
and they assume everything in the VAT
structure is more or less sane
because it came from a kernel driver.
But given that Use Fuze all
data in VA is no longer trusted, it
should be considered tainted and you
should validate it.
And of course, they don't.
And so you take this massive linked
value from it. And the fact that the
mallock and as I mentioned before,
don't miss email when it sees a very
large value kernel panic.
So this right here was a bug.
And then if you look a little bit further
gets W.D.,
they'll do another call to vacillator.
Just stop right there.
And basically they get
to the studio structure
back.
And previously, when you need that kind
of return again, it was it
was Farson data, but it was headed
back from I think some
driver saw the structure was more
or less trusted.
And in this case, it's really just a
Bufferin in length.
And so the content, because it now comes
from usually the process is no longer
trusted. And so if you look at what it
starts parsing the name length
of an entry in a directory, it sort of
just assumes that it's more or less
valid.
And then it uses that for a move
and that can cause another boundary.
So basically, the problem with Fuze and I
would imagine you see this in Linux, too,
but I haven't looked yet.
Is that your view that you have?
If you if you do if you like Fuze,
you have to modify your vacillator
because you're vacillator has
all these assumptions where it assumes
the data gets from your file system is
valid and it's no longer true.
So that was a sample of adoption's.
But you got to be as easy as asimilar
bugs.
Just this particular bug.
The bug was there since 2006, but I
think Fuze is not quite at all.
And so this has only recently been
a real issue.
And then obviously, if you look at the
actual fast handler, when you give it a
a blob of data that amounts.
So this is the X2 parser
for privacy.
And this is a brief, very brief look at
this. I did not do an exhaustive search,
but I was like, you know, grep for this
thing called berried.
And I'm like, oh, well, you're looking
for some kind of string and the string
isn't there. You just panic.
Well, that's pretty bad.
Basically, I can give you a
malicious explanation and then this thing
will cause a panic.
So obviously the
the Faslane partners in
the BSD are not what they should be.
I suspect if you throw a simple fast and
further against these things, it'll blow
up in all sorts of bizarre and weird
ways.
I just spent five minutes on this nose.
Like, this is very, very broken
because clearly you're assuming falt
filesystems.
Again, this this book's been there for
seven or eight years or so, but I suspect
when you start hammering on the Folsom's,
you'll find more bugs.
Right.
So, yeah, networking beyond these VIP
stack and I sort
of mentioned Wi-Fi,
but I really only have Wi-Fi
in my slides.
I kind of threw out because I didn't get
to it.
But when you look at your Wi-Fi attack
surface, there are
sort of two things you have to
look at. Right? One is the stack itself
and then one are to the actual Wi-Fi
drivers. Right.
And ideally, you would have this thing
where you have only one stack and then
all the drivers are according to it,
which ought to be as these did.
Analytics has this too.
But enormities of Wi-Fi, sort of every
driver came in so full stack.
But luckily we sort of passed out and
there's only there's one stack for four
older drivers.
So, yeah, the stack is sort of
it looks like stack, I mean,
it's obviously partially different
protocols, but it's all in buffs.
It's in and out.
It's stuff that gets passed
back and forth.
The main input functions is
Tripoli. Eight or two underscore input.
And once you start reading that, you sort
of find the entire eight or two, 11
passing stack.
And that function is called from all
the Wi-Fi drivers.
And so, sure enough, we start reading
that eventually you find this function
called Tripoli eight or two
eleven underscore equal and square key,
underscore input.
And it's basically deals with people
keys.
And it turns out if you look at the
structure for this thing, it actually has
two different lengths.
One is length and one is payload length.
And it's this this particular function
does validate length and Paillot lengths,
but then it has to do this thing called
an ember pull up to that is to say
that's to actually pull up enough
continuous buffers to make sure there's
that much length. And it does this for
the payload length, but not for the
actual the other Lingfield.
And so it turns out that
the actual airfields used to actually
read beyond the thing to
read the buffer.
And so because the pull up isn't done
for the length, but for the payload
length instead, if your length is bigger
than your payload length, then you can
end up having outer boundaries and
this can be triggered by remote
wi fi frames.
So, again, this goes back to AmBev
mishandling, as I said previously, in
stacked part and buffs
or heart.
This wasn't six
point one when I was ordered, it turns
out the bug has been around for about
nine years.
The drivers, the like for drivers,
this is the interesting part.
The Wi-Fi drivers are either so worried
because these are either PCI or USB.
Right species.
You know, when you put the card in, the
sky's the limit access, but USB is
different, USB packet based.
Right. And so it comes out the question
where it's like, do you trust
your Wi-Fi radio?
Right. What if somebody compromised the
Wi-Fi radio and then from there on
tries to own your OS?
And so for the PCI one, I was like, OK,
well, if your PCI
OK, it's kind of game over because they
can do TMY and that's I mean,
that's no longer true when you use things
like Mumu.
But let's just assume that if it's PCI
and you handle it wrong, OK, fine.
But when it comes down to the USB
drive, three to two or 11 duty
protocol is essentially packet based.
And so your host
really should be able to, you know, pass
the packets correctly and not blow up.
If you get bizarre USB packets
from your Wi-Fi radio,
it turns out they're currently not really
doing that.
And this leads to very, very trivial
smashers.
And I have I wanted to have one example,
but I really give you five examples of,
like, the same thing.
So this is one driver where they go like,
OK, here's a Lynnfield that can be
up to a page long and then,
OK, we'll go do we'll create a number
of cluster, which can be 20 bytes long,
and then we'll just do a copy with that
length into that cluster without ever
felt any of that length is bigger than a
cluster.
And obviously that means you get trivial
memory corruption.
And then this is a different Wi-Fi driver
and they say, OK, let's grab this linked
field out of the out of the
USB packet and then we'll basically
use that and copy into
an app that can be up to to
two thousand bytes. And again, very
similar encryption book.
And then this is not a driver and it's
very similar thing with a computer
linked and then it's another driver,
very similar thing where you take a link.
They do an IBM copy and it causes an
admin heap corruption bug.
And there's more of these.
But those are the ones that were very
trivial.
So this is basically wide open attack
surface across all of these,
across various different
I mean, there's an ATM, there's a real
taxers, a whole bunch of these
like drivers
did.
This code is very trusting
of the USB packets. It just assumes
everything is done right.
I think when when these crimes were
committed, nobody thought about the
attack surface on this one.
And then so that's more or less it
for the for to attack surface.
I had
there's a few more things I looked at and
I kind of want to talk about,
like I didn't really have much detail
about it, but two things that I showed up
that I sort of had that that
that seemed like there were many bugs
in there. So one is
there appear to be a certain
amount of easily detectable
giraffe's in the BSD.
I spent some time looking at it in
FreeBSD.
I did a very quick rap on
the on that because I
suspect there's a similar amount
on that because we're basically.
So the way you call mallock on the BSD
basically is you pass the flag and
the flag is either basically says
no weight or
default behaviors.
That default behavior is that the mail
always waits. And when it succeeds, when
it returns, it always succeeds.
It never fails.
And there's a way you can pass the flag,
which is no way or can fail.
And what that means is if it can't
fulfill the requests within a certain
amount of time, it returns and feels the
request. Right.
And so what you can do is you basically
graffitis flags and you see any time
where there's Amalek done and return
values and checked and you get a new
address.
And the reason these things show up is
because by default,
the pattern is Malacañang for value.
And you would think, OK, well, that's an
easy pattern. And no, if
you write in Kirkcaldy, you'll never make
that kind of mistake except because the
general way calls where
it could never fail.
And so there's almost never Amalek servo
check, except you have to do this
when you're doing no way to Cadfael.
And it turns out there is.
Thank you.
Turns out there are quite a few cases
where when you do mellark,
no way to fail.
People don't return value.
And so I think these are pretty
graspable. The second elsewise
and I don't know why people haven't done
this yet, but there's quite
a I brief.
So when are you getting at like
15 or 20?
I can't remember how long the list was on
on a frequency.
And I think that was interesting to see
that the videos
have, you know, just direct.
Interesting stuff in Colonel
Right track ranging management
infrastructure for those who don't know,
these are basically the graphics drivers
that are in Colonel and so when X1
runs, it sort of talks to these graphics
drivers and colonel and that the whole
thing around it is called DRAM or dry.
And so this sort of because this sort of
came from the open desktop people and it
was initially developed separate.
And then a couple of years ago it was
moved into the Linux kernel.
And then what to be as easy as they kind
of forked it. But it's essentially more
or less the same code base.
And so to be but the PC guys kind of have
to have it. Otherwise it doesn't really
do much anymore these days.
And so it's interesting when you
see the struggles they have with this.
And if you look at the the the main
oatmeal's, the developer was responsible
for maintaining the AMD urine in
Otomi as the he said, well he goes
all this loose code that we are
importing, it's not going to be reviewed
by any means.
The kernel developers, because they
refuse to read any code that is not
conform to the basic standard.
And so you have all of these rigorous
review standard practices and OBC
except the zero zero stuff,
they will not touch it.
And so all the bad antecedent Linux
kernel, all that stuff is pretty
much between abusing free PC as well.
OK, so that was sort of it for
running through
the sort of the types of bugs I was
looking for and the things I found.
I mean, I could have spent I could have
done two or three hours running through a
bunch of bugs, but it'd get pretty
boring.
So so what was my result?
After I was done about three
months, I about 115
bugs in total,
30 bugs in previously, about twenty five
bugs in obesity.
And the lion's share was in jeopardy.
So about 60 or so.
And that
it was a very wide spectrum
of bugs, pretty much everything under the
sun that you can expect.
Right. A straight up SAC smashers,
race conditions, expired pointers,
double freeze, integer issues
on the or flaws in as bugs logic
bugs. I had a typo somewhere where the
wrong variable was used, but it turns out
that one existed two.
And then you get these weird things where
the wrong thing was happening on the
wrong structure because there was a typo
division by zero.
I had some logic books in there.
I mean, you can imagine it's in there.
It turns out it's not written by gods
and they to make mistakes and they make
plenty mistakes, actually.
So I found basically
bugs among all three of these
among all of the attacks, as I mentioned,
and within that entire spectrum.
But it is interesting, once I sort of got
a grasp for all three of them and what
was where and how it was done,
it's interesting that I think
I can make some observations about the
quality and just looking
at the bugs, like just a numbers of the
bugs. Right. You can you can you can see
the same thing. Right.
And so there's sort of a I
think obviously when it comes to code,
quality in their kernel is
the clear winner.
Right. And it comes
the quote that I had from
the originally where it says, oh, it's
code quality.
That's part of it.
I think it's it
became obvious to me that it's code
quality, but also a tax rate reduction.
It's a combination of those two that
seems to be a winning formula.
And it won't be easy. There is enormous
tax reduction. If you compare it with
the other BSD, there are many things they
do not have.
They don't have a little kernel modules.
They have relatively few devices.
They have virtually no combat code.
They remove the combat code.
A couple of years ago, they removed her
entire Bluetooth stack because they
thought the code sucked and they just
deleted it. So no Bluetooth support.
Obviously, they have significantly
less system calls. They have more than
two hundred thousand calls, less than
FreeBSD, and
they cut support for a whole bunch of old
architectures. Right.
And that in combination with code
quality,
I think is a winning formula.
The quality is interesting because it
really does show if you look at the code,
right, the trivial low hanging fruit
stuff is almost
entirely gone.
The integer overflows, sinus
bugs are virtually
gone.
Like the Wi-Fi driver stuff is something
where I still found it because it was a
taxi service they never thought about.
But I don't think that they know is
attack surface.
It's highly likely financial flows or
bugs simply because they know about
them. They
they inform their developers
about what that looks like.
And they have this every
every commit gets reviewed
by at least one or two people.
And these people know exactly what his
patterns look like. And it turns out when
you have a process like that in
flows simply don't occur in attack
surface.
The other thing is that they had fewer
leaks than the other abuses
in terms of the clear loser.
Yeah, that was what I
think you can see that in these bugs.
I mean, they have. The other two combined
is less so, yeah, it was
it wasn't that busy, tons of legacy code,
tons of combat code.
Yeah, it turns out when you have Lexing
evacuate when you have 96 and you
haven't looked at it since.
Yeah. You're going to have bugs.
They have these ISO protocols there,
which I don't know if anybody actually
uses those these days.
It's really ancient code from the 80s,
which is written by IBM.
And then it was important that bisdee and
it's been there ever since and nobody
knows what it does, but it's there
and a whole bunch of this really, really
old code.
The other thing is that there seems to be
less consistent with
security called security code quality
compared to the other BSD,
unlike obviously they have tons and tons
and tons of issues and
Satanas bugs there.
I mean, just I want to show that, you
know, of those right there.
So so there is definitely that sort of
code quality difference.
And I don't mean that as a dis.
I mean, I understand that.
I mean, building, maintaining, improving
OS is really, really hard.
And if you think it's easy, you know, try
it. So I understand that it's very hard
to analyze, but there is a clear
difference between if you if you look at
one or the other, you can see there's
there's a difference in code quality
when you look at the attack surface
and then FreeBSD is somewhere
in between. Really,
it's hard to place it, but it's
it's not it's not the code quality isn't
as bad as Nepsa,
but it's not as good as open BSD.
So, OK, so obviously when I found these
bugs, I, I talked
to the teams that are sending e-mails and
I said, hey, here's a list of bugs.
Have you guys should probably go and find
this, fix this.
So e-mail your music, guys.
And you know, T.O. gets back to me and
about a week or so later and first thing
he does, he says, Oh, I'm sorry, it took
me a week. Get back to you.
I was on vacation.
And he says all these bugs look good, is
definitely problematic.
We should go and fix these things.
And then he says emails back and says
the next two or three days you should see
fixes sort of
coming in our CVS.
And sure enough.
Twenty five bucks. I reported
less than a week and they fixed it,
right?
Yeah, I think that's good.
And then a couple of weeks later, the
abusive guys basically made
individual patches and advisories and
said, OK, if you have if you haven't,
please don't be easy and you want to fix
these bugs, here's the patches.
Here's how to do it.
So I think that was great.
I think that's perfect. I think that's
the way it's supposed to be. Right.
You know, within a week, responds a few
days later or fixes the
fixed in place and then like a week or
two after that, all the patches are
publicly available.
There's advisories.
This is exactly the way
a security process should work.
It means you guys have done everything
right as far as I'm concerned.
So Freebie is the hardcore.
Well, it sort of started off similarly
where I got a response within a couple of
days, maybe a week, and I got a
bug back from these guys and said, OK,
well, we've seen all your bugs and we
filed the internal bug database.
And this was July 14th.
And sure enough, this is from the email
and have blacked out.
What hasn't been fixed yet or what.
I'm not quite sure of just three negative
and fixed rate.
So since that
email, not all
that much has happened. Right.
It's five months later,
two devices have been released.
And so obviously those two books have
been fixed. And then there's the third
one is Akie Incap.
I saw
I saw civs commit for that.
So I know that was fixed.
All the others I it's
up in the air. I don't think they're
fixed. I, I quickly checked CBS
right before I came here.
They look like they're still in limbo
somewhere.
So, you know, this is this
is where freebees the
NEPI is the first of all
when I e-mailed news bugs,
a list of sixty bugs to
shit got fixed overnight.
Seriously. Seriously.
This is obviously unbelievably
impressive, right?
I don't know how you can do that, but
clearly there were two developers that
were like, oh, let's fix this shit, let's
fix it right now.
So that was that was very impressive.
And then, as I mentioned, it also turned
off your last year for
Campath subsystem.
And if you look at the commitments, you
know, the email they sent me said
basically it disappeared in the messages
that we've just able to ask for by
default, something that should have been
done a long time ago.
So that isn't really impressive.
That was late July 2013,
five months ago.
Let me let me tell you what's happened
since absolutely
nothing bugs are fixed and CBS,
there are no patches for current.
There are no advisories.
What this effectively means is if you're
running that busy today
or 60 bugs are there and you can
go us and
see exactly what the bug is.
So I wish they had followed up with some
patches and advisories.
So that kind of it started off really,
really, really well. And then they kind
of dropped the ball.
OK, so coming back to my sort of
the earlier where I began
my presentation, the sort of New York,
are things on equal footing?
Well, I think bugs are still
very to defined in the physical's,
probably about as easy as Colonel,
even open, because he wasn't I mean,
there were certain things I didn't see,
obviously, but it wasn't like it was hard
to find bugs in there.
There's certainly very little quality
between the two or
three of them and depends on the agent
who wrote it and under what
circumstances.
The most consistent set of quality I
found by far was open because again,
this comes back to their rigorous review
process, right?
Every every check in gets
reviewed.
I think that's a process that simply just
works.
With the exception to the idea of
the ABC. Guys have the same shitty code
everybody else is, and a fairly busy
developers refused to touch it.
Another thing I have that I
think should happen because I found a
couple of bugs where I was like, OK, this
bugs me, but it was fixing it.
BSD or and the other thing around where
I'm like, oh, this is Nepsa, but
you obviously got to fix it 15 years
ago. Right? So those things from time to
time did happen with some frequency.
And so ideally,
I think to maintain it, to be as we
should talk more among each other.
Now, understand, that's easier said than
done, because in the last two, three or
four years, they have diverged and
there's different philosophies and ideas
on where the music is supposed to go.
And obviously, you know, there's big egos
involved as well.
And so getting these guys to talk isn't
always very easy and it doesn't always
make sense.
But by and large, I think there's enough
commonality still between all the boards
that it would make sense that when
it comes to things that are attack
surface and fixes, it
would probably make sense of these guys
talked more with each other.
The other thing is that obviously, when
it comes to things, you know, if you look
at countries alone, that tells you
something about your tax.
If it's right, can as kernel is about
two point eight millions of code net BSD
is about seven point three million in
that business.
And this is 10 this was 11
points or I don't know what the latest
one is. The freezy was about nine
million. Right. So that alone tells
you that it is going to have less bugs
because they have less code.
Right. It's that easy.
So obviously, this plays a part, right.
You can't have a bug in code that you
don't have. Right.
And the other thing is obviously
sort of accidental versus planned where
if I haven't gotten if
I haven't done something yet, then you
can't have it yet. Right.
But the other thing is, obviously, is
that the plan was choices to make
the delete code on purpose.
And this is something we saw in OBC
where, you know, they chose to delete the
Bluetooth stack. They chose to delete
their letters, come back later.
And obviously it's a double edged sword.
You lose functionality, but you gain
security and try to find that balance
to obviously, you know, cutting code.
You know, that generally, you know,
it cuts to service and generally means
you have less bugs.
Right, so, yeah,
my conclusions basically
going back to what I
was dealing with, that, which was the
many eyeballs thing.
Yeah, I think that's a factor.
I think it really does matter.
Right. I think if you have more people
looking at something, more books are
going to be found.
And so I think one of the big reasons why
the numbers are off when you compare
those tables initially, I think
a large part of it is
more people are looking at a girl and so
they're going to find more bugs.
Coach quality can't explain
everything.
And right, I mean,
you can say what you want about people,
ratlines colonel, but, you know, there
are just orders of magnitude people.
More people looking at that quote are
just going to find more bucks.
And it shows in numbers,
and that's pretty much it.
That was frightfully awesome.
OK, I'm quite convinced people
want to ask a bunch of questions,
we got about nine minutes.
Let's start with
you over there.
One sentence, one question mark,
but thank you for your awesome
work and nice presentation.
And the question is,
are you interested in
exploiting
so you had a crush crush
us? And how about making
a proof of concept legal privileges
coalition or RC
and what is execution?
Yeah, given that my plan was
to report all the bugs I saw
really no point in running football next
points because it's wasted effort, right?
The only to me, the only way I mean if
I go to my next point, I don't
like I don't, I don't want to next one
for a bug. I know it's going to get killed.
Right. So I didn't see I mean,
some of these bugs would have taken me
weeks or months to sit down and write
code for.
And so I didn't I don't think it would
have been very useful for me to write
full-blown exploits.
I know there's a shock and awe factor to
exploit. And at times they can be useful,
given my understanding or my assumption
that the people on the other end, I was
talking to people like Dō
that are very knowledgeable in this area.
I didn't feel there was any need to write
the write next board, and so I didn't.
Does that answer your question?
Things.
But
showing exploits usually
helps to convince people in
self-protection technique technologies
like we have our security and.
Oh, yes, absolutely no.
I mean in mitigation obviously got a good
thing. And we should we should keep
innovating in scoring new medications.
It's just that I don't think this would
have contributed much to it.
OK, thank you.
There's a question from the Internet.
Please listen to the dark side.
Yes, I think the dark side.
How would you suggest to improve
cooperating between the different BSD?
That's a good question.
I mean, I don't know.
I understand because I know I
know what you said a few things about.
Well, you know, it's not easy to talk to
other people because so and so and so
I don't know how to you know, either they
get these guys in a room and get them to
talk or something.
Obviously, there's
there are some difference between the two
and they're not there.
Certain things, obviously, that,
you know, where there's differences, they
don't necessarily have to talk to each
other.
But I can't I don't really
know of any specific way to try to
massage them, to talk to them, to each
other. All I can say is find
the right containers for the right
subsystems. And if some guy fixes
a bug, it's something where they go, this
is a tax surface.
You know, reach out to the guy on
the other you know, the other
BSD, Amela, and just drop.
And it will be like, hey, guys, maybe you
should look at this to be all that.
I have no good answer, really.
OK, thank you.
Is there another question from the
Internet?
Not yet.
How about one last question?
We got five more minutes.
Anybody at the microphone who.
I'm not really seeing anything out there.
OK, over
there on the left. Excuse me.
My question was about methodology.
Did you use any automated tool or did
you do everything by hand
where you come from?
Anywhere on the left side,
your neighbors are in the back.
Oh, OK.
Yeah, well, I didn't
I nine out
of this thing was like straight up
reading code.
Just, you know, I open up in
an idea and I was reading it.
There were a couple of times when I used
some grep to look for some patterns.
But beyond that, no, it was just me
reading code that
was pretty much there were no other tools
involved.
I think we'll take one more, one more?
Sure, yeah.
One more here
than you want to.
Now's your big chance.
Could you describe your motivation
of spending three months
on that work?
Yeah, I know CAVU isn't
for everyone. I think I once heard it
described being more boring than watching
paint dry.
I disagree with that.
I actually I enjoy reading code.
I think it's fun.
I think there's a number of things you
can learn from reading code
and it's sort of interesting
sort of kick from writing. Like if I find
a bug in pieces like sometimes used to be
the code and I'm like, oh
like, oh, they screw this up.
Like, I noticed this and they didn't.
So there's a little bit of that.
But generally,
yeah, I, I generally enjoy it and
I know some people don't, but for me
it was, it wasn't a death march, it
wasn't a stretch. I was I had no problem.
And when I say three, three, four months,
I mean on and off because obviously I've
worked and things. So it's like evenings
and weekends.
But it wasn't it wasn't hard.
It was difficult. I was just like, OK,
let's open up my laptop and I'll spend
the next three or four hours looking at
the system or something.
I didn't think it was hard.
I understand there's not for everyone,
but I.
I tend to enjoy that view.
Thanks again for your work.
I'll see.
OK, thank you very much.
Am I overseeing a question somewhere?
No, now's
your chance.
The Internet, yes.
There's one final question from the
Internet.
Why the BSD may not be cooperating?
Is there at least a common mission
statement or any high level thing that
they could at least agree on?
This is a non security BSD
question. I have no idea.
I think there are people here that are
probably a much better
place than I am to answer these kind of
questions.
I have no idea.
OK, if that's it.
Thank you. But let's have a final hand.