User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:94.0) Gecko/20100101 Firefox/94.0

Steps to reproduce:

Prevent CSS exfiltration / password stealing.
This article provides POCs on stealing password using just CSS.

https://portswigger.net/research/ublock-i-exfiltrate-exploiting-ad-blockers-with-css

The Bugbug bot thinks this bug should belong to the 'Toolkit::Password Manager' component, and is moving the bug to that component. Please revert this change in case you think the bot is wrong.

Marking it as a security bug until we confirm this is not.

Does this need to be hidden if the article is public?

This is not a problem with the password manager, but more generically an issue with using maliciously injected CSS to read text content. Moving the bug to a better component, and unhiding because the article is public.

The first part of the article is not relevant to us: it's about using now-fixed bugs in a particular web extension to inject malicious CSS. The fact that injected CSS could do various bad things was already known, but he talks about some interesting ways to use CSS to use downloaded fonts to send signals about the characters encountered in a specified element. The technique he discusses works in all browsers more or less, with a few quirks specific to different browsers.

I don't know how this could be addressed without removing some of the CSS features that let you target different fonts at individual characters.

Note this is discussed in the W3C CSS Fonts Module Level 4 Editor's draft:

14.1. What information might this feature expose to Web sites or other parties, and for what purposes is that exposure necessary?
An attacker may obtain fingerprinting information by querying the Installed Fonts. In contrast to older technologies (notably Adobe Flash, which provided a complete list of Installed Fonts and sent this information in HTTP headers) such probing must be done one font at a time, providing the font family name and then checking (either via script, or by using unicode-range to selectively download webfonts depending on whether the user has a font by a certain name that supports a certain character) whether the font was loaded. This takes time, and checking for more than a few hundred fonts introduces a noticeable delay in page rendering.
For especially privacy-sensitive contexts, options would include never downloading any webfonts (at the risk that some characters may be rendered incorrectly, or not at all), or always downloading all webfonts whether needed or not (ignoring unicode-range, and potentially downloading vast quantities of unused fonts each time the page is viewed).

14.8. What data does this specification expose to an origin? Please also document what data is identical to data exposed by other features, in the same or different contexts.
For third-party Web Fonts loaded via a stylesheet, the stylesheet origin may be exposed to the third party in the Referer header. In addition, careful pairing of unicode-range and distinct src urls allows the third-party to see which characters are used on a page, which is a privacy risk for large character repertoire scripts such as CJK.

The severity field is not set for this bug.
:jwatt, could you have a look please?

For more information, please visit auto_nag documentation.

As far as I can tell, the crux of the article here is: if an attacker is allowed to inject a malicious stylesheet into a page, then they can (in some circumstances) determine what text is present in certain parts of the page.

The "password exfiltration" scenario currently only works in Edge, I think, and it's essentially a page with a password field where an attacker is given the opportunity to choose a custom font for the password field. If the user clicks the button to unmask their password, then their browser requests the appropriate characters for the web-font and the attacker learns the characters in the user's password. I don't believe that's possible in Firefox right now, though it's worth thinking about as we get closer to fixing bug 1743046 and shipping a reveal-password button ourselves. Maybe it'd be worth locking down password fields to prevent using web-fonts on them, if possible?

But yeah, in general, comment 5 sums things up, particularly the last line: "I don't know how this could be addressed without removing some of the CSS features that let you target different fonts at individual characters." For now, the best mitigation here is for sites to avoid letting attackers inject CSS into their pages (which is bad for a variety of reasons beyond what's discussed here).

--> Adjusting summary to make it clearer what this is about.

(In reply to Daniel Holbert [:dholbert] from comment #8)

The "password exfiltration" scenario currently only works in Edge [...] though it's worth thinking about as we get closer to fixing bug 1743046 and shipping a reveal-password button ourselves. Maybe it'd be worth locking down password fields to prevent using web-fonts on them, if possible?

I filed bug 1753116 on this, BTW.