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

146 visningar
Hoppa till det första olästa meddelandet

Yutaka Hirano

oläst,
19 nov. 2019 12:36:112019-11-19
till blink-dev, Anne van Kesteren

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

oläst,
20 nov. 2019 09:49:052019-11-20
till Yutaka Hirano, blink-dev
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

oläst,
20 nov. 2019 10:03:442019-11-20
till Anne van Kesteren, blink-dev
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

oläst,
27 nov. 2019 00:12:312019-11-27
till Yutaka Hirano, Anne van Kesteren, blink-dev
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

oläst,
27 nov. 2019 00:55:012019-11-27
till Yoav Weiss, Yutaka Hirano, Anne van Kesteren, blink-dev

Chris Harrelson

oläst,
27 nov. 2019 01:43:212019-11-27
till Mike West, Yoav Weiss, Yutaka Hirano, Anne van Kesteren, blink-dev

Yutaka Hirano

oläst,
17 dec. 2019 03:44:012019-12-17
till Chris Harrelson, Mike West, Yoav Weiss, Anne van Kesteren, blink-dev
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.
Svara alla
Svara författaren
Vidarebefordra
0 nya meddelanden