Before this patch, nsNSSComponent initialization would call PK11_ConfigurePKCS11
with some localized strings, which contributed to startup time. Also,
PK11_UnconfigurePKCS11 was never called, so the memory allocated to these
strings would stick around forever. This patch addresses both of these problems
by not calling PK11_ConfigurePKCS11. This means that some properties of NSS'
internal "PKCS#11 slots/tokens" have to be localized when displaying them to the
user.
MozReview-Commit-ID: BbAgbgpFfFG
--HG--
extra : rebase_source : b633da8fea683675d0c0514a378954332afeb024
There is one actual behavior change here, in the webidl version of
TreeBoxObject::GetCellAt. I believe this change fixes a leak of the
nsTreeColumn, but could use careful review.
I tried to avoid changes not needed to get this compiling. There will be a lot
more cleanup in the next few changesets.
Same approach as the other bug, mostly replacing automatically by removing
'using mozilla::Forward;' and then:
s/mozilla::Forward/std::forward/
s/Forward</std::forward</
The only file that required manual fixup was TestTreeTraversal.cpp, which had
a class called TestNodeForward with template parameters :)
MozReview-Commit-ID: A88qFG5AccP
This was done automatically replacing:
s/mozilla::Move/std::move/
s/ Move(/ std::move(/
s/(Move(/(std::move(/
Removing the 'using mozilla::Move;' lines.
And then with a few manual fixups, see the bug for the split series..
MozReview-Commit-ID: Jxze3adipUh
Also removes displayUnknownCertErrorAlert, which was declared but never used.
Also removes some unnecessary ns(I)CertOverrideService OID stuff.
MozReview-Commit-ID: 4o7c1TkKeKJ
--HG--
extra : rebase_source : a8069b76fc847e6b4d158e4b30a75bde3e290ed9
Before this patch, we exposed a few interfaces that revolved around mapping a
name to a specific PKCS#11 module, slot, or token. These APIs were all either
problematic and/or unnecessary. In theory there could be two tokens in different
modules with the same name, so nsIPK11TokenDB.findTokenByName wasn't guaranteed
to return what the consumer expected it to. In general, these APIs were used by
front-end code to go from a handle on the specific object in question to a
string identifier and then back to a handle on the object. This was unnecessary
- we can just retain the original handle.
MozReview-Commit-ID: IbqLbV4wceA
--HG--
extra : rebase_source : 05d39afd6bed0aa5e7694e1c79baf836edc03214
The patch for bug 1456489 included a workaround for the issue that origin
attributes weren't honored on channels that didn't have a load group set (bug
1456742). Now that that's fixed, we don't need the workaround.
MozReview-Commit-ID: I4ExIqt6dYo
--HG--
extra : rebase_source : d323c0860989985b72933dcffd62743b9d73644d
nsNSSComponent::PIPBundleFormatStringFromName and ::GetNSSBundleString are now
unused. They can be removed (which means that nsNSSComponent::mNSSErrorsBundle
can be removed as well).
MozReview-Commit-ID: GAaGawSDL2n
--HG--
extra : rebase_source : 3f683a902e292c6b0cf736773e71fb893074c32b
nsNSSComponent startup and shutdown would be simpler if there were no direct
dependencies on localized strings. This patch removes a dependency on the
localized name of the builtin roots module by hard-coding the name internally
and then mapping it to/from the localized version as appropriate.
MozReview-Commit-ID: 30kbpWFYbzm
--HG--
extra : rebase_source : 3d384af5a9fa45d5ac1f78e1fcb0dd9e4b94267d
Add font servers to sandbox policies instead of relying
on them to be registered before the sandbox is enabled.
MozReview-Commit-ID: IoVJhAqoEEW
--HG--
extra : rebase_source : 448cc9e556056c44cf76f79c126fbfe56e948e1e
Before this patch, if nsNSSComponent initialization failed after allocating the
XPCOM object for the component but before dispatching the load loadable roots
task, BlockUntilLoadableRootsLoaded would block indefinitely in ShutdownNSS
(called from ~nsNSSComponent).
This patch re-arranges some things so that nsNSSComponent cleanup won't block on
the load loadable roots task if it never fired. It also splits the cleanup into
idempotent operations and operations that can only be run once.
Unfortunately if nsNSSComponent initialization fails, Firefox is likely to exit
or fail promptly anyway (since it is essential to so many other components).
However, quitting outright is probably a better experience than hanging
indefinitely.
MozReview-Commit-ID: RWmBUV2pEU
--HG--
extra : rebase_source : e2d06178ecc8ca8681eef18cb3af0a9ac8f83d1c
Adds a test to validate that content sandboxing is allowing content
processes to access fonts from non-standard locations on the
filesystem. The test copies the Fira Sans font to the root of the
home directory and renders a page that should use Fira Sans when it
is installed and registered with the OS. The test checks for the use
of the ".LastResort" font which is an indication of the the content
process failing to load the font.
MozReview-Commit-ID: GPWqHdF3vhG
--HG--
extra : rebase_source : c0ea283d496517812202d068c610bdcc0ece640d
In debug builds, we assert if any UTF8-to-UTF16 conversion fails. If we have
invalid UTF8 in a certificate, we don't want to assert. So, we now lossily
convert invalid UTF8 in certificates for any display purposes.
This also handles fields that are supposed to be ASCII in a similar way.
MozReview-Commit-ID: 6TdVPDTmNlh
--HG--
extra : rebase_source : 17000bd0671551bbdae534a4eaf4946c1b0beb83
When doing TLS session resumption, Firefox currently does not have enough
information to trivially reconstitute the original connection's security
information. Consequently, we have to rebuild the certificate chain in the
handshake callback. Before this patch, we determined the EV and CT status of the
connection but did not set the succeeded cert chain unless the certificate was
EV. This was insufficient. In this patch, we set the succeeded cert chain
regardless of if the certificate is EV or not (provided we found a valid chain).
MozReview-Commit-ID: AuKrlBwX1Qh
--HG--
extra : rebase_source : cafb17548666f6330038012e36fa23ef382f361a
At this point, all uses of GetPIPNSSBundleString *should* be on the main thread,
so we can just remove the nsINSSComponent version and rely on the
nsNSSCertHelper instance.
MozReview-Commit-ID: Lt7AgokGKRH
--HG--
extra : rebase_source : 95d3cf6e011468e2aa9df9bb69372ac4d3430286
Add back font whitelist rules removed by the fix for bug 1393259
to workaround font sandbox extensions not being issued automatically
on OS X 10.11 and earlier.
MozReview-Commit-ID: 2hT0BzN3Ggq
--HG--
extra : rebase_source : 4fe9ce43eb7efe0c6a91c908c149126da6eb708e
Summary:
Change the security.pki.name_matching_mode pref to 3 for Enforce on Nightly.
BR_9_2_1_SUBJECT_ALT_NAMES show that ~99.98% of encountered certificates have
an acceptable SAN, so our compatibility risk is about 0.02%.
BR_9_2_2_SUBJECT_COMMON_NAME also shows, 99.89% of certificate common names are
present in a subject alternative name extension, giving a worst-case of 0.11%
risk, though BR_9_2_1_SUBJECT_ALT_NAMES is more what we're affecting here.
Test Plan: none
Reviewers: keeler
Tags: #secure-revision
Bug #: 1461373
Differential Revision: https://phabricator.services.mozilla.com/D1277
--HG--
extra : transplant_source : %BF%7D%DEi%C7%9BhE%D0%C2d%9D0%AC%F8%9EM%E0%60U
Don't use MOZ_MAKE_ENUM_CLASS_BITWISE_OPERATORS; it's unneeded here right now,
and occludes "PSM::Result" on Windows.
--HG--
extra : transplant_source : %B9%24%7FR%A8%1B%B0%3B%D44%ED%C5%3F%CD%1E%96%1F%22m%A3
Per Bug 1437754 comment 10, the pref security.pki.distrust_ca_policy makes more
sense as a bitmask than a state. To permit future nuance, let's go ahead and do
that before people start implementing atop Bug 1456112.
This does permit both 0b10 and 0b11 to enable the functionality for Firefox 63.
--HG--
extra : transplant_source : %84%AF%89%E0%89dT%01%10%84%A0%3B%A5%28%2A%D3%E1%B0%0D%E7
If a user has set a master password on their NSS DB(s), when we try to change
the trust of a certificate, we may have to authenticate to the DB. This involves
bringing up a dialog box, executing javascript, spinning the event loop, etc.
In some cases (particularly when antivirus software has injected code into
Firefox), this can cause the nsNSSComponent to be initialized if it hasn't
already been. So, it's a really, really bad idea to attempt to change the trust
of a certificate while we're initializing nsNSSComponent, because this results
in a recursive component dependency and everything breaks. To get around this,
if we need to load 3rd party roots (e.g. enterprise roots or the family safety
root), we defer any trust changes to a later event loop tick. In theory this
could cause verification failures early in startup. We'll have to see if this
is an issue in practice.
MozReview-Commit-ID: FvjHP5dTmpP
--HG--
extra : rebase_source : 73d39788ce39adcbe01c89867061f64d05a3876b
If a user has set a master password on their NSS DB(s), when we try to change
the trust of a certificate, we may have to authenticate to the DB. This involves
bringing up a dialog box, executing javascript, spinning the event loop, etc.
In some cases (particularly when antivirus software has injected code into
Firefox), this can cause the nsNSSComponent to be initialized if it hasn't
already been. So, it's a really, really bad idea to attempt to change the trust
of a certificate while we're initializing nsNSSComponent, because this results
in a recursive component dependency and everything breaks. To get around this,
if we need to load 3rd party roots (e.g. enterprise roots or the family safety
root), we defer any trust changes to a later event loop tick. In theory this
could cause verification failures early in startup. We'll have to see if this
is an issue in practice.
MozReview-Commit-ID: FvjHP5dTmpP
--HG--
extra : rebase_source : ad0fb83a0de3632e3a967e91aec3d8070b22dedc
Summary:
No bug, Automated HPKP preload list update from task XSqPd8faStCdsylVmzvQ6w
No bug, Automated blocklist update from task XSqPd8faStCdsylVmzvQ6w
Reviewers: sfraser, aki
Reviewed By: sfraser
Differential Revision: https://phabricator.services.mozilla.com/D1256
--HG--
extra : rebase_source : 855e19990c75e2613bd311976297fb6513e02b94
Bug 1456489 cleaned up our OCSP request implementation a bit. One simplification
it made was to not cancel the timeout timer. It turns out that if we don't, the
OCSPRequest that constitutes the timeout callback's closure might not be valid
if the request has completed (because the timer doesn't own a strong reference
to it). The fix is simple: cancel the timer when the request completes. Note
that we don't have to do the reverse because necko has a strong reference to the
request.
MozReview-Commit-ID: 2WHFLAcGBAw
--HG--
extra : rebase_source : c4216f6792c1d62cbd046b1b3802226c51fbe8af
(Backed out changeset 6bbf8dc0b86e (which was a backout of changeset 0a5795108e0a))
MozReview-Commit-ID: EZFn7dLBcdh
--HG--
extra : rebase_source : 8fac1e33a7f108a248ecde35779b2c63ce7d9172
Also fixes existing code which fails the rule.
MozReview-Commit-ID: CkLFgsspGMU
--HG--
extra : rebase_source : 86a43837659aa2ad83a87eab53b7aa8d39ccf55b
OCSP requests cannot be performed on the main thread. If we were to wait for a
response from the network, we would be blocking the main thread for an
unnaceptably long time. If we were to spin the event loop while waiting (which
is what we do currently), other parts of the code that assume this will never
happen (which is essentially all of them) can break.
As of bug 867473, no certificate verification happens on the main thread, so no
OCSP requests happen on the main thread. Given this, we can go ahead and
prohibit such requests.
Incidentally, this gives us an opportunity to improve the current OCSP
implementation, which has a few drawbacks (the largest of which is that it's
unclear that its ownership model is implemented correctly).
This also removes OCSP GET support. Due to recent OCSP server implementations
(namely, the ability to cache OCSP POST request responses), OCSP GET is not a
compelling technology to pursue. Furthermore, continued support presents a
maintenance burden.
MozReview-Commit-ID: 4ACDY09nCBA
--HG--
extra : rebase_source : 072564adf1836720e147b8250afca7cebe4dbf62
This adds another preference (DistrustSymantecRootsRegardlessOfDate == 2) that
stops permitting certificates issued after 1 June 2016, and updates the test to
check it.
--HG--
extra : transplant_source : %F1%DE%16m%F2%DD%A8Ei%EF%B4%CAo%BF%8D%A6%A6%5E%D4%89
Bug 1372694 added a firefox-appdir line to PSM's xpcshell.ini. It turns out this
breaks running these tests locally because utilities like BadCertServer can't be
found. I looks like the change isn't necessary, so the simplest thing to do
would be to just remove the addition.
MozReview-Commit-ID: 8fg8ujPWxRe
--HG--
extra : rebase_source : ffef9b067dacb94c4bd554f97556ab95f58efd2b
This also removes any redundant Ci.nsISupports elements in the interface
lists.
This was done using the following script:
acecb401b7/processors/chromeutils-generateQI.jsm
MozReview-Commit-ID: AIx10P8GpZY
--HG--
extra : rebase_source : a29c07530586dc18ba040f19215475ac20fcfb3b
Update Mac sandbox rules to allow executable mappings from /Library/GPUBundles which is
used by the Nvidia downloadable "Web" driver.
MozReview-Commit-ID: L2nTP4YWdJJ
--HG--
extra : rebase_source : d8eefdd5a180db5d3ea8207d923e021420f2318e
(This also fixes Bug 879740 and Bug 1204543.)
build/pgo/certs contains an NSS database set that has a bunch of hand-generated
certificates, and many of these hand-generated certificates are specifically
depended upon for a variety of unit tests. This patch changes all of these to
use the "pycert.py" and "pykey.py" utilities that produce deterministic keys
and certificates.
The naming convention here is new, and defined in the README. It is based on
the mochitest runtest.py naming convention that imports .ca and .client
PEM-encoded certificates.
Unfortunately, the updates to build/pgo/genpgocert.py to generate these files
depends on OpenSSL in order to produce PKCS12 archives for pk11tool to import
into NSS. This could be done with pure-NSS tooling, but it'd require some new
command line functionality, which is out-of-scope for this change.
Note that build/pgo/genpgocert.py no longer takes arguments when run. It's not
run automatically anywhere that I can see, but could (reasonably) be, now.
Differential Revision: https://phabricator.services.mozilla.com/D971
--HG--
extra : amend_source : bc389b9b0a807a4889feb14db439daa28635dfe9
This patch uses the shared memory name prefixes introduced in bug 1447867
to prevent access to /dev/shm files of other applications or other
processes within the same browser instance.
When a shared memory implementation that doesn't use shm_open is available
(specifically, the memfd_create support to be added in bug 1440203),
/dev/shm access is completely denied.
MozReview-Commit-ID: L2ylG5KrXTU
--HG--
extra : rebase_source : ca1deece6117e843d691a13fff05bd0f97ec0408
These functions cause main-thread certificate verifications, which is bad for
performance. In general, nsIX509CertDB.asyncVerifyCertAtTime should be used
instead.
MozReview-Commit-ID: 9nkUDmyFY0k
--HG--
extra : rebase_source : d3e8a02e2d21e5507e71681b88f0360edf64b790
This patch goes through and changes a bunch of places in our tree which mention
this bug to use the new feature, making the methods more strongly typed.
There are probably more places in tree which could be changed, but I didn't try
to find them.
nsIX509CertDB.findCertByEmailAddress performs multiple certificate verifications
on the main thread, which is bad because it blocks the main thread and can cause
nested event loop spinning. Firefox doesn't even use this function. Other
products that use this function will either have to re-implement it locally or
find some other workaround.
MozReview-Commit-ID: HShl0H8cgxs
--HG--
extra : rebase_source : 63ee16b600ca7c2867352ee1ad791eb79b82a77c
These functions perform certificate verification on the main thread, which is
already a bad idea. They can also cause OCSP requests to be made from the main
thread, which will cause nested event loop spinning, which is an even worse
idea. Luckily this really only affects tests.
MozReview-Commit-ID: LqDAgDmlyER
--HG--
extra : rebase_source : c86414db0b6d6e7e83b5e3f371506b773813cdbf
window.sizeToContent() apparently interacts poorly with windows that have a
persisted size (see bug 90276, which is a 5-digit bug that hasn't been touched
in over a decade). As a workaround, don't persist the certificate exception
dialog's size. This means we have to call window.sizeToContent() more often and
unfortunately results in the window growing and shrinking again on Windows, but
at least it will always be the "right size" for its content.
MozReview-Commit-ID: 9UT3X8IEqZg
--HG--
extra : rebase_source : 9d968748bd77328eea4ae11e1ae746de9401fb4d
I'm not adding a patch to security/sandbox/chromium-shim/patches for this,
because we need to get this fixed ASAP, certainly before we take another update.
This patch moves all TLS error string handling to the frontend.
Dev-tools doesn't show the same error code as the page does anymore but only the error code as string.
All logging of these error messages has been removed.
Bug #: 1415279
Differential Revision: https://phabricator.services.mozilla.com/D607
--HG--
extra : rebase_source : 61e2d94cb21ef4c02b81448531609205c85a9707
We're seeing a crash in tests from trying to release the promise in
this runnable from the background thread we create to run this
method. The only way I can see that happening is that the bg thread
loses the race with the main thread to drop its reference to the
runnable, causing it to call the destructor. Rather than calling the
helper that adds a reference to the runnable and then forgets it,
let's just forget it here.
MozReview-Commit-ID: LXpC8Kr2SBb
--HG--
extra : rebase_source : bfed3ed4128c6a3ede6f06feed1f50cb9f30e485
Bug 1441223 added MOZILLA_PKIX_ERROR_ADDITIONAL_POLICY_CONSTRAINT_FAILED to be
emitted when we hit certificates affected by the Symantec distrust.
Since some sites have multiple certificate trust paths possible, sometimes
SEC_ERROR_UNKNOWN_ISSUER is emitted instead of the more specific error.
This patch uses a flag to ensure that the specific error is emitted out of the
Cert Verifier.
--HG--
extra : rebase_source : a961d2e713ae342222d85dff6f83ed3bcaa8006b
Replace the boolean pref "security.sandbox.mac.flash.enabled"
with "dom.ipc.plugins.sandbox-level.flash" to support sandbox
levels and be consistent with the Windows pref name.
Adds filesystem read access to the sandbox using sandbox extensions
granted by the file dialog machinery (level 1).
Add support for level 2 which blocks read access.
Allow the sandbox to be disabled with MOZ_DISABLE_NPAPI_SANDBOX.
MozReview-Commit-ID: 4rfobEoxQpF
--HG--
extra : rebase_source : 05dc54b46063967e959bc3fced21c61e5463de48
Adds additional sysctls that are used by the Flash plugin process and alphabetize the list.
MozReview-Commit-ID: 7CaPtaKe874
--HG--
extra : rebase_source : 909228ef9617029eaf7cb16565751150cd1c7404
Remove access to DARWIN_USER_CACHE_DIR. Limit DARWIN_USER_TEMP_DIR
access to the FlashTmp subdirectory. Remove xattr read access to
~/Library/Caches/ and ~/Library/Preferences.
MozReview-Commit-ID: 9svk0BoxVXs
--HG--
extra : rebase_source : 5ea9c7ecc0189455eceb190fb300170d42d0b890
Replace the boolean pref "security.sandbox.mac.flash.enabled"
with "dom.ipc.plugins.sandbox-level.flash" to support sandbox
levels and be consistent with the Windows pref name.
Adds filesystem read access to the sandbox using sandbox extensions
granted by the file dialog machinery (level 1).
Add support for level 2 which blocks read access.
Allow the sandbox to be disabled with MOZ_DISABLE_NPAPI_SANDBOX.
MozReview-Commit-ID: 4rfobEoxQpF
--HG--
extra : rebase_source : 87f2f00867c4522ae3102abbc44fd05db63c7ec7
Adds additional sysctls that are used by the Flash plugin process and alphabetize the list.
MozReview-Commit-ID: 7CaPtaKe874
--HG--
extra : rebase_source : 078697987ac7fec77c75953035b924422fc93066
Remove access to DARWIN_USER_CACHE_DIR. Limit DARWIN_USER_TEMP_DIR
access to the FlashTmp subdirectory. Remove xattr read access to
~/Library/Caches/ and ~/Library/Preferences.
MozReview-Commit-ID: 9svk0BoxVXs
--HG--
extra : rebase_source : 669c4fa446c9cab6b32cf60091e91eae2d08625f
RenderDoc, a graphics debugging tool, uses a preload library that
creates a listening socket (Internet-domain) early in startup and
accepts connections from the frontend. If it's detected (via env vars),
we allow accept/accept4 (but not socket/bind/listen), and remain in
the parent process's network namespace so that other processes can
connect to the socket.
This doesn't change the sandbox policy if not running under RenderDoc.
MozReview-Commit-ID: 964RW4BFh4u
--HG--
extra : rebase_source : d4a954e68431d84fa2e0edea4171421a948794af
This is to support WebGL with hybrid graphics drivers that connect to
a secondary X server for GL (Primus and VirtualGL), without allowing
access to arbitrary sockets. In addition to local X11 connections,
Primus needs to connect to the Bumblebee daemon (otherwise it will exit
the calling process).
The broker support is limited to AF_UNIX, to non-datagram sockets (see
bug 1066750), and to pathname addresses. Abstract addresses could
theoretically be handled but there isn't currently a compelling reason
to, and the broker very much assumes it's dealing with a C-style string
referring to a filesystem path and not an arbitrary byte sequence
(including NULs).
At a higher level: If the GPU X server is remote then it won't work,
but it won't work anyway because WebGL requires features that aren't
supported by indirect GLX. If the GPU X server is local but the browser
is inside a chroot, it will fail to connect unless /tmp/.X11-unix is
bind-mounted into the chroot; hopefully this use case is not common.
MozReview-Commit-ID: IvI2jYDRZZ2
Factor out the ATI-based driver detection code and use this to set
specific permissions needed by this driver. In passing, unnest some
of the SandboxBroker fallback paths, and make it properly report
the operation in all error paths.
MozReview-Commit-ID: FrRpicj5NF
--HG--
extra : rebase_source : 1410cdddcf1264dc1572f9b9b691f9d08a2061cf
The SandboxLaunchPrepare currently bails out early if it detects a
lack of user namespaces. Hoist the check for drivers needing SysV
IPC up so it's done before that early exit, and the required env
variables get correctly set.
With this we no longer fail with a SIGSYS sandbox error, though
in a debug build we still crash because many assumptions in the
graphics stack get broken when that fails to initialize the driver
for WebGL.
MozReview-Commit-ID: 8n3Hx6VSjTF
--HG--
extra : rebase_source : 99bf2d25a7435b0eb95f186a00cc7723a196be4c