[tbb-bugs] #12418 [Applications/Tor Browser]: TBBs with UBSan create lots of errors when running
Tor Bug Tracker & Wiki
blackhole at torproject.org
Wed Jul 12 16:13:36 UTC 2017
#12418: TBBs with UBSan create lots of errors when running
Reporter: gk | Owner: tbb-team
Type: defect | Status: assigned
Priority: Medium | Milestone:
Component: Applications/Tor Browser | Version:
Severity: Normal | Resolution:
Keywords: tbb-security, tbb-hardened | Actual Points:
Parent ID: | Points:
Reviewer: | Sponsor:
Comment (by tom):
Replying to [comment:12 cypherpunks]:
> Replying to [comment:11 tom]:
> > The conclusion was that some tests are valuable and should be used
(bounds, pointer-overflow, vptr although this requires RTTI).
> > But that others (signed and unsigned overflow) caused a gratuitous
amount of false positives (largely in the graphics and layout areas but in
general all over the place) and it's infeasible to whitelist them all. We
had someone spend a month on this and using his whitelist we brought the
number of reports down from the hundred of thousands down to the mere
thousands - but even then it was with a ton of effort and had a ton of
effort to go.
> Unfortunately, those are some of the most important types of UB that
must be prevented. An alternative (mutually exclusive due to
incompatibilities with internal symbol names, or something of that sort),
if suitable manpower is present, is to instrument important parts of FF
with the PaX Size Overflow plugin (see
https://forums.grsecurity.net/viewtopic.php?f=7&t=3043). It provides
better protection than UBSAN for this specific issue.
Hmmmmm. I don't know I will have to investigate.
> > So I think the path forward is to turn on UBSAN on the whole browser,
run it through something like the web platform tests or Mozilla's usual
unit tests, and slowly increase the number of UBSAN tests one by one. When
we hit one that causes too many false positives, we turn it back off and
investigate turning it on for an individual component (like image
> I had assumed that the amount of UB would be so great that it would be
infeasible to do this in any reasonable amount of time. I still feel like
instrumenting individual components of the browser would be easier.
What do you mean by "amount of UBSAN"? There are some checks that should
have basically no false-positives (like pointer overflow) - those should
be feasible for whole-browser I think.
Instrumenting components with more verbose tests (like int overflows) is
definitely valuable though!
Mind you, Mozilla's not going to ship Firefox with UBSAN enabled, we'll
just run tests with it to catch issues. Maybe Tor would ship something
with UBSAN (??) but maybe not since I don't think you can enable both ASAN
> > Also I would suggest the path forward for this is in Mozilla's court,
rather than Tor's. Not that Tor has to wait for Mozilla, only that making
use of Mozilla's infrastructure will make it considerably easier. Tor devs
have access to that, and if any cypherpunks want access, I think the only
thing needed is a few contributions* that I can point to and say "This
person is doing good work, let's give them access to run their tests on
our task runner".
> I tend to avoid Mozilla's ticket system due to their excessively
bureaucratic nature, and their tendency to put security as a low priority.
All my Firefox-related contributions have been made here (though
admittedly I have made more contributions for Tor itself, and relatively
few for Firefox).
Well, It's a big org, we're not all bad ;) But I hear you loud and clear.
My main point was not "Try and get Mozilla to take your patches" but
rather "You can almost certainly make use of Mozilla's infrastructure to
do experimental runs and examine the output." For example, you could
queue up 10 jobs that turn on UBSAN for 10 individual components, and run
them all at once.
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/12418#comment:13>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online
More information about the tbb-bugs