MozillaFirefox 91 ESR stopped working on banking site
kenyapcomau opened this issue · 16 comments
System is openSUSE Leap 15.3 on x86_64 which uses SUSE Linux Enterprise 15 packages.
Today, the newly updated MozillaFirefox 91 ESR package won't work on a banking site that previously did. Display keeps spinning its wheels and console shows:
Check for system-wide FIPS mode is required and /proc/sys/crypto/fips_enabled cannot be opened for reading - aborting
Redirecting call to abort() to mozalloc_abort
A search found this patch which is how I got here. I assume that this is the problem and that fixed packages will be released soon? Working around by using a different browser for now.
https://github.com/openSUSE/firefox-maintenance/blob/master/mozilla-sandbox-fips.patch
Edit: Just to add that I suspect this problem is impacting performance as it seems to slow down access to many other sites.
Hm, have you updated mozilla-nss as well?
And does this fail only for this specific website?
When I updated MozillaFirefox, it did not pull in any updates to mozilla-nss and asking to update that says no newer version is available. Here are the versions I have:
MozillaFirefox-91.2.0-8.54.1.x86_64
mozilla-nss-3.68-3.56.1.x86_64
mozilla-nss-certs-3.68-3.56.1.x86_64
It also gives the same message on another site, a credit card site, and I cannot sign into that site too.
So, NSS is trying to open /proc/sys/crypto/fips_enabled, but apparently fails to do so.
Could you try to do cat /proc/sys/crypto/fips_enabled in the commandline?
$ cat /proc/sys/crypto/fips_enabled
0
is this banking website requiring anything besides https ? e.g. crypto keys or similar from within firefox?
No, they are just normal HTTPS pages. In the case of the credit card site I don't even get the login form. Requesting the login form is sufficient to trigger that message on the Firefox console.
would it be possible to share the site url? (of any that triggers it)?
and just to be sure, are any https sites working? e.g. https://github.com or www.suse.com ?
I can login to github.com fine. I don't have an account at suse.com but I do get the login form.
I've sent the credit card URL to you by email. However further testing shows that if I go directly to the redirected URL, then I do get a login form. And it seems this is the one they use from their main site go to credit cards. So it doesn't seem to be as serious a problem as it appears. It's still puzzling though.
Ok, so this is a weird one.
I've just tested with upstream Firefox 93 and even Chromium. The login-page redirect does not work for any of them, for the page you have provided us with. So, I would think the page itself is broken.
Our own build still shows the FIPS-abort, which shouldn't happen (I could reproduce this locally). But I think it is not responsible for the behavior you see.
Ok, looks like one is supposed to not use a deep link but enter by the "front door" for the credit card site. Thanks anyway.
If SSL is generally working but there are edge cases where you're getting FIPS errors in non-FIPS mode, it's very likely a sandboxing error.
If we're unable to check if we're in FIPS mode, we have to bail out -- otherwise we might be silently ignoring a positive FIPS setting, which would be bad. And if the FIPS check were truly broken/always failing, you should expect SSL to not work at all (which is what I think @msmeissn is getting at).
If you look at the link I posted in the first post that brought me to this repo, you will see that the patch is indeed to fix the sandbox. I just thought it might also be preventing Firefox from presenting me with a login form, but that seems to be a problem with the web pages in question. Remember that SSL is already working with the sites in question since they are just internal redirects within the site.
Recall that the last part of the diagnostic was: Redirecting call to abort() to mozalloc_abort. It just made me consider the possibility that it was throwing a Rust exception or something like that and giving up on the page, hence no login form. But you guys can let us know how it goes.
martin and i debugging this, the socket sandbox currently does not know the /proc/sys/crypto/fips_enabled name ... martin tries a test build to fix it.
This should be fixed with 7019bc2.
If not, please reopen this ticket.