Opened 2 years ago

Last modified 2 years ago

#24154 new task

Look into fuzzing our tor-browser patches

Reported by: gk Owned by: tbb-team
Priority: Medium Milestone:
Component: Applications/Tor Browser Version:
Severity: Normal Keywords: TorBrowserTeam201711, GeorgKoppen201711
Cc: boklm, arthuredelstein Actual Points:
Parent ID: Points:
Reviewer: Sponsor: Sponsor4

Description

As part of Sponsor4 and our switch to have specific debug builds which allow us to detect bugs earlier we should look into fuzzing our browser patches.

Mozilla already does fuzzing and we might learn something from them. Also, some of the things mentioned in https://blog.mozilla.org/security/2012/06/20/7-tips-for-fuzzing-firefox-more-effectively/ might be a good starting point, too.

Child Tickets

TicketStatusOwnerSummaryComponent
#24478closedtbb-teamEnable tests and debug assertions in our ASan buildsApplications/Tor Browser

Change History (5)

comment:1 Changed 2 years ago by gk

comment:2 Changed 2 years ago by gk

Keywords: GeorgKoppen201711 added

comment:3 Changed 2 years ago by gk

To sum up on where we are with this:

To get started with fuzzing the Firefox codebase it seems worth trying to get our own patches under scrutiny first. Firefox itself is regularly fuzzed by an own, specialized team targeting different components (like the JS engines).

As we don't have any JS engine patches ourselves there is no need for looking for a specialized tool in that area. Instead I started to look into domfuzz (https://github.com/MozillaSecurity/domfuzz) while glancing over domato (https://github.com/google/domato) which we might deploy later on.

I got domfuzz running locally and started fuzzing our code using ASan builds (see: #21998 and #24478). There are some challenges we might want to consider, though, to make this a smoother and more successful experience:

1) We are using ESR 52 and git and the fuzzing code is expecting mozilla-central and a mercurial repo. We can work around that but might benefit from the idea to at least rebase our patches to mozilla-central regularly (see: https://lists.torproject.org/pipermail/tbb-dev/2017-November/000669.html) and use that. That might as help with the plan to discover issues in the Firefox codebase itself.

2) Doing fuzzing on local computer does not scale and does not give good results. Thus, we need to get dedicated machines for that thinking about budget etc. I asked Mozilla if we could share resources somehow but they declined for good reasons. But they are willing to help us to duplicate their infrastructure or at least to get their tools running for us.

3) There is currently no process established to get the feedback from the fuzzing efforts back into the development cycle (like ticket creation, ticket assignments and working on them).

comment:4 Changed 2 years ago by gk

Priority: Very HighMedium

comment:5 Changed 2 years ago by toralf

I do fuzz tests the Tor git tree using the AFL and [1]. I got for enarly every fuzz test warnings like these :

torproject@mr-fox ~/done $ grep -h WARNING */fuzz.log | sort -u
[!] WARNING: No new instrumentation output, test case may be useless.
[!] WARNING: Some test cases are huge (277 kB) - see /usr/share/doc/afl-2.52b/perf_tips.txt!
[!] WARNING: Some test cases are huge (316 kB) - see /usr/share/doc/afl-2.52b/perf_tips.txt!
[!] WARNING: Some test cases are huge (79.9 kB) - see /usr/share/doc/afl-2.52b/perf_tips.txt!
[!] WARNING: Some test cases look useless. Consider using a smaller set.
[!] WARNING: You probably have far too many input files! Consider trimming down.
[!] WARNING: Not binding to a CPU core (AFL_NO_AFFINITY set).

Maybe the fuzz_corpora directory needs an update ?

[1] https://github.com/toralf/torutils/blob/master/fuzz.sh

Last edited 2 years ago by toralf (previous) (diff)
Note: See TracTickets for help on using tickets.