Re: Cross-domain information leak with UI Security Directives

I'm not entirely sure whether the attack works. My question is, suppose
that attacker.com and bank.com both paint the exact SAME bitmap on a
certain screen region within the specified display-time (say 500 ms), do
browsers repaint that screen region?

If the browser does NOT repaint, then the attack might work. Nevertheless,
the attacker must also guess when the user will click, and overlay the
guessing image shortly (e.g. within 500ms) before the click. Further note
that the amount of boolean tests exposed would be bounded by the number of
user clicks performed.

If the browser does repaint, then the Display Change List (see Section
"Input Protection Heuristic") would record two different repaint-causing
documents which would trigger a violation if clicked by the user, thus the
attack would not work. (For our InContext prototype, this was the case.)

Thanks,
David




On Sun, Jun 2, 2013 at 2:05 PM, Hill, Brad <bhill@paypal-inc.com> wrote:

> Hmm...
>
> I think the case the security image that can be shown in an embedded
> context, (either because it lacks XFO or produces differential output from
> a stable, cross-user URI) is probably already insecure - the attacker could
> just use that kind of embedding to directly spoof the page.
>
> There are also probably other side channels that would allow determining a
> user's logged-in state, and I don't know if that is by-itself a serious
> issue.
>
> Maybe a more interesting attack is a site that offers a game where numbers
> appear in different parts of a play area and you're supposed to click on
> them, whack-a-mole style.  Behind the scenes, it's briefly showing a
> repositioned, framed view of a specific area of your bank account summary
> screen, then replacing it again with a guess with an input-protection rule.
>  If the user's click gets delivered intact, they guessed right, if the
> click has the unsafe flag set, they guessed wrong.  By continuing the game,
> they can learn your balance.
>
> So it seems this does introduce a general information leak side channel.
>
> I wonder if it is possible to limit the bandwidth of this channel enough
> to make the mechanism useful for good scenarios while very cumbersome for
> bad scenarios.
>
> e.g., perhaps we could have a rate-limiting timeout on violations in a
> given window or for a window + set of origins?  Perhaps we break the "no
> new security prompts" rule and show a modal warning dialog for ten seconds,
> or just force the user to close that tab/window, if we see multiple unsafe
> interactions within a short time period.  Not great, but I expect the
> signal from abuse of this kind of side channel would be pretty unambiguous,
> so the false positive rate would be very, very low.
>
> Other ideas?
>
> -Brad
>
> > -----Original Message-----
> > From: Peleus Uhley [mailto:puhley@adobe.com]
> > Sent: Tuesday, May 28, 2013 4:31 PM
> > To: public-webappsec@w3.org
> > Subject: Cross-domain information leak with UI Security Directives
> >
> >       I was reviewing the UI Security Directives specification and I
> believe
> > that I have identified a way that it can be used as a small cross-domain
> > information leak.  Here is the overview:
> >
> >                Attacker's goal: The owner of haxor.biz wants
> information about
> > your browser's state with another domain. As one example, let's say
> > haxor.biz wants to know what your anti-phishing security image is with
> your
> > bank. (e.g. Your login page will always show a teddy bear so you know
> that
> > you are at their site).
> >
> >                Assumptions: Most security image implementation are based
> on a
> > fixed number of pre-selected images. The owner of haxor.biz has
> > downloaded all of them from the victim site.
> >
> >                Method of attack: The victim visits haxor.biz. The site
> haxor.biz loads
> > a child iframe from haxor.biz that has UI safety directives specified
> and a
> > report-uri pointing back to haxor.biz. Within the UI protected frame,
> > haxor.biz has an image tag which references the bank's security image
> CGI so
> > that it will display the victim's security image.  The browser will take
> the
> > initial screen shot based on this state.  Then the haxor.biz page will
> overlay
> > the security image with what it believes the victim's security image to
> be.
> > The display-time timeout will occur and another screen shot will be
> taken.
> > The two screen shots will be compared.  If haxor.biz gets an error
> report to
> > their report-uri, then they know that they have guessed wrong. If
> haxor.biz
> > doesn't get an error-report, then they have guessed the victim's security
> > image.
> >
> >                In practice, I realize that the security image isn't the
> best example
> > based on when they typically show up in a login work flow and the number
> of
> > possible images. However, there could be simpler variants of this
> attack. For
> > instance, if the attacker just wanted to know whether you are logged in,
> then
> > they could try overlaying the "sign-in" vs "login" buttons of the victim
> > website. This information could be useful in making CSRF attacks more
> > accurate.
> >
> >                Challenges for the attacker: Many sensitive web pages
> will have x-
> > frame-options or CSP frame-options defined to prevent haxor.biz from
> > loading their site in an iframe. The attacker would be limited by the
> fact that
> > the content that is being tested would be visible to the end-user when
> the
> > snapshot is being taken. Also, this attack wouldn't allow for an
> arbitrary read
> > of the page contents. It would only allow the attacker to perform a
> > true/false test on the user's session with another domain. The actual
> value of
> > the information that is leaked would be site dependent.
> >
> >             The primary concern with this issue is that it would be a
> by-default
> > information leak in the browser that sites would have to take action to
> > protect themselves against it. Do we think that this risk merits a
> change to
> > the spec? Any additional ideas or concerns?
> >
> > -Peleus
> >
>
>
>