868967 - Attacker is able to inject own assertion in login process

Status: RESOLVED FIXED

(Cloud Services :: Server: Identity, defect)

Description

[g.schmitz]

As already discussed with Dan Callahan by email, here is a more
detailed bug report of one of our findings.

During the login process (initiated by navigator.id.get or
navigator.id.request) an attacker (e.g., in an advertisement iframe)
can inject postMessages in the communication between the login dialog
and the BrowserID JavaScript (include.js) running at the web page of
the relying party. The communication between the login dialog and
include.js is handled by the WinChan library, which doesn't check the
sender of a received postMessage.

To abuse this insufficient handling of received postMessages, a
malicious JavaScript can, for instance, send the following postMessage
to the relying party:

{
  "a" : "response",
  "d" : {
    "assertion" : <assertion for [e-mail]>,
    "email" : ""
  }
}

Such a message can be constantly sent by the malicious JavaScript.
When the user wants to sign in at the relying party, she clicks on the
"Login with Persona" button, which then triggers either
navigator.id.get or navigator.id.request. Next, the login process
starts, which opens the login dialog using the WinChan library. A
postMessage handler gets registered by include.js at the relying
party's document (and also in the login dialog). Now, when the
postMessage handler at the relying party's document receives the
malicious message, it handles it as a valid response from the login
dialog. The login dialog is then instantly closed (probably without
the user noticing that a window has popped up for a very short
time). The malicious assertion is handed over to the onlogin handler
of the relying party, while the communication_iframe is informed that
no one is logged in. As the malicious assertion received by the
relying party can be a valid assertion for [e-mail] (which
such an attacker can easily generate by himself), the relying party
considers the user to be logged in as
[e-mail]. Alternatively, the malicious assertion can be
invalid, which then blocks the login completely (as constantly new
invalid assertions arrive at the relying party's document and all
further login dialogs get closed immediately).

The faked email address sent in such a malicious response is sent to
the communication_iframe, which double-checks if the user is logged in
at Persona and if the received email address is recorded as logged in
at the relying party in the localStorage.  However, the
communication_iframe is only able to send "login" or "logout"
postMessages and no special error message. It is up to the relying
party how to handle (or detect) postMessages sent by the
communication_iframe in the case of mismatch. Further, if the attacker
knows which email address the user uses at the relying party, he can
send this email address in order to keep the communication_iframe
quiet. Additionally, the attacker can send an empty string as the
email address, which would also prevent the communication_iframe from
detecting a mismatch, if the user is not logged in at Persona or has
never been logged in at the relying party with her current browser.

To fix this issue, the onMessage function of the WinChan library
should be modified to check that the origin is the expected one
(Persona). Additionally, the redundant email address sent in the
"response" postMessage sent from the login dialog could be removed as
the email address is also contained in the assertion, where it can't
be spoofed.  Further, after the communication_iframe has been informed
about the email address in the assertion, the include.js in RP could
wait for some acknowledgement (all checks ok) by the
communication_iframe before handing over the assertion to the onlogin
handler.

Comment 1

[Daniel Veditz [:dveditz]]

freddy: since you added the wsec- keywords please rate this sec-low,-moderate,-high, or -critical.

Comment 2

[Frederik Braun [:freddy]]

I'd say this is sec-high. Any objections, Dan Callahan?

Comment 3

[Dan Callahan [:callahad]]

Passing the sec-high, etc. question over to Francois

Comment 4

[François Marier [:francois]]

Ben, Lloyd and I discussed this last week and we were of the opinion that it is a real attack, but that it's difficult to weaponize because if I'm an attacker and I want to trick you to log in as me on a site, I need to:

1. inject my iframe into the target site
2. send my own assertion at the same time as yours

It's a small fix (likely just adding an if statement) to winchan, but we're not planning on hotfixing it on production because we want more time to test it on all of our supported platforms.

So it should go into the train that's currently in dev (5/22) and scheduled to be deployed on June 5th.

Comment 5

[Frederik Braun [:freddy]]

Thank you for the clarification! :)

Comment 6

[fett]

Our understanding was that the assertion could just be sent repeatedly all the time. Is that not possible?

Comment 7

[Frederik Braun [:freddy]]

Well, if we want to be extra precise:
Yes, the attacker can just send the assertion repeatedly and will most likely succeed in winning the race condition (it's not a very tough race after all ;)).
And strictly speaking the attacker does not have to be in an iframe either: Other script contexts are fine too. An XSS on the same origin of the RP will also do.

Comment 8

[Daniel Veditz [:dveditz]]

(In reply to François Marier [:francois] from comment #4)
> So it should go into the train that's currently in dev (5/22) and
> scheduled to be deployed on June 5th.

Did it? Since no one ever got assigned to this bug I'm not hopeful.

Could this be used directly by an attacker against a site in order to login as a celebrity or a site admin?

Comment 10

[g.schmitz]

> Could this be used directly by an attacker against a site in order
> to login as a celebrity or a site admin?

An attacker cannot gain additional account privileges on the target site by this bug. But an attacker can either block the login completely or force the user to login into an attacker's account.

In the latter case, if the user does not notice that something is wrong, the user gives information to the attacker. For example, imagine an application like Trovebox and a celebrity uploading a private photo album.

Comment 11

[François Marier [:francois]]

It appears this bug has slipped through the cracks :(

I will take care of it this week.

Comment 12

[chris hofmann]

gschmitz, tried to send you bounty award info but haven't seen a reply.  If you are interested please contact [e-mail]

Comment 13

[François Marier [:francois]]

Attachment: open-origin.zip

Simple example to reproduce the winchan bug due to a lack of origin checking in open()

Comment 14

[François Marier [:francois]]

Attachment: open-origin.patch

Fix for open()

Comment 15

[François Marier [:francois]]

I think there's a similar bug in onOpen and I'll look into reproducing (and fixing) that one tomorrow.

Comment 16

[François Marier [:francois]]

I think we can ignore the lack of checking in onOpen because there's no way to reliably check the origin of window.opener at the time when we receive the first postMessage.

Additionally, all that a hostile site could do is steal the "button click" from another site and get the user to log into the attacker's site. The Persona dialog will still show the right URL (the attacker's site) and the assertion will be restricted to the attacker's site too.

I will work with John to get the attached one-line fix pushed to stage for testing on all of our supported platforms.

Comment 17

[François Marier [:francois]]

Here are pull requests for the trains that are in production and in stage:

  https://github.com/mozilla/browserid_private/pull/10
  https://github.com/mozilla/browserid_private/pull/9

Comment 18

[François Marier [:francois]]

The fix is running in production and has been merged into the public winchan repository:

  https://github.com/mozilla/winchan/commit/0afb18feae83d0f22d2b94f61fd56efe5fe19904

Comment 19

[Curtis Koenig [:curtisk-use curtis.koenig+bzATgmail.com]]]

un-hiding are request of :francois