Opened 4 years ago

Last modified 23 months ago

#16301 new enhancement

Add a fuzzing harness for the torrc file

Reported by: teor Owned by:
Priority: Low Milestone: Tor: unspecified
Component: Core Tor/Tor Version:
Severity: Normal Keywords: lorax
Cc: Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description

It's possible to build tor with afl-fuzz, but it requires a custom test harness to do anything useful.

Over the long term, if tor is refactored into separate libraries, this may become easier.

Child Tickets

Change History (12)

comment:1 Changed 4 years ago by asn

Good idea. More fuzzing!

I think Tor would have to expose its cell parsers and directory documents parsers for this to work nicely. I don't expect afl-fuzzb to ever be able to generate actual Tor traffic.

Maybe we could switch Tor to fuzzing mode using a CLI switch, and then you can just feed it descriptors/consensuses/cell data on stdin or something.

How is other software doing this?

comment:2 Changed 4 years ago by teor

Most of the software that I've seen fuzzed is already split into libraries which process files or data buffers (think ImageMagick and libjpeg/libpng/...)

When I fuzzed torrc parsing in #14142, I built a stripped-down version of tor_main which only initialised the data structures required to parse arguments. I did this so that fuzzing would operate at a reasonable speed.

There's also llvm's coverage-guided in-process fuzzing using libFuzzer. It promises to be several orders of magnitude faster than afl-fuzz for small data inputs, as long as the program doesn't maintain (much) state between runs.

However, most of libFuzzer only works on Linux at the moment, so I'd need to set up a VM or VPS on my end for that.
http://blog.llvm.org/2015/04/fuzz-all-clangs.html

comment:3 Changed 4 years ago by teor

And the reference for LibFuzzer being Linux-only is:
http://clang-developers.42468.n3.nabble.com/Build-issues-when-trying-to-use-LibFuzzer-on-Mac-OS-X-td4045832.html

afl-fuzz isn't great on OS X either, because OS X's fork is slow. And the CrashReporter slows it down as well. Maybe I should just get a cheap linux box/vm/vps...
https://www.mikeash.com/pyblog/friday-qa-2015-05-01-fuzzing-with-afl-fuzz.html

comment:4 Changed 4 years ago by teor

Aim to produce:

  • a harness that reads and parses a single file
  • a list of known tokens

For each of:

  • command-line arguments
  • directory requests
  • directory replies
  • HS subsystem
  • (HS) cell parsing
  • HSDir/client cache

Without specific AFL dependencies (or conditionalised), as a lot of fuzzers work with files, not function calls or network calls.

[14:15] <teor_> asn, dgoulet: I have plans to work towards fuzzing some parts of tor over the next week or two
[14:15] <teor_> do you have a priority area?
[14:16] <asn> teor_: great, keep me in the loop.
[14:16] <dgoulet> interesting
[14:16] <asn> i have done a bit of previous work
[14:16] <teor_> I have already done torrc options and found one bug
[14:16] <asn> teor_: nice
[14:16] <nickm> if you find any horrible security bugs, please send them gpg-encrypted. :)
[14:16] <dgoulet> teor_: I would say the HS subsystem but I'm bias :P
[14:16] <asn> ehm
[14:16] <asn> HS cell parsing would be nice
[14:16] <asn> and general cell parsing
[14:16] <teor_> And looked at the directory requests, but never actually got to fuzzing them
[14:16] <asn> then i guess directory documents  
[14:17] <dgoulet> pushing the HSDir/client cache to the limit
[14:17] <asn> like microdescriptors
[14:18] <asn> teor_: i used to do fuzzing with radamsa like this: https://gitorious.org/mytor/mytor/commit/6acef044580057b7496ed4eb67861656a5ca84a6
[14:19] <asn> teor_: super hacky way, i just basically overrode the --verify-config switch
[14:19] <asn> teor_: but exposing the parsing functions like this and fuzzing them , i think might be a reasonabe approach
[14:19] <asn> or maybe through the control port. depending on how it's easier for afl.
[14:19] <dgoulet> if that fuzzing can be integrated in some part of the test suite, that would be epic imo

comment:5 Changed 4 years ago by teor

There's a very early draft in my branch: feature16301-fuzz-draft
on: https://github.com/teor2345/tor.git

It isn't very useful right now, as it only fuzzes torrc parsing.
And I haven't tested it on Linux yet.
(But that's why I uploaded it to GitHub, so I could merge it on my Linux box.)

comment:6 Changed 4 years ago by teor

Hmm, and it has a lot of testcase files in it. Maybe we'll want to cut those down. A lot.

comment:7 Changed 4 years ago by teor

This breaks the link-handshake/authenticate/cell test on OS X, and the crypto/ed25519_simple test on Linux (due to tor_memeq).

comment:8 Changed 3 years ago by teor

Priority: MediumLow
Severity: Normal
Status: newneeds_revision
Summary: Add afl-fuzz instructions to contribAdd a fuzzing harness for the torrc file

Now we have fuzzing instructions merged into tor, we could rewrite this code to use the libfuzzer/AFL combined interfaces.

comment:9 Changed 2 years ago by nickm

Milestone: Tor: very long termTor: 0.3.2.x-final

It seems we could so some parts of this with our harness, though if we want an "integration test" style of thing here, we'll need to make it afl-only, since trying to do a whole bunch of torrc responses in one process will fail. Maybe we could go over all of "options_validate" though, since in theory that's not supposed to change state?

comment:10 Changed 2 years ago by nickm

Milestone: Tor: 0.3.2.x-finalTor: unspecified

Mark some needs_revision tickets as unspecified. If/when the revisions happen, they can go back into a live milestone.

comment:11 Changed 23 months ago by teor

Owner: teor deleted
Status: needs_revisionassigned

Disowning tickets I don't intend to work on in the next 6 months.

comment:12 Changed 23 months ago by teor

Status: assignednew

Mark all tickets that are assigned to nobody as "new".

Note: See TracTickets for help on using tickets.