Firefox 108 ignores 'unsafe-hashes', sites built using Shibboleth are broken
Categories
(Core :: DOM: Security, defect)
Tracking
()
| Tracking | Status | |
|---|---|---|
| firefox-esr102 | --- | unaffected |
| firefox108 | --- | wontfix |
| firefox109 | --- | fixed |
| firefox110 | --- | fixed |
People
(Reporter: dan, Unassigned)
References
(Regression)
Details
(Keywords: regression)
We use Shibboleth SP and IDP 4.x, and both use <body onLoad="document.forms[0].submit()"> in their binding templates. We had been running fine with 'unsafe-hashes' 'sha256-ePniVEkSivX/c7XWBGafqh8tSpiRrKiqYeqbG7N1TOE=' for over a year now and no issues on any browsers. We added this because without it, Chrome would fail to load document.forms[0].submit() in the binding templates used by Shibboleth. Adding 'unsafe-hashes' 'sha256-ePniVEkSivX/c7XWBGafqh8tSpiRrKiqYeqbG7N1TOE= allowed us to remove 'unsafe-inline' so Shibboleth would work.
As of Firefox 108 using 'unsafe-hashes' 'sha256-ePniVEkSivX/c7XWBGafqh8tSpiRrKiqYeqbG7N1TOE=' no longer works. Firefox 108 will not allow document.forms[0].submit() to execute even with a valid 'unsafe-hashes' entry in the CSP, and we are forced to add 'unsafe-inline' in order for document.forms[0].submit() to load.
I'm hiding this from public view only because I think there might be a lot of sites forced to re-enable 'unsafe-inline' to get their sites back online.
|
||
Updated•2 years ago
|
|
||
Comment 1•2 years ago
|
||
The problem is that Firefox has always ignored unsafe-hashes, but because of a security bug fixed in 108 it sort of matched hashes unsafely anyway (bug 1644790). It wasn't full support because it was a bug side-effect, but in a lot of cases, like yours, you might think we were honoring it. If Firefox had been working properly you would have had to still serve 'unsafe-inline' to Firefox.
In Firefox 108 we actually implemented 'unsafe-hashes' support, but it is disabled while we test it. This also fixed the CSP bypass security bug so some sites are having some touble; we're in a bit of an in-between state.
It would help if you could tell us what site(s) are broken by this, so our release managers can prioritize the testing and enabling of the feature.
|
||
Updated•2 years ago
|
|
|
||
Comment 2•2 years ago
|
||
Set release status flags based on info from the regressing bug 1797070
:tschuster, since you are the author of the regressor, bug 1797070, could you take a look? Also, could you set the severity field?
For more information, please visit auto_nag documentation.
|
||
Comment 3•2 years ago
•
|
||
We might want to start considering uplifting support for 'unsafe-hashes' to Beta at least.
|
||
Updated•2 years ago
|
|
||
Comment 4•2 years ago
|
||
(In reply to Tom Schuster (MoCo) from comment #3)
We might want to start considering uplifting support for 'unsafe-hashes' to Beta at least.
Indeed, we're hoping for this to be uplifted in beta and fixed in Firefox 109
https://bugzilla.mozilla.org/show_bug.cgi?id=1343950#c14
Thanks for the reports and sorry about the breakage. This was definitely more than we expected.
(In reply to Daniel Veditz [:dveditz] Out until Jan 9 from comment #1)
The problem is that Firefox has always ignored unsafe-hashes, but because of a security bug fixed in 108 it sort of matched hashes unsafely anyway (bug 1644790). It wasn't full support because it was a bug side-effect, but in a lot of cases, like yours, you might think we were honoring it. If Firefox had been working properly you would have had to still serve 'unsafe-inline' to Firefox.
I get that. The problem is now with 108 when unsafe-hashes is supported, it's busted. I have unsafe-hashes with proper hash values (I know because I had to implement unsafe-hashes on our site in order to get Shibboleth to work using Chrome). Chrome works, Firefox 108 is just failing even though I have unsafe-hashes and I have the correct hash value for the inline javascript that requires the hash.
In Firefox 108 we actually implemented 'unsafe-hashes' support, but it is disabled while we test it. This also fixed the CSP bypass security bug so some sites are having some touble; we're in a bit of an in-between state.
It would help if you could tell us what site(s) are broken by this, so our release managers can prioritize the testing and enabling of the feature.
It's an internal site.
|
||
Updated•2 years ago
|
(In reply to Dan from comment #5)
(In reply to Daniel Veditz [:dveditz] Out until Jan 9 from comment #1)
The problem is that Firefox has always ignored unsafe-hashes, but because of a security bug fixed in 108 it sort of matched hashes unsafely anyway (bug 1644790). It wasn't full support because it was a bug side-effect, but in a lot of cases, like yours, you might think we were honoring it. If Firefox had been working properly you would have had to still serve 'unsafe-inline' to Firefox.
I get that. The problem is now with 108 when unsafe-hashes is supported, it's busted. I have unsafe-hashes with proper hash values (I know because I had to implement unsafe-hashes on our site in order to get Shibboleth to work using Chrome). Chrome works, Firefox 108 is just failing even though I have unsafe-hashes and I have the correct hash value for the inline javascript that requires the hash.
In Firefox 108 we actually implemented 'unsafe-hashes' support, but it is disabled while we test it. This also fixed the CSP bypass security bug so some sites are having some touble; we're in a bit of an in-between state.
It would help if you could tell us what site(s) are broken by this, so our release managers can prioritize the testing and enabling of the feature.
It's an internal site.
(In reply to Frederik Braun [:freddy] from comment #4)
(In reply to Tom Schuster (MoCo) from comment #3)
We might want to start considering uplifting support for 'unsafe-hashes' to Beta at least.
Indeed, we're hoping for this to be uplifted in beta and fixed in Firefox 109
https://bugzilla.mozilla.org/show_bug.cgi?id=1343950#c14Thanks for the reports and sorry about the breakage. This was definitely more than we expected.
*** This bug has been marked as a duplicate of bug 1343950 ***
If it gets uplifted to the Beta I'd be happy to confirm it has fixed our issues.
Was the only change to fix this setting about:config: security.csp.unsafe-hashes.enabled == true? If so, that would suggest we could revert our change to our CSP to enable unsafe-inline and reenable unsafe-hashes, then tell people running Firefox 108+ that they have to change security.csp.unsafe-hashes.enabled == true. Can you confirm that's the only change we need to get Firefox 108+ to support unsafe-hashes?
|
|
||
Comment 8•2 years ago
|
||
The problem is now with 108 when unsafe-hashes is supported, it's busted.
As we said. Unsafe-hashes is not supported (by default) in 108, but will be in 109.
Was the only change to fix this setting about:config: security.csp.unsafe-hashes.enabled == true?
Yes. We just enabled the pref security.csp.unsafe-hashes.enabled in Firefox 109: https://hg.mozilla.org/releases/mozilla-beta/rev/b970bf751d85. We usually don't suggest that sites recommend fiddling with prefs, but for you internal use case that might be ok.
Description
•