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 evil@attacker.com>, "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 evil@attacker.com (which such an attacker can easily generate by himself), the relying party considers the user to be logged in as evil@attacker.com. 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.

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

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

Passing the sec-high, etc. question over to 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.

Thank you for the clarification! :)

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

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.

(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?

> 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.

It appears this bug has slipped through the cracks :( I will take care of it this week.

gschmitz, tried to send you bounty award info but haven't seen a reply. If you are interested please contact chofmann@mozilla.org

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

Fix for open()

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

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.

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

The fix is running in production and has been merged into the public winchan repository: https://github.com/mozilla/winchan/commit/0afb18feae83d0f22d2b94f61fd56efe5fe19904

un-hiding are request of :francois