Play with Intel's MPX for hardened Tor Browser builds

With GCC 5.x support for Intel's MPX is available. We should play with it and see what we could get out of it using Intel's SDE. Useful links:

https://gcc.gnu.org/wiki/Intel%20MPX%20support%20in%20the%20GCC%20compiler https://software.intel.com/en-us/articles/using-intel-mpx-with-the-intel-software-development-emulator https://code.google.com/p/address-sanitizer/wiki/IntelMemoryProtectionExtensions

added TorBrowserTeam201711 component::applications/tor browser owner::tbb-team priority::very high resolution::wontfix severity::normal sponsor::4 status::closed tbb-rbm tbb-security type::task labels

Trac:
Keywords: N/A deleted, tbb-hardening added

Trac:
Keywords: tbb-hardening deleted, tbb-hardened added

I don't want to dissuade anyone from implementing this, but I do want to say to be careful. When MPX is not supported, the instrumentation is obviously still there, so it makes ROP slightly easier by adding more gadgets to the code.

(oops, I didn't mean to edit the severity when making this post)

Trac:
Sponsor: N/A to N/A
Severity: N/A to Normal
Reviewer: N/A to N/A

Trac:
Cc: N/A to arthuredelstein

Trac:
Keywords: tbb-gitian, tbb-hardened deleted, N/A added

Trac:
Sponsor: N/A to Sponsor4
Keywords: N/A deleted, TorBrowserTeam201711 added

Changing prio to reflect sponsor deadline

Trac:
Priority: Medium to Very High

Here's what I have done with MPX so far:

I have been using an MPX-supporting VPS and confirmed with a simple test program that gcc -fcheck-pointer-bounds -mmpx produces a binary that catches heap buffer overflows at runtime. Using CFLAGS and CXXFLAGS in mozconfig, and upgrading to the latest version of the gold linker, I built a big part of Firefox 52 using the same flags.

But I'm currently running into the following error, which occurs only when the -fcheck-pointer-bounds flag is present in CFLAGS: {{{ 2:46.68 ../../../../build/unix/gold/ld: error: /home/arthur/tor-browser/obj-x86_64-pc-linux-gnu/config/external/nspr/pr/pripv6.o: re
quires dynamic R_X86_64_PC32 reloc against '_pr_test_ipv6_socket' which may overflow at runtime; recompile with -fPIC 2:46.68 ../../../../build/unix/gold/ld: error: /home/arthur/tor-browser/obj-x86_64-pc-linux-gnu/config/external/nspr/pr/pratom.o: re
quires dynamic R_X86_64_PC32 reloc against '_PR_x86_64_AtomicAdd' which may overflow at runtime; recompile with -fPIC 2:46.68 ../../../../build/unix/gold/ld: error: read-only segment has dynamic relocations 2:46.68 collect2: error: ld returned 1 exit status 2:46.68 /home/arthur/tor-browser/config/rules.mk:800: recipe for target 'libnspr4.so' failed 2:46.68 make[5]: *** [libnspr4.so] Error 1 2:46.68 make[5]: Leaving directory '/home/arthur/tor-browser/obj-x86_64-pc-linux-gnu/config/external/nspr/pr' 2:46.68 /home/arthur/tor-browser/config/recurse.mk:71: recipe for target 'config/external/nspr/pr/target' failed 2:46.68 make[4]: *** [config/external/nspr/pr/target] Error 2 }}}

I've tried a number of things to fix this error, including adding -fPIC to CFLAGS as well as NSPR_CFLAGS, but so far nothing has succeeded. I plan to continue to try to fix this bug and any remaining errors that turn up in the build, and then it should be possible to implement a patch for tor-browser-build.git.

MPX support has been removed from GCC.

https://www.phoronix.com/scan.php?page=news_item&px=MPX-Removed-From-GCC9

Support for Intel Memory Protection Extensions (MPX) is now pretty much dead on Linux.

As a follow-up to the article in April of GCC looking to remove MPX support from their compiler with Intel no longer maintaining that portion of the code and MPX being deprecated already, today the commit went in deleting all of the MPX support in GCC. 

Trac:
Status: new to closed
Resolution: N/A to wontfix
Keywords: N/A deleted, tbb-rbm added

closed

moved to tpo/applications/tor-browser#16352 (closed)