*37c3 premusic* [Translated by Viljami Kittilä (KYBS2004 course assignment at JYU.FI)]
All right, everyone, welcome back. Our
next talk is fuzzing the fuzzing
TCP/IP stack with Ilya. Please give him
a warm round of applause.
*Applause*
Great. Thank you for the introduction. As
was just mentioned, I will be talking
about fuzzing stack going beyond
trivial. Just a fair warning and I'll get
into this a bit later. This is a very,
very early pre-alpha version.
There's more to come, but I have
some things to talk about and report and
hoping to maybe move to the kind of
current state of this a bit further.
Right, so who am I? My name is Ilya.
I have been coming to the CC Congress
since 18C3, which is really
not a way of saying I'm old and decrepit.
I've in the in a
handful of those times. I've also spoke
here before. I spoke on some issues with
clearing memory, which I called Memsad.
I spoke on some X11 things about a decade
ago. I spoke on some Windows stuff. I did
a general fuzzing talk about 15-16 years
ago, and there were a few others that I
can't really remember because I'm old and
my memory sucks. But
what's really cool is it's really,
really glad. I'm really glad to be back
here after four years.
Yeah, right. Yeah,
absolutely. Oh, man, *Applause*
I was almost. It was almost going to
happen last year. And then I guess
something happened. It didn't.
But hey, here we are. All good again.
Hopefully we, hopefully, you know, we
won't have to wait another three or four
years for the next one. I'm definitely
looking forward to the next one already,
even though I guess we're only halfway
through. But yeah, that's kind of who I
am. Yeah. I mean, also I work at a
company called IO Active. We do computer
security. I do code review and
pen test and fuzzing and all those kind
of things. You know, I'm a security kind
of consultant/engineer.
Right. So what am I going to talk about?
Basically, I'll have a slide kind of
talking about the audience that might be
interested in here. But if you're here,
you probably only know who you are. And
then I'll kind of go into a little bit of
the history of doing TCP/IP
stack fuzzing and this like low-level
network fuzzing and kind
of where the state is today
and then kind of move on to.
Where I see it going, what I'm, what I
will be the crux of what I'll be
presenting and then sort of the how do we
go beyond that. And then
the the kind of middle part of my talk is
kind of the where I'm at. So
sort of how I want to do some or I
envision doing sort of the quote unquote
next level, whatever that means. Of
TCP/IP stack fuzzing, you know, and I'll
talk about kind of what I want to fuzz
and how I want to fuzz it. And I'll talk
about the set up and I'll talk about
certain modifications I made to a network
stacks to try to make this happen.
I'll show how to get all this thing
set up and how to kind of the
usage of the stuff I've been that I kind
of built and then I'll
do a small demo. And
then after that, if anybody is still in
the room, I'll take questions.
Right. So the audience, I mean, you know
who you are, but if it isn't clear, if
you're if you like fuzzing, this might be
interesting. If you're a network geek,
this might be interesting. If you're
operating systems guy, this might be
interesting. If you like technology, you
might like this. If any any kind of sort
of security, network, OS, fuzzing.
Then this may be for you, but even if you
don't fall in that category, you might
still find this interesting,
right? So let's let's get into kind of
the history of things, right? So I'm
obviously, you know, not the very first
guy to go, hey, you know, we have these
TCP/IP stacks and they
take network packets and they parse bits
and bytes and they handle state. Isn't
that interesting? Surely that's attack
surface, right? In fact, you know,
you go back to the 90s and probably
before that, but you know, I wasn't
around before that. So if you
look at kind of the the state of
network stack bugs in the 90s,
it was sort of very trivial stuff. For
those who were around, you might remember
like WinDuke and we had things like SYN
floods and Ping of dead
and you know Smurf and
LAND and Teardrop and Bonk and all
these mutations and Boink and what have
you and
and I wouldn't say they were really a
result of fuzzing, but they definitely
were some kind of result of some kind of
runtime testing. I think at this time
very few people were actually doing any
kind of targeted code review or
fuzzing, but people were at least, you
know, people observed certain bugs in the
network stack and. Observe that they
could write tools and exploits to use
them mostly for things like denial of
service. But that's kind of
where this starts, sort of mid 90s
ish with these kind of trivial tools.
None of this should work today,
but that's that's kind of the the where
the history starts of this. And then
we kind of get into the late 90s and the
2000s and
you know. We had better, we had
some libraries like libnet and things
like that. And somebody wrote this
tool called ISIC, the
IP Stack Integrity Checker.
And ISIC is really, really cool.
Somehow it's one of these tools that not
many people, everybody should know about
them. But you know, I when I talk to
people, oftentimes they'll be like, what
is this thing? And then you go download
this thing that's 20-25 years old and you
run it against. Network stack and
sometimes bugs come out. It
was extremely successful back in its day.
It it would break windows up to Windows
7. There was some nasty bug in the UDP
handler. It's broken. It only sees IP
stack several times. I mean they twiddle
with their stack often, so sometimes
stuff breaks and they fix it and then two
years later it breaks again on something
else and so on and so on. It's definitely
broken to that BSDTCP/IP stack. The
top three I know because I I hit those
bugs too. And then kind of the bottom
one's the like Checkpoint Firewall and
the Gauntlet Firewall and the Raptor and
so on. I didn't, I never observed any of
that because I don't have access to that
hardware. And of course that hardware, I
mean this is this is basically from their
trophies file which is from the late 90s
and so this these these are kind of
products of that time. But like
dot, dot, dot because this this stuff,
this thing really used to break
everything and on occasion it still
breaks stuff, right? And
the the way ISIC really works is it
understands the structure of an IP packet
and the structure of a UDP packet and the
TCP packet and an ICMP packet and an
Ethernet frame and it just,
you know, bit bangs around and
has some options to go hey. Do you want
to fiddle with these flags or TCP flags?
Or do you want to fiddle with IP options
or TCP options? And or do you want to
mess with the checksum? And then it just
keeps this one buffer and then has this
loop and it just keeps changing a few
bits and keeps firing these things off.
The speed of ISIC is really pretty bad,
pretty insane. Like it's it's fast.
But it it's limited, right?
It can only it doesn't understand any
kind of state and
so it while it finds a certain amount of
bugs, there is beyond a certain point it
just it can't get beyond that. It can't
find those bugs, right. But even so
that's this is kind of where
we've been stuck for 20 years, right.
That's so it's kind of why I wanted to do
this presentation. Since, you know, you
can use SCAPI and do similar things with
SCAPI. The reason I like ISIC and still
like it today is because it's it's
it's very simple C code and it's just
blazingly fast.
Anyway, how do we go beyond this trivial
state? We've been stuck here for 20
something years. It's time to
move on, right? As I mentioned
before, it turns out. TCP,
which sits on top of IP and some other
things, has state
and there are, and you
can ask network engineers and people that
build these network stacks and so on.
There are bugs that sit behind these
states that if you just throw packets at
it without ever getting into the state,
you will never hit these kind of bugs,
right? You can't. So
you just can't get there with crafting
packets, simple packets. You need to like
complete your three-way handshake and
like set up like the right extensions and
the right flags. And like I send you this
and you send me this and I send you this
other thing and you send me this thing.
And all of a sudden you get into this
weird state where maybe some bug happens,
right? But that's pretty deep. That's
pretty deep into like your network
protocol. If you're just banging out some
bits, you never get there, right?
And so. Getting to
this point and trying to fuzz beyond
that, this is hard and it takes a lot of
time.
As I said, the state really hasn't
advanced much beyond this.
There's been some research the last
couple of years cause I kind of googled
around for these things. And so there's
this Amnesia33 and then there's
this academic paper TCP Fuzz
where they kind of use this.
Network stress / test
tool by Google, which isn't really a
fuzzer, but you can kind of
coax it into like becoming a fuzzer-ish
called packet driller. And so they found
some interesting things with that and
I'll kind of circle back to these
things a bit later.
So of course you know with with the
enormous success in the last decade and
change of things like AFL and AFL+.
The first thought is, aha, let's let's
use coverage guided fuzzing. Fantastic.
Let's do that. And that would be
great. It turns out it's not that
simple. There there have been attempts
in principle. Yes, you want to do
coverage guided fuzzing. It's not
easy. There are some
problems, right? So first of all, AFL and
AFL++ work incredibly well
when: A you have a file
where really all of your state is
maintained in a file, or you have a very
simple API where you go.
Here's a here's data and here's a length
and go parse right. It is. It
works exceptionally well for those
situations and a lot of
attack surfaces like that. A
network stack doesn't quite work like
that, right? It's
not. It's not a file. It's a
protocol, which means there's things that
get to state that doesn't isn't like one
bit inside of a packet, right? So it's
it's this weird thing that you is like
encoded in a series of things. It isn't
like represented by one bit or one byte
or like a length field or something like
that. That's one. The
other one is packet queues.
What I mean by packet queues is
basically. So if you let's say if you
have a network, you have a file parser,
usually you have like file parse function
and you have a length and a pointer and
it parses the thing and it returns and it
does something. When you do a network
stack, because it is so tightly
integrated into the bowels of your
operating system, it
like what happens is a packet comes in
and the NIC kind of sees it and it
triggers an interrupt and the interrupt
handler kicks in and goes great and it
kind of takes it from the interrupt
queue. And then it looks at it and it
goes, oh, this is Ethernet. I'm going to
put this on Ethernet queue. And then at
some point your Ethernet handler wakes up
and it goes, oh great, I'm taking another
queue and it goes, oh, this is IP, great,
I'm put this on the IP queue and it goes
back to something else. The IP queue at
some point wakes up, takes this thing off
the queue and goes, Oh yeah, great, this
is IP so and so. Oh, it's TCP. Yes, yeah,
I have an open TCP port. Great. I'm going
to go put this on the TCP queue and then
the TCP queue at some point, you know,
TCP thread wakes up, takes it from the
TCP queue and goes. Yes, I know this guy.
I've been talking to this guy. I have a
userland service that's running. I'm
going to take this thing and give it to
the userland guy and the userland guy
just called receive and receive now
return. And and so it's you have
you have a bunch of these steps and
and it's it's they're not it's not
linear. It's not 1,2,3. It's one
guy and then somebody else and then
somebody else and then somebody else
and. While you can
instrument that, it's not quite as simple
right? As I mentioned
the other one issue is
the state can easily be captured in
in any kind of file or set of
data. It's really like a a sequence
of things.
So that that's where things get
problematic and and there are people that
have you know discussions and people have
tried. And
someone said, hey, you know, we actually
tried with AFL and we got somewhere,
but they said, you know, we ran into
problems, which is exactly what I was
just talking about. The the queues,
the async, the asynchronicity of
it all makes it very
difficult. It it doesn't mean you can't
do coverage guide fuzzing, but it means
it requires an extra set of work
beyond what we've done before
and so. I mean, my
opinion is we have to work towards
getting this, but we are
very far away from it. Getting that done
in any kind of way that is reproducible,
easy to set up, doing like a
one-off where it works for one guy and
then getting to some level
of fuzzing. That's what this this guy is
describing, right? But getting that to
any kind of level where we can repro that
and and make it, you know. Not make your
life miserable when you try to set it up.
Nowhere close to that.
So as I said, this is that this is why
like the state fuzzing is just hard and
time consuming and I'm
definitely not here to talk about
coverage guided fuzzing. I just wanted to
kind of see where we're going. I'm
basically I'm very I'm a
I write code I do you know I'm lazy right
so. And the thought
I had is instead of doing that,
what we really want is I want to have my
own network stack that I can fiddle with
and then talk to somebody else's network
stack. OK, basically, you know, modify
this network stack so that it adds
fuzzing. And because the network stack's
already there, I get all the state for
free because the stack is doing that. But
as I said, I am lazy. There's no way I'm
building my own network stack.
But the good news is I don't have to,
right? If this was 10,15,20 years
ago, you would have been out of luck and
you would have had to do that. But
today it turns out we have a number
of userland TCP/IP stacks, right?
And they're often used
for like in embedded stuff or to test
certain things. Somebody wrote a port
scanner with it, like you can do all
sorts of things with it. But somehow, as
far as I can tell, no one's ever looked
at it and said, Great, let's go
co-opt one of these network stacks and
turn them into a fuzzer. And that was
kind of the idea I had. That's kind of
the crux of this presentation.
One of the things I did is looked
around and said, Okay, what's what's out
there? And it turns out there's quite a
few. There's libuinet, which is a
port of the BZ network stack to use
LANs. It's fairly old. It hasn't been
touched in eight years. I have no idea
what its current state is. I just
looked at it the time stamp. I was like,
uh, I don't want to mess with this. It
might just be too painful. There's PyTCP,
which is a fully functioning network
stack in Python.
I considered using that. It was a
bit too painful for what I had in mind.
It it does like it comes with its own.
Like DHCP server and things like that.
And that's that's too much. I I don't
want that. I just want the network stack.
So there's a few others. I looked at
Netstack, which is Google made this as
part of their Gvizor
products, offering, whatever.
And Netstack used to be a
separate thing and then it somehow got
moved into Gvizor like the repo.
And trying to separate one from the
other, I'm sure there's a way to do it. I
tried, couldn't quite get
there. I didn't spend much time on it,
but I'd say couldn't get it done within
an hour. And that was kind of like, OK,
you're out. I need something easier.
There's LwIP, which I know is used in a
few places. There's Smoltcp, which
is a TCP stack entirely written in
Rust, which is very exciting. picoTCP
uIP, there's a bunch of others. I
settled on picoTCP and I'll talk about
that in a minute.
Before I get to like the actual
implementation and kind of testing I did,
what do we actually want to fuzz?
This this isn't really a hard question,
but you know, we should determine this
before we actually set out to to fuzz
this thing, right? So yes, the idea is we
take a userland TCP/IP stack, we modify
it. To fuzz the right things, we get the
state for free because the TCP cycle
already does that. But what do we then
want to fuzz, right? And the answer then
is, OK, let's go look at the
protocols and see what's there and where
we know their state and where we know
things go wrong and where we know things
have gone wrong in the past, right?
Basically stuff where there's complexity,
right? And if you're looking at, for
example, TCP. Like obviously your flags,
they tend to signal things and cause
transitions in states. You know,
obviously a SYN or a SYN ACK or
those kind of things tend to cause
transitions in state.
Window sizes are interesting. They've
definitely. They're kind of subtle, they
seem trivial, but they've caused problems
in the past. So messing with window size
is a great idea. Checksums
shouldn't be a problem,
but I have seen problems where checksum
functions will read out of bound by one
or two bytes. So on occasion checksums
are a problem. Obviously the
size of packets is interesting, right?
If, you know what happens if you get a 0
size packet, right? Is that even legal?
Spoiler turns out for UDP it is legal,
for TCP it is not.
What if you send really large packets?
What if they're larger than the MTU? What
if you use jumbo frames and so on? Some
of this triggers fragmentation, some of
it doesn't. And obviously
the obvious one is length fields, right?
Can we mess with length fields?
And then obviously fragmentation is
interesting, right? We know there have
been plenty of bugs with fragmentation in
the past. We know there's going to be
bugs in the future with fragmentation. So
that's that's definitely something you
you would want to fuzz. And you get into
all sorts of is it too big or too small
or too many or not enough or out of order
or some stuff timed out or some
duplicates or you set a don't fragment
flag, but you fragment anyway. You know,
you get all of these weird fragmentation
things. And then sort of
lastly is, you know, options, right?
So IPv4 options, TCP options,
IPv6 extension headers, right?
Insertion, truncation, removal, out of
order, any of combination of
these could be interesting, could lead to
some kind of issues
in state or parser or a combination of
both. So that's stuff that we would want
to fuzz.
So as all of these may or may not relate
to state, I care in the sense that I want
to get to state, but I also don't really
care in the sense that because I already
have a network, I userland TCP/IP stack
does the state for me. So I just kind of
piggyback off of that. And
then of course you can just build on it,
right? It's like, OK, well what about ICMP?
What about SCTP? What about IGMP and so
on for SCTP? It's like, OK, pick
SCTP doesn't support it. I wanted to use
loop UInet, but I never got that far. So
ultimately I want to get there, but
not not even close to it. SCTP, by the
way, is one of these weird things where,
like, if you're a network nerd, you've
probably heard of it, but you've never
seen it because nobody, nobody uses
SCTP except when you get to the TelCo
world. And then everybody uses
SCTP, right? So it's one of these really
large niches, but outside of that,
nobody, nobody really uses it.
Right. So that's kind of OK when I want
to fuzz and how I want to fuzz. Let's
let's let's talk practical things because
I did, I kind of built this fuzzer right
and it does this thing. So how does that
work right. So well the first thing you
do is as I said you pick one. So
I chose picoTCP and I'll get into that in
a moment. Your steps for set up are
relatively easy. Essentially
you set up a TUN/TAP interface. You
play around with like a bridge and like
add if and BRCTL and so on
and then you need something to drive
traffic. And So what I did is I created a
simple echo service and an echo client
and that obviously you do that in a
loop but it kind of ends up driving
traffic till the end of time, which is
great because now I can just hook into
the network stack and and start messing
with things. And because the, you know,
the echo client server just keeps sending
data back and forth and back and forth
and back and forth, it'll just that just
drives fuzzing, right? And then the last
step in the setup is yes, you need to
modify your TCP/IP stack and add fuzzing
to normal traffic.
So yeah, as I said, I
used picoTCP and here's why.
So I evaluated a bunch of these things.
Initially I wanted to go with PyTCP.
It I just didn't. It was a little bit too
hairy for what I wanted to do, but it
it it does work. I was like, OK, picoTCP
looks great. I used to write a ton of C
code. I haven't touched much C in the
last couple of years, but it was
nice because I got an I now have an
excuse to write some C code. And picoTCP
is it's pretty
simple C code. It's not very complicated.
It's easy to get started with it. It's
easy to integrate into into your own
userland program. It's easy to read the
code. It is easy to modify. And best of
all, it's open source and free software.
It's entirely GPL. So that means I
can do whatever the hell I want with it.
Sweet. So yeah, I should have
put one of this in this slide,
but essentially. I don't know if you can
read the code from how far, but
essentially one of the cool things about
picoTCP is that it it comes with
very simple, very easy APIs. And so I
built a simple echo client using the
APIs. And so essentially
you kind of go and say, yeah, I want the
stack to have this IP, you know, I want
to, you know, create a socket and
then go connect with somebody else on
that socket.
And that's just, I mean, it's the APIs
are really, really simple.
Sweet. So with that,
I I'll do a demo.
I'll say this though, lower expectations.
I didn't quite get as far
as I wanted to. The the fuzzer works.
Just barely though, but it works. I
didn't implement everything I wanted to
implement. There's lots of to do's.
The fragmentation, for example, I'm not
there yet. In terms of
trophies, not really any significant
crashes yet. I did find a minor denial of
service in like dominic street network
stack where if I'm throwing packets at
it, something else at some point can't
connect to it until you kind of stop
throwing packets at it. I don't know if
that's really a state thing. That may
just be that the stack is so slow it
can't keep up, even though I'm not
throwing packets at it that fast.
But yeah, let me let me do a little
demo.
Sweet. So here I have an open BSD machine
which is running my echo daemon
and here
I have my my fuzzer. This
runs, yeah, a Linux machine.
So this is this one is
182168.11 dot I think
131 or 130 and
then the open busy machine is 132
and so you'll see traffic here in a
second and should have
yeah sweet. OK
so kind of drive traffic from here and it
goes like yeah yeah I'm fuzzing and
fuzzing and fuzzing and fuzzing. And then
Wizzy goes, yeah, I see your packets and
they're kind of fuzzing and they're
echoing some things, but it's dropping a
lot because there's all sorts of things
it doesn't like.
And then like if you go through this
stuff, there's you'll see a whole bunch
of like retransmissions and like some
broken packets and all sorts of things
like it's not it's.
It's good enough that
packets get through and get processed and
make it pass the three-way handshake and
they get echoed back. It's broken enough
that a lot of this stuff doesn't get
through and gets stuck somewhere. And my
hope is somewhere in there, it will find
bugs. Uhm
This code started working this morning at
about 6 a.m.
Yeah, so
*Applause*
The the downside is I I'd hope to find a
bug or two. Not yet, which is kind of
annoying, but
this is this is about as far as as I go
with that. So yeah,
it's pre-alpha version. There's
work to be done. As I said, it works, but
just barely. As I said, I can force
packets through the stack, do a three-way
handshake, and sometimes the echo
service even acknowledges and sends it
back to me, which is great. Sometimes
my echo client crashes and that's why I
have a bash loop around it. As I said,
it's it's ugly, but it works.
And as I said, I haven't implemented
fragmentation yet, so lots of
work to be done. The code is incredibly
ugly, but given and I wanted to get
further than I did today, but it does
work somewhat
and I put it on GitHub. So if you want
to, if you want to play around with it,
you can. Expect updates in the
next couple of days and weeks. I hope to
get this in a much better state. It is
really ugly by the way,
and it currently
I don't actually have a full picoTCP code
in there. I just took a diff and the diff
is kind of screwed up so I do need to fix
it. But everything if you really want to
get working, everything is there. But
I'll in the next couple of days I will
clean it up and make it easier to work
with. But if you want to get going to
like right now. It's going to take you
some effort, but it's there. But
if you hold on for a few more days, maybe
a week, I will make sure
it works. It's it'll be easier.
Yeah, I'm kind of out of time, but last
thing I kind of wanted to talk about is
why stop at one fuzzer, right? One of the
really cool things I like about AFL++ is
its integration with other fuzzers. And I
think that's something we should start
doing in everything we fuzz. It's like,
why stop at one fuzzer? If there's
something else, find a way to make them
work together, to cooperate and
collaborate and so on. I
mentioned the package ruler before.
Like you could definitely get some
package ruler in there. Why not throw
some ISIC in there? There's IPv6
toolkit, there's a few others. So I'd say
don't just stop at one fuzzer, combine a
bunch of things. Yeah, I was talking
about some previous research.
Yeah. As for conclusion, I don't really
have much of A conclusion except for I
should have started this earlier and
gotten further.
*laughs*
I do have long-term goals and a call to
action, right? To me, it's clear
that using a userland TCP/IP stack
will move the state beyond where we are
today with. Just using
ISIC for example, right? ISIC still finds
bugs, but you know, it's twentyfive years
old. We let's have a better approach,
right? And so I think using
userland TCP/IP stack is seems very
promising to me. I think it's a good move
forward. It's not the end
goal, right? Ultimately we do want
coverage guided fuzzing and but I don't
think those are mutually exclusive. In
fact, I think both will work well
together. As I said, doing this
currently is very difficult.
I'm hoping to you know find other people
that will want to work on this as well.
My goal here is really just to get things
moving and get some ideas going, really.
Yeah, I guess I'm one minute over time,
but that's that's essentially my
presentation.
*Applause
Thank you. All right. We have
8 minutes for questions. So if you have
any questions, please line up at the
microphones and we will take them. And if
you're on the stream, you can also ask
questions on the Internet. And someone
already did. So please go ahead.
Yes, thank you. Thank you for the great
talk and the great effort and getting it
ready for today. One question from the
Internet here is where do you see like?
What else do you see that that could be
done like fuzzing ICMP
or or so on? It's like good userland
tools also available here. Just what are
general thoughts on the landscape?
Yeah, that's a really good question. ICMP
think is a good one because I mean that's
one of these things where usually. I
I see packets generally don't come out of
nowhere. They tend to come out of
something in the state went wrong. Like
you're talking to the TCP thing and all
of a sudden the port closes and then you
get an ICMP going, hey, you know, port
closed or something. So that's definitely
stuff you can do to
some extent. I have that implemented in
the sense that I don't, I haven't don't
have any code that explicitly evokes ICMP
packets, which is something that I think
should be added. But I do have code that
says, hey, if the network stack generates
ICMP messages, I will go fuzz that. So
that is implemented. But
ICMP is is a really good one. There's
definitely more work to be done there. I
mentioned some of these things before.
So it's yeah, so definitely
IPv6, which I haven't implemented yet.
The extensions I think is interesting.
Yeah, ICMP here, IGMP is another one.
SCTP. I mean the
opportunities are really boundless and
endless, right. So I think it's a great
question. I don't have the answer to all
of them. I think I enumerated some.
There's definitely more it would make
sense as an exercise to to really dive
deep into kind of every
possible thing you can have in in your
state in TCP/IP stack, explicitly
enumerate it and then go kind of like
this goal oriented approach where you go.
Have I implemented this? No. How do I do
it? Have I implemented this? Have I
implemented this? As I said, I kind of
ran out of time. I'd like to do this. I
haven't done that yet.
All right. We take mic #2, please.
Hello. Thank you. I wasn't quite
clear. Are you fuzzing picoTCP
or are you just using picoTCP
to take care of a bunch of stuff that you
are too lazy to do. That's exactly it. I
I'm not. I mean you you can fuzz picoTCP
with this too. It's not what I'm doing
right. I'm using picoTCP to be my TCP
stack, right? That means I don't have to
write it. And then what I did is I
basically the way picoTCP works
is like it's not a library that in the
sense that like it's on the system. It's
a it's a library in the sense that it's
part of your application. I compile it
with me. And so because of
that, I can like the the picoTCP
source code is part of my program. So
I literally just add hooks in a bunch of
places in picoTCP and go, oh, before you
send this out, if it's IP, do IP fuzzing.
If it's TCP, do TCP fuzzing. If it's
ICMP, do ICMP fuzzing. Add extensions,
mutate extensions, that kind of stuff. So
you're fuzzing the remote system.
Correct. All right. Thank you.
All right. Do we have any further
questions in the room? No.
Internet go.
Yes. Another one.
How do you meter kind of like the
underlying stacks? How do you look at
branch coverage and so on?Are you doing
that already on how are you doing it?Yep,
that is a great question. That's coverage
guided fuzzing. I'm currently not
doing that right. I spoke about that a
little bit. We need to move in
that direction. It's
definitely. I think that's the end goal
really. The problem, some of
the problems discussed there is, that
it's not quite as easy as it's made
out to be. You're dealing with a
low-level operating system, so it's not
as simple as instrumenting a user on a
program. You're dealing with queues
instead of files or like one file parser.
So dealing with queues is a pain in the
ass, and then you're dealing with state,
right? Which means a lot of things.
Don't necessarily encode to one bit or
one byte, but it's really a combination
of you sent this and then I sent that and
then this sent and then so on. And as you
separate different things lining up that
then causes a state transition, right.
And so it's there's at least from where
I'm standing right now, there's no easy
way to do this. As I said, we need to
go there. That's the end goal. How
we go there, there are certain gaps that
need to be filled. Were you in
yesterday's talk about the Qemu fuzzing?
Unfortunately, no, I had code to
write. I think that's a good, good start.
All right, mic #3, please. Hi,
great talk. I wanted to ask if it's maybe
possible to integrate fuzzing into the
Linux kernel itself to fuzz its TCP/IP
stack. Yes,
you can. So when you get to like
a net filter, there are places there
that you can use to to
to fuzz with. I looked into it. It's one
of the things I wanted to do. It was on
my ToDo List. Once I get done with, you
know where I get with picoTCP and some
other things. And again, it's one of
these things. It doesn't have to be one
or the other, right? You can combine these
things. So that is a great
approach. I thought about it. I want to
do it. I haven't gotten there
yet. That's 10 steps away from where I'm
now. I hope that answers your question,
but I think it's a great question and the
answer is yes, we we should do that. All
right. Thanks. All right. Do we have
any further questions from the Internet?
If yes, we have one and I think it's
it's very general so.
The question here is have you have used
considered using Rust for the fuzzer
itself like the hyperHTTP
library or something like this. Yeah
so I did I mentioned Smoltcp so the the
given that there's a network stack for it
you can use Rust. I haven't
I didn't use that I I'm I like Rust. I
think it's a great programming language.
I think it's. At some point,
hopefully it'll replace all or most of
our C or C++ code. I have
many great things to say about Rust.
I am not a great Rust developer. I've
written a little bit of Rust code, but I
I have a large learning curve and for
that reason and only that reason, I
didn't go with Rust or Smoltcp. It's
just it's my own limitations. I wish I
had known more Rust, but you know, life
happens and I didn't. I haven't had a
good opportunity yet to to write a bunch
of Rust code. Someday I hope to get
better at writing Rust code, and I would
love to do some of this stuff in Rust,
but the only reason I didn't
touch anything in Rust here was I
wasn't confident I would have gotten
anything done in time.
All right. Then we will
simply end the talk perfectly on time.
Thank you very much, Ilya.
*Applause* *37c3 music* [Translated by Viljami Kittilä (KYBS2004 course assignment at JYU.FI)]