Intent to Deprecate and Remove: non-origin-clean ImageBitmap serialization and transferring

[Yutaka Hirano]

Primary eng (and PM) emails

yhi...@chromium.org

Summary

ImageBitmap can contain data from cross-origin images not verified with the CORS logic. We call such ImageBitmap objects as “non-origin-clean” ImageBitmaps. ImageBitmap is serializable and transferable, but we are proposing to raise errors when web developers are trying to serialize or transfer an non-origin-clean ImageBitmap.

Motivation

We are developing Cross-Origin-Opener-Policy (COOP) and Cross-Origin-Embedder-Policy (COEP) for unblocking APIs such as memory measurement APIs. The basic idea is that we are going to “isolate” a renderer process so that resources not verified by CORS (or CORP) logic cannot enter the process. We call such a process as “cross-origin isolated” process. Non-origin-clean ImageBitmap is data we need to prevent from entering into an cross-origin isolated process.

Hence we would like to disallow serialization and transferring non-origin-clean ImageBitmap.

Interoperability and Compatibility Risk

WPT tests: serialization, transferring

Firefox: Supported, positive to removal

Safari: Supported, no signals

Alternative implementation suggestion for web developers

Origin-clean ImageBitmaps remain serializable and transferrable. Web developers can create an origin-clean ImageBimap by creating from an image verified with CORS.

Usage information from UseCounter

I added use-counters (NonOriginCleanImageBitmapSerialization and NonOriginCleanImageBitmapTransfer) in M79, so we have data from beta, not from stable.

So far both counters are less than 0.001% of the PageVisits counter. Here is the detailed data (sorry, for Googlers only).

 

Entry on the feature dashboard

https://www.chromestatus.com/features/5728790883860480

Requesting approval to remove too?

Yes (M-80).

We would like to unblock the memory measurement API in the future (M82 or later). But I think it’s good to remove this sooner because otherwise an attacker can get an non-origin-clean ImageBitmap and stores it to the indexeddb in M80 and sniff the contents with the memory measurement API in M82 (Note: even when this feature is removed, an attacker can sniff data with some nice tricks if he/she can have the data enter into the process. The critical part for security is the serialization part, not the deseriazation part).

It is true that an attacker can do the same thing with M79 and M82, but I think having one milestone lessens the security risk considerably.

I will follow up with the M80 stable numbers, and if the numbers are problematic I will revert the removal change and merge it to M80.

[Anne van Kesteren]

On Tue, Nov 19, 2019 at 6:36 PM Yutaka Hirano <yhi...@chromium.org> wrote:
> Note: even when this feature is removed, an attacker can sniff data with some nice tricks if he/she can have the data enter into the process.

Mozilla is definitely supportive of simplifying this setup if
possible. Our bug for this is
https://bugzilla.mozilla.org/show_bug.cgi?id=1565205 if that helps.
I'm rather curious what the meaning of this note is however. What are
the remaining holes you are thinking of here?

[Yutaka Hirano]

Assume we remove the feature on M80.

A web developer can persist a non-origin-clean ImageBitmap with IndexedDB on M79.

Starting from M80 we are going to raise exceptions when the web developer tries to load such ImageBitmaps from the database, but the block will be implemented in the renderer.

So, the situation will be similar to a note in the current proposed PR:

To truly protect against sidechannel attacks implementations should avoid transmitting serialized.[[BitmapData]] to the surrounding agent's agent cluster under the above conditions.

ImageBitmaps serialized with M80 or later will be OK, because we won't allow serializing non-origin-clean ImageBitmaps.

[Yoav Weiss]

LGTM1

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CABihn6F5OdsvsXo3ivErEvPYiU2WyDQ_p4_R8PvHi3RgAVYNfQ%40mail.gmail.com.

[Mike West]

LGTM2.

-mike

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CACj%3DBEjDyOeQcxsgK%3D9-HQPU4gVxkxSpx9nTgghEPN4OfxjJEA%40mail.gmail.com.

[Chris Harrelson]

LGTM3

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAKXHy%3Dex%2Bsex%2B7hLA4vpyHXv0AmKmku-SQf78kaLi4wgVBQdyg%40mail.gmail.com.

[Yutaka Hirano]

I took a look at stable numbers and they looked good.

I see

> So far both counters are less than 0.001% of the PageVisits counter

with Chrome 79 stable. We don't need to change our mind I think.