[tbb-bugs] #21448 [Applications/Tor Browser]: Identify what build flags we should be using for security, and use them

Tor Bug Tracker & Wiki blackhole at torproject.org
Tue Feb 21 07:43:58 UTC 2017


#21448: Identify what build flags we should be using for security, and use them
--------------------------------------+--------------------------
 Reporter:  arthuredelstein           |          Owner:  tbb-team
     Type:  defect                    |         Status:  new
 Priority:  Medium                    |      Milestone:
Component:  Applications/Tor Browser  |        Version:
 Severity:  Normal                    |     Resolution:
 Keywords:  tbb-security              |  Actual Points:
Parent ID:                            |         Points:
 Reviewer:                            |        Sponsor:
--------------------------------------+--------------------------

Comment (by arthuredelstein):

 Replying to [comment:7 gk]:
 > Replying to [comment:6 arthuredelstein]:
 > > Here are some security flags I think we can add to the gcc-based
 builds (Linux and mingw). There is heavy overlap with the proposed flags
 in https://bugzilla.mozilla.org/show_bug.cgi?id=620058. (I think we should
 be able to add similar flags to the clang based builds -- I will look into
 that after we settle on flags to add to gcc.)
 > > {{{
 > > -Werror=format
 > > -Werror=format-security
 > > -fstack-protector-strong
 > > --param ssp-buffer-size=4
 > > -pie -fPIE
 > > -D_FORTIFY_SOURCE=2 -O1
 > > -Wl,-z,relro,-z,now
 > > -ftrapv
 > > }}}
 >
 > Uhm. We are doing already most of those things. Have you looked at our
 gitian build scripts?

 Sorry I hadn't found the existing build flags before posting this ticket.
 I discussed with gk what is already in our build scripts.

 * On linux, we have in [https://gitweb.torproject.org/builders/tor-
 browser-bundle.git/tree/gitian/descriptors/linux/gitian-firefox.yml#n50
 gitian/descriptors/linux/gitian-firefox.yml]:
   {{{
   export DEB_BUILD_HARDENING=1
   export DEB_BUILD_HARDENING_STACKPROTECTOR=1
   export DEB_BUILD_HARDENING_FORTIFY=1
   export DEB_BUILD_HARDENING_FORMAT=1
   export DEB_BUILD_HARDENING_PIE=1
 }}}

   Indeed this covers most of the flags I mentioned. I'm not sure about
 `-Wl,-z,relro,-z,now`. gk, do you know how these are covered? boklm
 pointed me to [https://gitweb.torproject.org/boklm/tor-browser-bundle-
 testsuite.git/tree/TBBTestSuite/TestSuite/BrowserBundleTests.pm#n45 a part
 of the Tor Browser test suite] that seems to indicate that full relro is
 applied. Is that correct?

   I think it would be useful also to somehow confirm that we are now using
 -fstack-protector-strong and not -fstack-protector; I will try to
 investigate that.

 * On Windows, we have in [https://gitweb.torproject.org/builders/tor-
 browser-bundle.git/tree/gitian/build-helpers/i686-w64-mingw32-g++ gitian
 /build-helpers/i686-w64-mingw32-g++]:
 {{{
 /home/ubuntu/install/mingw-w64/bin/i686-w64-mingw32-g++ -Wl,--dynamicbase
 -Wl,--nxcompat -Wl,--enable-reloc-section -fstack-protector --param ssp-
 buffer-size=4 -fno-strict-overflow "$@"
 }}}
   I'm not familiar with Windows/mingw build flags, but it looks like we
 could possibly switch to -fstack-protector-strong. Also I wonder if
 -D_FORTIFY_SOURCE=2 and the relro flags make sense.

 * On Mac, we are adding -fPIE to the clang flags in
 [https://gitweb.torproject.org/builders/tor-browser-
 bundle.git/tree/gitian/descriptors/mac/gitian-firefox.yml#n43
 gitian/descriptors/mac/gitian-firefox.yml]. clang largely supports gcc's
 build flags so I think we could probably add most or all of the flags from
 comment:6 to the build. (I tried all of those flags with clang++ while
 building a "hello world" c++ program and confirmed that clang++ at least
 did not complain that any of the flags were unknown.)

 > And I am not so sure we should build with `ftrapv` see
 comment:1:ticket:18310.

 That's interesting. I'm not sure what the right answer is. RCE seems a lot
 worse than DOS, though.

 > > Note I am leaving out more advanced mitigations like -fvtable-
 verify=std for this iteration because getting these to work is likely to
 be complex.
 >
 > That is broken and not working due to Mozilla internals, see:
 https://bugzilla.mozilla.org/show_bug.cgi?id=1046600

 I read in
 [https://www.usenix.org/system/files/conference/usenixsecurity14/sec14
 -paper-tice.pdf Tice et al 2014] that there is a mechanism in the VTV code
 to "whitelist" some parts of the code that would otherwise fail
 verification. I wonder if that feature is deployed in the gcc VTV
 implementation and could be used to get around the problematic vtable
 hacking Nathan Froyd
 [https://bugzilla.mozilla.org/show_bug.cgi?id=1046600#c2 mentions in the
 Mozilla bug]. Similarly, clang's -fsanitize has an option
 to[https://clang.llvm.org/docs/ControlFlowIntegrity.html#forward-edge-cfi-
 for-virtual-calls "blacklist"] certain functions so that they also don't
 fail verification.

 Something else that occurs to me is it would be nice to document our
 hardening flags for each build (hardened, alpha, release) in the Tor
 Browser design document.

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/21448#comment:8>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online


More information about the tbb-bugs mailing list