1531568 - Consider moving canvas backing-store OOP once the canvas is tainted (e.g. from cross-origin image)

Status: RESOLVED WONTFIX

(Core :: Graphics: Canvas2D, enhancement, P3)

Description

[Daniel Holbert [:dholbert]]

As discussed in bug 1497715 comment 4 - 5, it may be wise to move the <canvas> bitmap backing-store into a separate process (separate from the content process for the page that contains the <canvas>) as soon as the canvas becomes tainted due to having a cross-origin image drawn into it.

The "tainted" canvas already becomes write-only at that point, from the page's perspective -- but it's conceivable that an attacker could use still spectre/meltdown style attacks to get at the canvas image-data (and read the contents of a cross-origin image). So, for robustness, it'd nice if we could prevent that by moving this memory into a separate process.

Comment 1

[Tom Ritter [:tjr]]

Practically, if evil.com includes victim.com/private.png into a canvas; how is that different from including it into an <img> tag? Spectre can steal the latter; so why protect against the former?

victim.com can opt-into protection for victim.com/private.png with Bug 1459573 (not implemented yet) - and canvas should respect that header; but per Bug 1459357 we're not trying to protect cross-origin images by default.

Comment 2

[Daniel Holbert [:dholbert]]

(In reply to Tom Ritter [:tjr] from comment #1)

Practically, if evil.com includes victim.com/private.png into a canvas; how is that different from including it into an <img> tag? Spectre can steal the latter; so why protect against the former?

Yeah, that's a good point. (Sorry for taking a while to respond, and thanks for the needinfo prod.)

I suppose there's no difference between those scenarios, from a Spectre perspective. So if we're not seeking to protect against spectre-type attacks for the latter, then there's no strong reason to have extra concerns/protections about the former.

So this is probably WONTFIX like bug 1497715 that it was spun off of.