richard authored Mar 01, 2018 and Georg Koppen committed Mar 08, 2018

Ported over firefox patch c2db4a50dc5c (Bug 1432966)

richard authored Mar 06, 2018 and Georg Koppen committed Mar 08, 2018

With sandboxing enabled on Vista, 32-bit Firefox uses another 64-bit
process (wow_helper.exe) to patch functions in the loaded ntdll.dll
in the child content process.  However, we are not building
wow_helper.exe and it is not present, so the content process
creation method silently fails.

We 'could' go in and properly update the build system to build
wow_helper.exe with 64-bit mingw.  However, Vista support is going
away very soon for Tor Browser once we update to a newer Firefox ESR.
Therefore, the more prudent fix is to simply disable sandboxing when
running on Vista or lower in this WOW64 scenario, rather than to do
the work to get wow_helper.exe building only to have to rip it all
out in a few months when we rebase with latest Firefox ESR.  This
logic is ifdef'd out for 64-bit builds.

Verified the Tor Browser works as expected in following scenarios:
  32-bit Firefox on 32-bit Windows Vista -> Sandbox enabled
  32-bit Firefox on 64-bit Windows Vista -> Sandbox disabled
  32-bit Firefox on 64-bit Windows 7 -> Sandbox enabled

Kris Maglione authored Jun 06, 2017 and Georg Koppen committed Mar 01, 2018

The first time any other code in the parent process uses NSPR (usually via
nsIProcess) to spawn a new process, it spawns a thread to contuously wait for
any child process to exit. This thread winds up reaping our child processes
before we get the chance to wait for them, which leads us to continuously poll
for them to exit.

We don't have a good way to handle this, but checking the error status of
waitpid at least prevents us from failing catastrophically.

MozReview-Commit-ID: 75Z1yUHUmjy

--HG--
extra : rebase_source : db45f781190b6fc84873c32c611134326736a1ba

This closes our bug 25389.

This reverts commit dcd2db03.

We don't need this patch anymore as we are relying on IndexedDB being
disabled in Private Browsing Mode (PBM) and properly isolated in non-PBM.

richard authored Feb 01, 2018 and Georg Koppen committed Feb 19, 2018

The initialization path for the SOCKS proxy in firefox involves creating
a generic AF_INET socket, and then replacing it if the actual
configuration requires something else (either AF_INET6 or AF_LOCAL).
With syscall filtering configured to return an error in the event of
AF_INET or AF_INET6 socket creation, this initialization path fails.  We
would like this capability so that we can prevent firefox from making
network requests outside of the Tor proxy.

This patch adds a check in the initial socket creation path to see if
the SOCKS proxy host begins with file:// with the assumption that such
URIs point to a UNIX Domain Socket (on Linux+macOS only).  In that case,
we create an AF_LOCAL socket rather than the requested type.  A similar
check for Windows already exists to determine if the proxy is actually a
named pipe.

In the subsequent replacing step no work occurs as the passed in socket
matches the type we need, so no changes need to be made there.

NOTE: With this change there is still a one-time request for an AF_INET6
socket that occurs.  This code path exists to determine whether the
system supports IPv6; if socket(AF_INET6...) fails then it is assumed
that the system does not.  However, this check only affects code that is
unreachable when using AF_LOCAL sockets so it seems safe to leave as it is.
However, this does mean that Tor Browser will still be incompatible with
seccomp policies which kill the calling thread in the event of a
socket(AF_INET6,...) call.

Kathleen Brade authored Feb 14, 2018 and Georg Koppen committed Feb 19, 2018

This has been shown to cause problems with STARTTLS in XMPP (used
in Tor Messenger) and with Tor Launcher's Moat client. A replacement
will be added to the Tor daemon itself via bug 5915 (Write patch to
make socks handshakes succeed instantly).

ffmancera authored Feb 02, 2018 and Georg Koppen committed Feb 19, 2018

e10s in its current form probably brings some fingerprinting risks with it.
E.g. users of accessibility tools (not only those users) won't have e10s
enabled on windows and macOS. In order to solve this issue
"dom.disable_window_showModalDialog" is set to "true".

Zibi Braniecki authored Apr 18, 2017 and Georg Koppen committed Feb 19, 2018

StringBundle caches bundles, so when language chain changes we should
flush the cache to enable new strings to be loaded.
This also affects localized prefs like intl.accept_languages.

Then in HttpHandler we have to mark the value as dirty so that next
time it's called it actually recalculates using flushed string bundle
with the new locale.

MozReview-Commit-ID: DKWEDUli4yH

--HG--
extra : rebase_source : 75ecc4204deca066d7492d1494492a91685f36be

This fixes bug 22659 on our side.

ffmancera authored Jan 20, 2018 and Georg Koppen committed Feb 02, 2018

Mozilla's experiment shouldn't be collecting any data on our users. If
"browser.cache.frecency_experiment" is not set in firefox.js to "-1" it will
default to "0" and then it is randomised between "1" and "4" inclusive, setting
different HTTP cache decay times for the four groups.

We make the certificate for the secondary key the new primary one, and
add the certificate for the new key as the secondary one.

This is the 2018 MAR signing key update.

Kaku Kuo authored Sep 28, 2017 and Georg Koppen committed Jan 19, 2018

MozReview-Commit-ID: 8RTe7lVSRwl

--HG--
extra : rebase_source : 5e67fae9fa287c4188402d8956d90e4ce47e1f32

Fernando Fernandez Mancera authored Jan 06, 2018 and Georg Koppen committed Jan 19, 2018

On systems where H.264 is not available or no HWA, VP9 is preferred. But in Tor
Browser 7.0 all youtube videos are degraded to VP8.

This behaviour can be turned off by setting media.benchmark.vp9.threshold to 0.
All clients will get better experience and lower traffic, beause TBB doesn't
use "Use hardware acceleration when available".

davidben authored Jan 21, 2016 and Georg Koppen committed Jan 19, 2018

This is a reland of https://codereview.chromium.org/1502373009 with some fixes
for components/metrics/leak_detector allocator type mismatches.

Original issue's description:
> Allow std::unordered_*.
>
> base::hash_* is, as a transition step, implemented in terms of
> std::unordered_*. Later commits will convert existing uses.
>
> Also fix a host of IWYU problems that arose from this CL.
>
> (NOPRESUBMIT because the wstring presubmit check is overzealous
> and complains about the reference to wstring in the comment.)
>
> Committed: https://crrev.com/3f37f7f1459e7b5a452c0e433493e0a6e9649ca7
> Cr-Commit-Position: refs/heads/master@{#370553}

BUG=576864
TBR=derat@chromium.org,danakj@chromium.org,dalecurtis@chromium.org,jbauman@chromium.org,blundell@chromium.org
NOPRESUBMIT=true
CQ_INCLUDE_TRYBOTS=tryserver.blink:linux_blink_rel

Review URL: https://codereview.chromium.org/1615713003

Cr-Commit-Position: refs/heads/master@{#370867}

richard authored Nov 27, 2017 and Georg Koppen committed Jan 19, 2018

Ported over firefox patch 997c6b961cd0 (Bug 1329835)

richard authored Nov 27, 2017 and Georg Koppen committed Jan 19, 2018

Ported over firefox patch 5e7872cb3b5c (Bug 1364627)

richard authored Nov 27, 2017 and Georg Koppen committed Jan 19, 2018

Ported over firefox patch 5b9702d8fe4e (Bug 1309205 Part 3)

richard authored Nov 27, 2017 and Georg Koppen committed Jan 19, 2018

Ported over firefox patch 2797f193a147 (Bug 1309205 Part 2)

richard authored Nov 27, 2017 and Georg Koppen committed Jan 19, 2018

Ported over firefox patch 5c25a123203a (Bug 1309205 Part 1)

richard authored Nov 15, 2017 and Georg Koppen committed Jan 19, 2018

The Problem:

During firefox and Web Content process startup,
::OverrideDefaultLocaleIfNeeded() is called which will conditionally
::setlocale() to "C.UTF-8" or "C" based off of the
javascript.use_us_english_locale preference (to prevent fingerprinting
based on how dates and what-not are formatted).  Sometime after this
call in the Web Content process the locale is set to the system's locale
which effectively stomps over the work done by the
::OverrideDefaultLocaleIfNeeded() call.  As a result, the firefox
process and the Web Content process are configured to use different
locales; firefox uses "C.UTF-8" while Web Content uses "" (system
default).

On Linux, the "Print to File" printer is a default GTK printer whose
name is localized based off of the process's locale.  The GTK print dialog
is hosted in the firefox process and therefore the printer name will be
'Print to File.'  This process sends this name over to the Web Content
process, which iterates over the list of printers and finds one whose
name matches.  However, as the Web Content process's locale is set to
system, its printer names will be localized and in the language of the
system, so no printer with the name 'Print to File' will be found, and
printing fails.

This is why disabling javascript.use_us_english_locale fixes the issue.
It also explains why disabling multi-process mode via the
browser.tabs.remote.autostart.2 preference fixes the issue; one
process means the printer-name is never used as a selector and also
means no mismatched locale can happen.

The Solution:

The fix for this issue is to first check the
javascript.use_us_english_locale preference each place in code where
setlocale occurs, particularly in the nsLocaleService object which is the
particular code path which overrides setlocale in the Web Content
process.

Tim Huang authored Dec 13, 2017 and Georg Koppen committed Jan 19, 2018

Bug 1372072 - Part 2: Add a test case for check whether network information API has been spoofed correctly when 'privacy.resistFingerprinting' is true. r=arthuredelstein,baku

This adds a test case to test that network information is correctly spoofed when
'privacy.resistFingerprinting' is true.

Firefox ESR 52 does not have the navigation object inside workers. Thus, the
worker test was removed.

MozReview-Commit-ID: Lt6HZlFrcja

--HG--
extra : rebase_source : 70d44115532549814af9fce3af9fe379e36bca80

Tim Huang authored Dec 13, 2017 and Georg Koppen committed Jan 19, 2018

Bug 1372072 - Part 1: Spoofing network information API and blocking ontypechange event when 'privacy.resistFingerprinting' is true. r=arthuredelstein,baku

This patch makes the network information API always returns the default type 'unknown'
and blocking the ontypechange event while connection type changed when 'privacy.
resistFingerprinting' is true.

MozReview-Commit-ID: 4eOdHgAGtyY

--HG--
extra : rebase_source : 78449fb4888b787062ff2139e36c219e0eac0b2c

The plugin-container process can thrash/crash due to increasing memory
consumption after our workaround for bug 24052. The patch provided by a
cypherpunk (bug thanks!) deals with that as far as the Developer Tools
are concerned.

Igor Oliveira authored Dec 10, 2017 and Georg Koppen committed Jan 19, 2018

Many fonts have issues with their vertical metrics. they
are used to influence the height of ascenders and depth
of descenders. Gecko uses it to calculate the line height
(font height + ascender + descender), however because of
that idiosyncratic behavior across multiple operating
systems, it can be used to identify the user's OS.

The solution proposed in the patch uses a default factor
to be multiplied with the font size, simulating the concept
of ascender and descender. This way all operating
systems will have the same line height only and only if the
frame is outside the chrome.

ASan and FORTIFY_SOURCE are not compatible with each other right now. Thus,
we make sure that we have FORTIFY_SOURCE disabled in case the sanitizer is used.
See #21925 for more details.

Arthur Edelstein authored Nov 01, 2017 and Georg Koppen committed Jan 19, 2018

This is the second part of the workaround for
https://bugzilla.mozilla.org/show_bug.cgi?id=1412081.

We should make sure restrictions regarding loading of file:// resources
are adhered to more strictly, at least on *nix platforms.

This is a workaround for
https://bugzilla.mozilla.org/show_bug.cgi?id=1412081.

boklm authored Oct 16, 2017 and Georg Koppen committed Jan 19, 2018

Bug 1305396 - Replace memmove with std::copy_backward in a file that doesn't include cstring explicitly. r=keeler

Arthur Edelstein authored Oct 17, 2017 and Georg Koppen committed Jan 19, 2018

This reverts commit 31348e47.

This reverts commit 722fd293.

Backing out due to #23701: We should make sure this defense only applies
to content and not the browser chrome.

richard authored Sep 29, 2017 and Georg Koppen committed Jan 19, 2018

ifdef'd out offending code in each platform based on existance of
TOR_BROWSER_VERSION and return empty string instead.

Kiril Vladimiroff authored Sep 05, 2017 and Georg Koppen committed Jan 19, 2018

MozReview-Commit-ID: FXniFjoU9RJ

--HG--
extra : rebase_source : 6fb36272b7779c52854e7e952725e528b7c9346a

igt0 authored Sep 16, 2017 and Georg Koppen committed Jan 19, 2018

Many fonts have issues with their vertical metrics. they
are used to influence the height of ascenders and depth
of descenders. Gecko uses it to calculate the line height
(font height + ascender + descender), however because of
that idiosyncratic behavior across multiple operating
systems, it can be used to identify the user's OS.

The solution proposed in the patch uses a default factor
to be multiplied with the font size, simulating the concept
of ascender and descender. This way all operating
systems will have the same line height.

Jed Davis authored Aug 08, 2017 and Georg Koppen committed Jan 19, 2018

1. X_OK is now allowed, and is limited only by the MAY_ACCESS permission.

2. The actual access() syscall is now used, if access is granted by the
broker policy.  This fixed bug 1382246, which explains the background.

MozReview-Commit-ID: 926429PlBnL

--HG--
extra : rebase_source : 6ae54c4c25e1389fa3af75b0bdf727323448294a

Gian-Carlo Pascutto authored Jun 19, 2017 and Georg Koppen committed Jan 19, 2018

MozReview-Commit-ID: Ko5m5i4Wkd6

--HG--
extra : rebase_source : 3076315ef3639a89f752addbb01d5d08a9c2db75

Haik Aftandilian authored Mar 03, 2017 and Georg Koppen committed Jan 19, 2018

MozReview-Commit-ID: 9tI2S6fEYkD

--HG--
extra : rebase_source : 0a5d00f8498861e7ea281e527b2be6b2c4e472d6