808234 - Spoof potential due to emoji in URL bar, tab titles and titlebar

Status: NEW

(Firefox :: Security, defect, P3)

Description

[Justin Dolske [:Dolske]]

Firefox supports display of Emojii now, these are some interesting unicode glyphs because they're inherently graphical and at least on OS X are rendered with colors. See: http://en.wikipedia.org/wiki/Emoji

I wonder if we should allow the display of them in the URL bar, and perhaps other places where users could be surprised/confused by the presence of "images".

A couple of confusing examples:

 Using 

Comment 1

[Justin Dolske [:Dolske]]

Attachment: Screenshot on OS X

Comment 2

[Justin Dolske [:Dolske]]

Oh, fascinating. Bugzilla truncated comment 0 where I included 2 emojii characters.

Here are the two examples:

  Using (lock): http://is.gd/3pLfRY
  Using (warning): http://is.gd/59KCMl

Comment 3

[:Gavin Sharp [email: [e-mail]]]

This would just be a matter of adding the appropriate character ranges to losslessDecodeURI.

Comment 4

[Johnathan Nightingale [:johnath]]

tyvm unicode.

Yeah, I agree that escaping these makes sense, but I'm sure that going down that rabbit hole will be IDN-style pain, where there will be some characters/pages we don't want to escape. I think, as with IDN, I'd rather escape by default and then whitelist in, but we're already well into me talking without knowing enough.

So... let's summon the Gerv, IDN-master. And some other folk.

And you probably want to file that bug on bugzilla truncation cause that feels like a bad time coming, too.

Fun.

Comment 5

[Gervase Markham [:gerv]]

"Firefox supports display of Emojii now" - could we have some background to this?

We currently have an IDN character blacklist, which contains dot-alikes, slash-alikes and so on. (Many or all of these characters may have been made illegal by IDNA2008, uur implementation of which is bug 479520.) However, that list applies solely to hostname labels.

In order to work out the appropriate mitigation strategy, we probably need to know the use cases for this 'feature'. Is it something that was specifically enabled, or did it fall out of some other work?

Gerv

Comment 6

[Gervase Markham [:gerv]]

Dolske: can you shed some light on the questions from comment 5?

Gerv

Comment 7

[Justin Dolske [:Dolske]]

Emoji are basically just an slightly unusual extension to stuff that's already in Unicode, and it's mixed in with the way iOS/OSX renders these with colors. So they're more like icons than text/glyphs. Which leads to the unusual situation this bug is about.

IDN isn't directly applicable here, other than being relevant as a thing that's doing unicode filtering in the domain part of the URL. [Well, hmm, I didn't check to see what happens with "<emoji>.sometld.jp". But the examples here are all involving the path part of the URL.]

Anyway. AIUI, the (short) history of this is that they started off as vendor-specific emotions in the pre-iPhone Japanese mobile market for IM/SMS, because hugely popular, and got standardized into Unicode.

I think it's rather unlikely that these are useful display in URLs, hence the suggestion that we escape them. (Another possibility, which I don't know if is possible, would be to add something -- CSS perhaps -- to force rendering Emoji as a 1-color glyph.)

Comment 8

[Justin Dolske [:Dolske]]

Attachment: Screenshot on Windows (FF+Chrome)

Note how on windows it's a monochrome glyph, so it looks much less special. Chrome doesn't seem to support Emoji (even in content), not sure what's up with that. Also note that Chrome is escaping all the intermediate spaces, we might want to do that too in some cases.

Comment 9

[Gervase Markham [:gerv]]

Does anyone know how these things get rendered in colour? Is it a property of the font used? I didn't realise fonts could contain colour information...

I have still not managed to understand how this has become a problem recently; was there some code change which enabled this? Was it deliberate ("support emoji") or a side effect of something else?

In order to take action on this bug, if we decide to take action, I think we need:

- Some definition of the characters we think are dangerous to display, or some mechanism for creating that definition
- Decision on whether we are whitelisting or blacklisting
- A code patch which takes that list and escapes them for URL bar display; see comment 3

I heed jonath's point about white-vs-blacklisting, but if we whitelist, we are going to be forever chasing Unicode as new scripts get added and people, reasonably enough, want to use them.

Also, dolske, please do file that bug on Bugzilla if you haven't already!

Gerv

Comment 10

[:Gavin Sharp [email: [e-mail]]]

(In reply to Gervase Markham [:gerv] from comment #9)
> Also, dolske, please do file that bug on Bugzilla if you haven't already!

(it's already on file as bug 405011)

Comment 12

[Justin Dolske [:Dolske]]

This and 740893 as aspects of the same issue, so mutating. In general, having content-supplied emoji show up in chrome UI leads to the potential for spoofing/confusion. We should filter them out (or escape, or somehow make monochrome, or ...)

Comment 13

[Gervase Markham [:gerv]]

Before we can do anything, we need answers to the questions in comment 9.

It would also be helpful to know exactly how this is happening, technically. Is it that the OS is choosing a font which itself contains colour information? I wasn't aware fonts were able to do that...

Gerv

Comment 14

[Gervase Markham [:gerv]]

Bug 479520 (implement IDNA2008), once someone gets time to implement it, will disallow Emoji and similar characters in domain names. Will that do, or do we need to ban them in other parts of the URL as well?

Gerv

Comment 16

[Anne (:annevk)]

1) This is part of fonts delivered by the OS. It's very popular on Mac OS X and iOS. They use bitmaps.

2) IDNA-wise we are safe, IDNA2008 or not.

3) URL path-wise we are vulnerable as evident from comment 2 or e.g. http://example.com/%F0%9F%94%92

Comment 17

[:Gijs (he/him)]

Per https://blog.emojipedia.org/emojipedia-now-with-https/ , it seems like Safari has started doing this in the tabstrip, at least.

Comment 18

[Jonathan Watt [:jwatt]]

Mass bug change to replace various 'parity' whiteboard flags with the new canonical keywords. (See bug 1443764 comment 13.)