SRI should be checked before Unicode conversion

[tniessen]

Version

v16.6.1

Platform

Any

Subsystem

policy

What steps will reproduce the bug?

1. Create a file index.js such that its contents change after Unicode processing. For example, use

   $ xxd -groupsize 1 index.js 
   00000000: 2f 2f 20 c0 af 0a 0a                             // ....

2. Compute the SRI value, e.g., using OpenSSL:

   $ echo "sha384-$(cat index.js | openssl dgst -sha384 -binary | openssl base64 -A)"
   sha384-Z8NoAR4bc95cOnD/QrsnPsgs5pmETQ3ke3NpAVI0Ve08aqCW6aaHFRNVrhcsBCua

3. Test the SRI value in a browser:

   <script src="index.js" integrity="sha384-Z8NoAR4bc95cOnD/QrsnPsgs5pmETQ3ke3NpAVI0Ve08aqCW6aaHFRNVrhcsBCua"></script>

4. Create policy.json:

   {
     "resources": {
       "./index.js": {
         "integrity": "sha384-Z8NoAR4bc95cOnD/QrsnPsgs5pmETQ3ke3NpAVI0Ve08aqCW6aaHFRNVrhcsBCua"
       }
     }
   }

5. Run the script with the policy file:

   node --experimental-policy=policy.json index.js
   

How often does it reproduce? Is there a required condition?

Always.

What is the expected behavior?

No output, unless index.js contains code. In the example above, index.js contains a comment only.

This behavior can be observed in Chrome and Firefox.

What do you see instead?

Error [ERR_MANIFEST_ASSERT_INTEGRITY]: The content of "file:///home/tniessen/dev/policy-test/index.js" does not match the expected integrity. Integrities found are: sha384-s+/FLC70SKA4cOtWba1RQAhBoGcQoMRXt/kU5mp0oDnO+hQVqm5/zQkIaG26qVa0

Additional information

It seems unlikely that this could cause any real security issues, but it does allow hash collisions. Different byte sequences can result in the same Unicode character sequences, which, when hashed, result in the same digests.

The issue arises from the fact that Node.js loads a byte sequence from the resource, converts the byte sequence to a Unicode string, and then converts the string back to a byte sequence for the SRI check.

Refs: #37248