Csswg-drafts: [css-color-4] Security: handling of color-profiles

[jsalowey]

I've been assigned to security review this document. I have some concerns with the handling of color profiles and how they might introduce security and privacy risks. My understanding of them is incomplete.

1. Are the .icc files listed in the color-profile meant to be retrieved and parsed in real time?

If so there is a potential risk that these requests could be used to track a user or deliver a malicious payload.

1. Are .icc files something that browsers already parse or is this a file-format that is new to them? Can these files contain any "scripts" or "code"?

What are the ways an implementation can mitigate any risks associated with handling this new file type?

1. Can a script determine if the profile was used or if a fallback was used?

If so it seems this could be used in fingerprinting

1. How would color-profiles interact with content security policy?

Do you envision any special treatment of these requests by content security policy?

[tabatkins]

Are the .icc files listed in the color-profile meant to be retrieved and parsed in real time?

Yes. The "track a user" concern is identical to any resource specified in CSS, tho - in particular, images like background-image.

The "malicious payload" concern is relative to whatever parsers browsers use for their ICC parsing - a broken parser is def an issue, but it's also a clear bug. I'm not sure - how severe is this kind of thing? It's part of any new file format being introduced, right?

Are .icc files something that browsers already parse or is this a file-format that is new to them? Can these files contain any "scripts" or "code"?

New file format.

Dunno about their contents - @svgeesus?

Can a script determine if the profile was used or if a fallback was used?

Yes. Can you elaborate on how it enables fingerprinting? The only profiles available are those predefined by the spec, and those explicitly loaded by the page. The latter aren't a fingerprinting vector - they're the same for everyone visiting the page - and the former is the generic "new features aren't supported by old browsers, and thus allow UA detection" leak intrinsic to the entire web platform.

How would color-profiles interact with content security policy?

The interaction between CSS's resource loading and CSP is ill-defined in general right now, but I suspect this interacts identically to CSS image loading.

[svgeesus]

Color profiles are in practice mostly used to give the (large) amount of measured color information needed to accurately convert colors on a Web page into CMYK for printing on a specific printer/ink/paper combination. The specification recommends some widely used profiles (FOGRA, SWOP) for particular characterised printers, which being standard are less of a tracking risk and will enable accurate printing at a commercial print shop. But if someone needs to print on an unusual printer they can do that too. Such workflows are in practice more likely to be intranet than internet, for example a publishing house generating a printed book from HTML/CSS sources.

Color profiles can be used for RGB colorspaces as well, but the CSS Color 4 specification already predefines the most commonly used ones, so that color profiles do not need to be downloaded.

[svgeesus]

Adding on to (or in one case contradicting) what Tab said:

Are the .icc files listed in the color-profile meant to be retrieved and parsed in real time?

Yes

If so there is a potential risk that these requests could be used to track a user or deliver a malicious payload.

Malicious payload is unlikely, the contents of an ICC profile are declarative and contain measured color information. There are no scripts in color profiles and no script execution mechanism.
They are defined by the International Color Consortium (ICC)
http://www.color.org/v4spec.xalter

Are .icc files something that browsers already parse or is this a file-format that is new to them?

Tab was incorrect here.
Browsers already parse them, embedded in images such as JPEG or (ore rarely) PNG.
Having the ICC files standalone and linked to the content was first introduced by SVG in 1998 and was implemented by browser plugins such as Adobe and Corel.
It is new to CSS (It was previously in CSS Color 3 but was dropped because there was only one implementation, in IE for Mac.
But browsers have been handling ICC profiles in raster images for over a decade.

Can these files contain any "scripts" or "code"?

No, see above.

What are the ways an implementation can mitigate any risks associated with handling this new file type?

Security bugs get reported to the ICC, which discloses them after fixes have been tested and deployed. See
http://color.org/profilesecurity.xalter
W3C is an ICC Member; I'm the W3C representative to the ICC, so I do now hear about these.

Can a script determine if the profile was used or if a fallback was used?

Possibly but unlikely. For example a profile could be used to swap the red and green channels, which would give a different visual result. However, browsers already have pretty good defenses to stop a script reading colors back off the screen.

[x-Jake-x]

Hi there! The only way I can see color profiles being different than the background-image problem in this case would be a gamut-mapping-detection possibility. To avoid duplicating detail, I just mentioned it in: https://github.com/w3c/csswg-drafts/issues/5553#issuecomment-700664793

[svgeesus]

Thanks, I was actually just reading that comment :)

[svgeesus]

OS-level color management systems are certainly a possible attack surface, but this has already been probed and cleaned up over the last decade or so from fuzzing image decoders. The ICC profiles used in CSS Color 4 as the same as those embedded in raster images or PDFs.

See for example https://www.real-sec.com/2020/09/fuzzing-image-parsing-in-windows-part-one-color-profiles/

[svgeesus]

As a further indication that ICC is not a new format on the Web, the Internet Media Type application/vnd.iccprofile was registered in 2008.

[svgeesus]

Do you envision any special treatment of these requests by content security policy?

Currently, CSS accesses external resources such as fonts, images, color profiles via the url() function. We have discussed specifying a similar but more full-featured function, (tentatively called src())which is CORS-aware and usable with CSP, plus some other improvements like usabiity with string concatenation. This would provide a consistent improvement for all external resources referenced from CSS, rather than solving it multiple times:

• [css-values] Define crossorigin, preload and async URL modifiers
• [css-values][all] Define all URL usages in terms of Fetch
• [css-font-loading] unclear how CSP interacts with font loads
• [css-fonts-3] [css-fonts-4] Font fetching in anonymous mode makes it impossible to link to fonts behind authentication
• [css-values] Add url() alias that does not accept unquoted URLs

So I guess the answer to your question is "we are working on that, and the solution will not be specific to color profiles"

[tabatkins]

As a further indication that ICC is not a new format on the Web, the Internet Media Type application/vnd.iccprofile was registered in 2008.

It's "a new format on the web" because browsers do not currently parse ICC files; this is a new parser being exposed to the web.

The presence of it in standards doesn't matter here, it's the exposure of potential new parsing vulnerabilities due to new parsers being exercised by potentially malicious actors.

[jsalowey]

Adding this to the list of resources to address for CORS and CSP sound like a good idea. Much better to handle this generically.

There will be some added attack surface exposed by the processing of the color profiles, however the file format does not have potentially dangerous functionality such as scripting. It would be a good to review and fuzz implementations that handle this format, but I'm not sure that is something that goes in this spec.

[svgeesus]

Okay so for the security & privacy appendix I added a note that ICC profiles are downloaded on demand and do not contain executable code.

Beyond that, I am not hearing any requests for changes to the specification, is that correct?

[jsalowey]

Correct. I don't think there is anything actionable for this specification.