www.youtube.com/.../watch?v=DobIrGdLEi0

*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)]