Closed Bug 541308 Opened 15 years ago Closed 13 years ago

random websites can manipulate personas by framing a whitelisted site

Categories

(Firefox :: General, defect)

Product:
Firefox
Component:
General
Version:
3.6 Branch
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED DUPLICATE of bug 542020

People

(Reporter: asa, Unassigned)

References

(
URL
)

Details

(Whiteboard: [sg:moderate])

Attachments

(2 files, 1 obsolete file)

limited only by your imagination
1.09 KB, text/html
Details
rasta root kit spoof.
1.61 KB, text/html
Details 
random websites can manipulate personas

Seems like a big problem to me. I was under the assumption that only getpersonas.com or other whitelisted sites could manipulate Firefox's personas but that appears to not be the case. 

http://lug.wsu.edu/~ben/personal.html
from facebook conversation at http://www.facebook.com/asadotzler?v=feed&story_fbid=301274168011
I'm sorry, I don't understand from that URL what the problem is. Hovering over any of the personas on that site doesn't show a preview. Clicking on them takes me to the Personas website where I can then install them.

This seems INVALID to me; what am I missing?
hovering over them previews for me on 3.6 on win7
so probably not a security sensitive bug since the content comes from a trusted site. still, this was kind of shocking to me and others and perhaps it's a behavior we should consider changing.
Group: core-security
Why was it shocking? Web designers can do many things that are a nuisance for users, at the cost of losing or annoying those users.

The behaviour as designed allows sites that are permitted to install add-ons (so, those listed as exceptions in the security prefs) to deliver previews of a persona as well as one-click install without a confirmation prompt. We allow this to happen even when the content is hosted in an iframe because the content is coming from a secure source.

(FTR, the firstrun page on mozilla.com relies on this functionality, though that's not why it was designed this way.)
It was shocking because until now, no website could mess with my chrome like that. They could do all kinds of annoying things, but they couldn't hijack my chrome like that.
Thanks Asa.

My concern is that even though the previews only work for trusted sites, that it seems trivial to write a script that would cycle through persona previews at a rapid rate or some other incredibly annoying behaviour and post it on forums all over.

And as far as I can tell, there doesn't seem to be a way of disabling that.  (aside from the drastic step of removing getpersonas.com from your trusted sites.)
Mike: perhaps you unwhitelisted the getpersonas site? Go to the gallery and see if the mouseover works there, and if not you can change page permissions through the page-info dialog.

This page is a scraped version of Mozilla content. I guess not a copyright issue since it's CC-by-SA, but maybe some trademark confusion issue. Regardless, in the middle of the page the personas are in a frame that comes from the whitelisted personas site so it's able to do persona stuff. It's of course completely unclear that content comes from another site so it looks like lug.wsu.edu is doing it.

I can see cases where this might be useful (we didn't have to whitelist mozilla.com in order to show off this feature) but it can also be confusing and alarming to users. Should a site abuse this framing there's no (obvious) way for the user to stop it -- even if they discover the site-permission setting they can explicitly block the framing site until they're blue in the face and it'll do no good.
Summary: random websites can manipulate personas → random websites can appear to manipulate personas by framing a whitelisted site
Attached file reduced test case. (obsolete) — 
is there anyway to hide the images in the div?  that could make it even more mysterious to a user that mouses around, and give the appearance to the user that something has taken control of the PC.

Possibly leading to 

  Your browser has been hacked!  
  click here to download browser cleaner-upper tools...
I didn't even notice the iframe because it was injected by js.  If the js and the persona -both- have to come from getpersonas.com then I'm not quite as concerned.

@Chris, yes, I believe that you could hide the frame by overlaying it with an opaque layer and using pointer-events to pass events through:
  http://hacks.mozilla.org/2009/12/pointer-events-for-html-in-firefox-3-6/
dveditz, this site was set up explicitly to testcase this issue. there should be no concern over trademark, copyright, etc. Ben was trying to show me how a site that wasn't Mozilla's could manipulate Firefox chrome.
OS: Windows 7 → All
Hardware: x86 → All
Is there any real harm done? No, the effect goes away when the user leaves the page. Will the typical user understand that and say "OK, annoying site"? I don't think so, changing the chrome is clearly reaching outside the content window and raises doubts about what other evils the page could do.

Pushy sites could use this to "brand" your browser while you're on their site -- all they need is to submit a persona that's not too outrageous. Griefers could try to slip some offensive images in there, or annoy the hell out of you with quick changes.
While I agree in general that this doesn't seem like a big issue, I also don't see any significant reason here why the current behavior can't be changed to just avoid this issue altogether.
Change to what?
(In reply to comment #5)
> Why was it shocking? Web designers can do many things that are a nuisance for
> users, at the cost of losing or annoying those users.

Yes, but where those things are not limited to the content area, we very much tend to consider them bugs.  I think this is unpleasantly surprising *browser* behaviour for users, not just unpleasant site behaviour.

We should look for ways to mitigate it, possibly just by frame-busting on the getpersonas site.
cc'ing webdev

I'm getting swayed by the arguments, I think. Framebusting sounds like a good solution.
So, what about framebusting but with an exemption for www.mozilla.com (and various staging sites) so we can continue to use the iframe. Is that possible?
I agree that while this behaviour was basically intentional (at least, inasmuch as we knew an iframe approach would work for the firstrun page) and while I can't see a real security risk to it (or we would have ruled it out altogether), it's still pretty irritating, and would be nice to see it mitigated.

We shouldn't rule out client side changes if need be, but give that there are only two sites trusted to do this (AMO and getpersonas), something web-side like framebusting might well be enough.  As reed says, it would be particularly nice if this could be done in a way that didn't hurt the firstrun experience (which people seem to love).

Adding getpersonas/AMO folk.
Wouldn't have to be frame-busting, the site could just not send the persona-changing events unless it's got proof that it's safe to do so, e.g. self==top OR document.referrer.match("^https?://([^/]*)")[1] == "www.mozilla.com".

Could also go HTML5 and try postMessage() since we get an origin out of that, but that seems needlessly complex.
I agree it's annoying and could be seen as some sort of security problem by an average user. Pretty sure we could do some detection via JS, but honestly this was going to be a 'feature' to allow users to share their personas on their own websites. Wondering if there's any other options.
(In reply to comment #20)
> I agree it's annoying and could be seen as some sort of security problem by an
> average user. Pretty sure we could do some detection via JS, but honestly this
> was going to be a 'feature' to allow users to share their personas on their own
> websites. Wondering if there's any other options.

Yeah, for me I think the idea of making getpersonas a privileged path, like AMO is, makes sense and I don't think we hurt personas as a feature by saying that if you host your persona elsewhere, you don't get previews unless the user changes your site's permissions. It's not like we're talking about making it impossible for third parties to host or install - the experience is just more irritating because that's our defense against nuisance. A hypothetical otherpersonas.com that was hosting a large number of them would have to convince users to extend them similar trust, after which things would work identically.

That being said, then, I think dveditz's suggestion has merit, +/- the unreliability of referrer.
FWIW, using the latest trunk build and hovering over the images on the "fake" website does change my chrome but on getpersonas.com it does.  Using 3.6, both sites change the chrome.
I don't think postMessage should be hard here, and it gives a useful basis for an API richer than <script src=> or <iframe src=> to meet the other-site needs sketched above by Ryan.  That we reliably get the origin out of it means that the personas site can even include site identity in a prompt for installation, etc.
(In reply to comment #23)
> I don't think postMessage should be hard here, and it gives a useful basis for
> an API richer than <script src=> or <iframe src=> to meet the other-site needs
> sketched above by Ryan.  That we reliably get the origin out of it means that
> the personas site can even include site identity in a prompt for installation,
> etc.

You're thinking that if self != top we disable previews unless we get a postMessage that says something like "here's my ID, check your in-house whitelist and decide whether or not to enable previews?" That would be downright swell, I rather suspect, and does give us forward flexibility, too.
Yeah, I'm thinking exactly that.
(In reply to comment #22)
> FWIW, using the latest trunk build and hovering over the images on the "fake"
> website does change my chrome but on getpersonas.com it does.  Using 3.6, both
> sites change the chrome.
Same thing with a new profile on trunk.  So maybe this bug was somehow fixed unknowingly on the trunk in some other bug?
another nice testcase just hit digg: "Persona-jacking"

http://dl.dropbox.com/u/3011522/personas.html
Attached file rasta root kit spoof. — 
another example of the suggested attack in comment 5 that spoofs user into thinking something is wrong with their browser and solicits a fix.

the result is general confusion at best, and fear that you need to be saved from a virus at worse.
Attachment #422924 - Attachment is obsolete: true
the alignment is a bit funky, but with more playing around it could get more precise.
Can someone (perhaps Johnath) file specific, separate bugs for the implementation of whatever solution was deemed best (postMessage?) for both getpersonas.com and AMO?
Depends on: 542020
Depends on: 542022
(In reply to comment #30)
> Can someone (perhaps Johnath) file specific, separate bugs for the
> implementation of whatever solution was deemed best (postMessage?) for both
> getpersonas.com and AMO?

Filed bug 542020 (Personas & Firstrun pages) and bug 542022 (AMO).  AMO can probably roll this fix whenever because I don't think they are currently being iframed anywhere that we support (right?) but the personas fix has to work in tandem with a fix to our firstrun pages and anywhere else that does that kind of framing.
so all the examples of this use the demo iframe at http://www.getpersonas.com/en-US/external/mozilla/firstrun.php  

has anyone played with putting individual personas in an iframe?   that would be a short cut to the spoofing exploit, and we should make sure we defend against that as well.
@chris:  About what you'd expect.  You could get a hell of a lot more sophisticated with this if you had the motivation to spend more than a few minutes on it.

http://lug.wsu.edu/~ben/personaJack.html
http://lug.wsu.edu/~ben/personaJackExtra.html
(In reply to comment #32)
> has anyone played with putting individual personas in an iframe?

Chris: see my attachment 422935 [details] from comment 12. I guess at this point keeping it hidden is pointless.
Attachment #422935 - Attachment is private: false
personas changed the site, breaking my PoC: the anchor doesn't work when the persona page is inside a frame.

See http://www.getpersonas.com/en-US/persona/65437#maincontent
vs
data:text/html,<iframe src="http://www.getpersonas.com/en-US/persona/65437#maincontent"></iframe>
Summary: random websites can appear to manipulate personas by framing a whitelisted site → random websites can manipulate personas by framing a whitelisted site
Group: core-security
We were talking about this last week. I think this is fairly security critical, even if you can't inject code. Text can be overlayed over the UI, pretending a site is safe and such.
Group: core-security
For the record, I would prefer to hide this bug for further discussion but it seems a decision was made not to, so I will not hide it.
Marking sg:moderate due to potential for spoofing of browser security indicators.  For example, we already have at least one persona submitted for a bank identity (http://www.getpersonas.com/en-US/persona/82571 corresponds to www.erstebank.at).  Great fodder for phishing.
Whiteboard: [sg:moderate]
Its a bit far fetched but lucas and I were also talking about the possibility of a green bar-ish, or blue bar-ish, and/or larry-ish looking persona.   it would be hard to get it looking exactly right but with enough work it might be close enough to fool a few people that they were on a secure connection.
First, [sg:moderate] seems pretty high to me, given the descriptions of security rankings as listed here https://wiki.mozilla.org/Security_Severity_Ratings I would expect this to be [sg:low].

Second, with the changes made to the by-default whitelisted sites, this now becomes a two stage social attack, correct? Just want to make sure everyone's aware that it's not as easy as dropping an iframe into arbitrary HTML. The attacker must now convince the user to add some site to the software whitelist. Not impossible, but much tougher with the default preferences we have in Firefox.
(In reply to comment #40)
> First, [sg:moderate] seems pretty high to me, given the descriptions of
> security rankings as listed here
> https://wiki.mozilla.org/Security_Severity_Ratings I would expect this to be
> [sg:low].

Oh, sorry, I see how it could be considered [sg:high] if one could take over the entire URL bar. You can't, really, with the way Personas work today, but if the way to represent that is to hedge and say [sg:moderate] then OK. I would think we'd want [sg:high?] to represent the potential, though. Obviously my understanding of how these rankings work is shakey.
From a quick skim, I can't reproduce this with the URL in this bug. Did we fix this, or did something else just make it stop working as "expected"?
(In reply to Justin Dolske [:Dolske] from comment #42)
> From a quick skim, I can't reproduce this with the URL in this bug. Did we
> fix this, or did something else just make it stop working as "expected"?

Yep, fixed via bug 542020.
Status: NEW → RESOLVED
Closed: 13 years ago
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: