New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 829271 link

Starred by 3 users

Issue metadata

Status: Assigned
Owner:
Buried. Ping if important.
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Windows
Pri: 2
Type: Bug



Sign in to add a comment

CSP hash verification of inline content is based upon transformed content

Reported by skuldw...@gmail.com, Apr 5 2018

Issue description

UserAgent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/65.0.3325.181 Safari/537.36

Steps to reproduce the problem:
See attached zip for a full PHP/JS/CSS/HTML demonstration.

What is the expected behavior?
The engine should calculate the hash on the original inline style or script (or other inline) content.

What went wrong?
The engine calculates the hash after having transformed newlines and possibly other transformations of the inline content.

Did this work before? N/A 

Chrome version: 65.0.3325.181  Channel: stable
OS Version: 10.0
Flash Version: 

To avoid the need to download the attachment here is a minimal amount of PHP code to demonstrate the bug workaround.

----code start---
$css = file_get_contents(TEST_CSS);
$css = str_replace("\r\n", "\n", $css); //Bug workaround
$css_sha256 = base64_encode(hash('sha256', $css, true));
----code end---

Without the bug workaround there is a hash mismatch. See the attached zip for a functional example (should work on PHP 5.3 and later).

By default the test will show "Script not working, style is working."
By commenting/un-commenting two lines in the PHP script this will change.

(Issue 487510 and Issue 627966 seems to be related.)

I also tested with Edge (16), and Firefox (59), their behaviour is the same. It is unlikely all three engines happen to have the same bug, so this might be a specification flaw/bug.

I do not know if this constitute a security vulnerability, I do not have the knowledge or means to test for this.

A fix would most likely require a spec correction or clarification, which would impact all vendors. Do note that I have no examined the specs to see what it says regarding transforming the content before hashing it and doing hash comparisons.

All I know is that transforming the content and then doing the hash is the wrong way to do it as this would mean that a web server (or scripts) would need to know how browsers (and each version of a browser) transforms contents before hashing.

Unfortunately fixing this bug would also break a lot of scripts, but not fixing it also makes inline hashing unreliable or excessively difficult to implement if web developers are unaware of this bug.

If the bug is unfixeable then information must be provided in dev console inform the developer how to fix their hashing so it works, currently you only have a hashes that are mysteriously wrong despite all obvious logic.
 
test.zip
1.4 KB Download
Summary: CSP hash verification of inline content is based upon transformed content (was: CSP hash verification of inline is not done on original binary content but on transformed content instead.)
As this "fails safe", I think we should derestrict it to a general Type=Bug.

Live copy of the POC is available at https://whytls.com/test/sricrlf/.

>If the bug is unfixeable then information must be provided
> in dev console inform the developer how to fix their hashing
> so it works

That already exists; the correct hash is provided in the error message

Refused to execute inline script because it violates the following Content Security Policy directive: "script-src 'sha256-+fMPtOEk4eRXtp+lAauXFq3Kj4HIk1rY5gKdIUkudnU='". Either the 'unsafe-inline' keyword, a hash ('sha256-wmxIBxFyjiyFHKEwHAK+Fv1lOABVyvbZpif9FdMDfIw='), or a nonce ('nonce-...') is required to enable inline execution.
Components: Blink>SecurityFeature
Labels: -Type-Bug-Security -Restrict-View-SecurityTeam -Via-Wizard-Security Type-Bug
Cc: mkwst@chromium.org
Components: -Blink>SecurityFeature Blink>SecurityFeature>ContentSecurityPolicy
Status: Untriaged (was: Unconfirmed)
Mike-- I had a quick look around the specs and couldn't find if/where they specify what normalization is done for inline blocks before hashing. Thoughts on this?
Owner: mkwst@chromium.org
Status: Assigned (was: Untriaged)
Assigning to mkwst@ as he owns the other related issues as well.

Sign in to add a comment