[libtorrent] Libtorrent afl-fuzzing?

[Jacek Wielemborek]

List,

(please CC me, I'm not subscribed)

I'd like to ask you whether libtorrent was already tested with afl-fuzz
[1]. If not, would you be interested in cooperating with me to achieve
this goal? I know afl-fuzz very well, but I have no knowledge of libtorrent.

Cheers,
d33tah

[1]: http://lcamtuf.coredump.cx/afl/

[Arvid Norberg]

Post by Jacek Wielemborek
List,
(please CC me, I'm not subscribed)
I'd like to ask you whether libtorrent was already tested with afl-fuzz
[1]. If not, would you be interested in cooperating with me to achieve
this goal? I know afl-fuzz very well, but I have no knowledge of libtorrent.

I have not fuzzed libtorrent, other than some of my own lame attempts. I'd
be exited to try it out though.

The obvious surfaces that might be interesting to fuzz would be the peer
connection (i.e. network messages)
and the loading of .torrent files.

The former is probably more interesting as a vulnerability there is
potentially more severe and also the amount of code part of that interface
is significantly more.

please feel free to follow up with me off-list.

[Arvid Norberg]

I spent some time trying to get some python fuzzing framework to build,
unsuccessfully. Then I built a naive "fuzzer" that takes a .torrent file
and systematically introduces errors into its encoding and passes it into
libtorrent's parser:

https://github.com/arvidn/libtorrent/blob/master/tools/fuzz_torrent.cpp

I read a little bit about afl-fuzz and it sounds pretty exciting. Does it
need any guidance or will it arrive at valid constructs relatively quickly?
I assume it uses code coverage as feedback, to score inputs, right?

If so, it seems pretty simple to use. I imagine I would need to adjust a
few things. For instance, for an incoming peer connection it would have to
accept any info-hash, since it's not likely to discover 20 bytes of random
looking bits.

Post by Arvid Norberg

Post by Arvid Norberg

Post by Jacek Wielemborek
List,
(please CC me, I'm not subscribed)
I'd like to ask you whether libtorrent was already tested with afl-fuzz
[1]. If not, would you be interested in cooperating with me to achieve
this goal? I know afl-fuzz very well, but I have no knowledge of libtorrent.

I have not fuzzed libtorrent, other than some of my own lame attempts.

I'd

Post by Arvid Norberg
be exited to try it out though.
The obvious surfaces that might be interesting to fuzz would be the peer
connection (i.e. network messages)
and the loading of .torrent files.
The former is probably more interesting as a vulnerability there is
potentially more severe and also the amount of code part of that

interface

Post by Arvid Norberg
is significantly more.
please feel free to follow up with me off-list.

Hi,
Let me know what you tried so far (example test program and how you ran
it) and we can start working from there.
Cheers,
d33tah

[Jacek Wielemborek]

Post by Arvid Norberg
I spent some time trying to get some python fuzzing framework to build,
unsuccessfully. Then I built a naive "fuzzer" that takes a .torrent file
and systematically introduces errors into its encoding and passes it into
https://github.com/arvidn/libtorrent/blob/master/tools/fuzz_torrent.cpp
I read a little bit about afl-fuzz and it sounds pretty exciting. Does it
need any guidance or will it arrive at valid constructs relatively quickly?
I assume it uses code coverage as feedback, to score inputs, right?

You're right. Basically you need to recompile program with afl-gcc (or
afl-clang) to get optimal performance.

Post by Arvid Norberg
If so, it seems pretty simple to use. I imagine I would need to adjust a
few things. For instance, for an incoming peer connection it would have to
accept any info-hash, since it's not likely to discover 20 bytes of random
looking bits.

Right once again ;) Those checks need to be disabled in order to get
best coverage.

As for connections, one caveat is that currently you need to fit all
state in one file - AFL is a file-based fuzzer, which means that for
fuzzing networked applications, you need to use it together with a
project like preeny. This also means that it's not easy to simulate
connections where multiple buffers are sent.