Uint8Array - related issues in Firefox content script (sandboxed environment)

[rrrooommmaaa]

• OpenPGP.js version: 5.9.0
• Affected platform: Firefox when loaded as a content script of web extension

In this setup we have 2 different Uint8Array types depending on where they were initialized: openpgp.js (Sandbox) or Web Cryptography API.

The sandboxed arrays are only recognizable as globalThis.Uint8Array, while the ones returned by Web Cryptography API are (window.)Uint8Array

So we currently need to patch openpgp.js for every occurrence of the pattern like x instanceof Uint8Array
replacing it with x instanceof Uint8Array || x instanceof globalThis.Uint8Array

I also found a helper function is_bytes in the codebase.
Can we fix it like this and call it from all the other places?

  function is_bytes(a) {
      return (a instanceof Uint8Array || a instanceof globalThis.Uint8Array);
  }

There are more details of this research: FlowCrypt/flowcrypt-browser#5013 (comment)

There is also an issue calling subarray and slice methods on (window.)Uint8Array in this setup -- permission denied.
It's better to not use these methods or create a sandbox copy of Uint8Array on arrays returned from Web Cryptography API

[twiss]

Hello 👋 I'm a bit confused by this issue as the Web Crypto API does not return Uint8Arrays, it returns ArrayBuffers. We create Uint8Array views over them ourselves, for example here:

openpgpjs/src/crypto/hash/index.js

Line 63 in 400b163

return new Uint8Array(await webCrypto.digest(webCryptoHash, data));

I don't see any reason why taking a subarray or slice of such Uint8Arrays would not be allowed - have you raised an issue with Firefox?

[rrrooommmaaa]

I don't see any reason why taking a subarray or slice of such Uint8Arrays would not be allowed - have you raised an issue with Firefox?

I can understand the mechanics of it -- when calling subarray or slice, the returned array is expected to be of the same class as the original one, that is an 'array with elevated privileges' (or an array belonging to a process with elevated privileges) should spawn an 'array with elevated privileges' as well, and this isn't allowed in the sandboxed environment -- Permission denied exception is raised. Perhaps, I can raise an issue with Firefox about it.

I'm a bit confused by this issue as the Web Crypto API does not return Uint8Arrays, it returns ArrayBuffers.

If I remember correctly, it happened when serializing params in uint8ArrayToMPI (or uint8ArrayBitLength)-- bin.subarray call. I'll need to run the unpatched version again to reproduce this behavior, if needed. Can it be that Crypto API provides Uint8Arrays in CryptoKey objects, e.g. algorithm.publicExponent
https://developer.mozilla.org/en-US/docs/Web/API/RsaHashedKeyGenParams
I didn't analyze that too deep, I guess you know where bin may be coming from.

[rrrooommmaaa]

stripped = bin.subarray(i); caused this exception Error: Permission denied to access property "constructor"
However, this would work: new Uint8Array(bin).subarray(i)

[twiss]

stripped = bin.subarray(i); caused this exception Error: Permission denied to access property "constructor"

Do you have a stack trace? This code comes from a helper functions so it's not entirely clear in which context this would break.

Can it be that Crypto API provides Uint8Arrays in CryptoKey objects, e.g. algorithm.publicExponent

As far as I can tell, we don't use this property anywhere. E.g. in the case of key generation we take the modulus from base64 and convert it to a Uint8Array ourselves, here:

openpgpjs/src/crypto/public_key/rsa.js

Lines 181 to 184 in bb0c1f8

	const jwk = await webCrypto.exportKey('jwk', keyPair.privateKey);
	// map JWK parameters to corresponding OpenPGP names
	return {
	n: b64ToUint8Array(jwk.n),

.

[twiss]

Btw, a tangential thought; there is another API that we're using that does return Uint8Arrays, namely TextEncoder. Though, normally we probably wouldn't call subarray or slice on those, except in the case of streaming. Is it possible that that's causing the issues you're seeing?

[rrrooommmaaa]

Yes, it is pretty much possible that these arrays are coming from TextEncoder. I didn't analyze the source code too deep, Crypto API was just my guess, as good as any other API. I noticed that these arrays have the mentioned peculiarities as opposed to those created inside OpenPGP.js (sandboxed) code with new Uint8Array statements.

[twiss]

Right. So - in that case, patching TextEncoder (e.g. by doing something like this) might help (though that particular patch has a performance cost - patching the native TextEncoder to return "normal" Uint8Arrays might be more efficient).

If that does help, I would indeed report an issue to Firefox as well ☺️

[rrrooommmaaa]

Replacing TextEncoder with the custom implementation from text-encoding-utf-8 seems to solve some of errors, but not all.
Now the subarray exception happens in produceKey method when trying to decrypt a private key, the stack trace is

produceKey (moz-extension://b71981f4-f479-4233-94ba-ee2af0217449/lib/openpgp.js#24554)
produceEncryptionKey (moz-extension://b71981f4-f479-4233-94ba-ee2af0217449/lib/openpgp.js#25648)
decrypt (moz-extension://b71981f4-f479-4233-94ba-ee2af0217449/lib/openpgp.js#25554)
decryptPrivateKey (moz-extension://b71981f4-f479-4233-94ba-ee2af0217449/js/content_scripts/webmail_bundle.js#6065)
...

so the call

openpgpjs/src/type/s2k.js

Line 184 in 400b163

const result = await crypto.hash.digest(this.algorithm, toHash);

returns the "incorrect" Uint8Array. Namely, asmcryptoHash(Sha256, 'SHA-256') produces the "incorrect" Uint8Array on line

openpgpjs/src/crypto/hash/index.js

Line 63 in 400b163

return new Uint8Array(await webCrypto.digest(webCryptoHash, data));

of the curried function.
However, I'm able to convert the array successfully "outside" of it, that inside produceKey function.
That is, instead of

arr.push(result);

I can do

        const fixedArray = new Uint8Array(result);
        arr.push(fixedArray);

and the exception goes away.
This is what I get:

result instanceof Uint8Array
false

result instanceof globalThis.Uint8Array
true

fixedArray instanceof globalThis.Uint8Array
false

fixedArray instanceof Uint8Array
true

So with 1) this fix, 2) TextEncoder replacement and 3) patch in web-stream-tools-inherited code openpgpjs/web-stream-tools#23
I was able to decrypt a message. Still have similar errors trying to verify a signature.

As some other users were having similar issues in environments totally different from Firefox's content script, can it be a bundler issue?
I noticed this line:

openpgpjs/rollup.config.js

Line 19 in 400b163

const intro = "const globalThis = typeof window !== 'undefined' ? window : typeof global !== 'undefined' ? global : typeof self !== 'undefined' ? self : {};";

Other bundles don't re-define globalThis, perhaps, we shouldn't be doing this in certain environments.
I see that in my Firefox content script environment globalThis points to a Sandbox, and then it's defined here to point to window.

Removing this line causes issues in other places, namely Uint8Array recognition:

equalsUint8Array (moz-extension://b71981f4-f479-4233-94ba-ee2af0217449/lib/openpgp.js#1740)
decrypt (moz-extension://b71981f4-f479-4233-94ba-ee2af0217449/lib/openpgp.js#24066)
decrypt (moz-extension://b71981f4-f479-4233-94ba-ee2af0217449/lib/openpgp.js#24065)
decrypt (moz-extension://b71981f4-f479-4233-94ba-ee2af0217449/lib/openpgp.js#29305)
decrypt (moz-extension://b71981f4-f479-4233-94ba-ee2af0217449/lib/openpgp.js#29298)

I have this:

array1 instanceof Uint8Array
false

array1 instanceof globalThis.Uint8Array
false

array1 instanceof window.Uint8Array
true

and array1.subarray() also throws an exception