Start page can access chrome with javascript

RESOLVED INVALID

Status

()

RESOLVED INVALID
9 years ago
6 years ago

People

(Reporter: pvnick, Unassigned)

Tracking

3.0 Branch
x86
Linux
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [sg:high] Ubuntu Firefox only)

(Reporter)

Description

9 years ago
This may be a bug with Ubuntu, in which case please close this bug. When Ubuntu loads Firefox 3.0.12, it starts at chrome://ubufox/content/startpage.html, which redirects to HOMEPAGE_ONLINE.

After redirected, type javascript:history.back(), or worse yet, type javascript:window.home() from any website, and the browser will navigate back into the chrome security context, which is improper behaviour. Combine this with a cross site scripting vulnerability and the attacker now has full security privileges.
Sounds like a problem with ubufox. cc'ing asac and fta.

Updated

9 years ago
Whiteboard: [sg:high] Ubuntu Firefox only
Would love to see some motion here - it's one of only 3 live [sg:high] bugs. Does the page really need the pref access (which I assume is the reason for taking chrome privilege in the first place)? asac, fta?
We could just file an upstream bug in Ubuntu's launchpad and close out this bug, as it doesn't affect any build that mozilla.org actually makes.
Filed downstream as https://bugs.launchpad.net/firefox/+bug/455474.

Marking this bug as INVALID.
Status: NEW → RESOLVED
Last Resolved: 9 years ago
Resolution: --- → INVALID

Comment 5

9 years ago
any hints how to do this better?

maybe an about:start handler like thing?

Comment 6

9 years ago
(In reply to comment #2)
> Would love to see some motion here - it's one of only 3 live [sg:high] bugs.
> Does the page really need the pref access (which I assume is the reason for
> taking chrome privilege in the first place)? asac, fta?

the pref access atm is need to find the right locale in case we go to the offline page.
Thanks for filing the downstream bug, reed.

(In reply to comment #5)
> any hints how to do this better?
> 
> maybe an about:start handler like thing?

The typical approach we use when a content page requires chrome capabilities is to make the page itself unprivileged (so as to avoid these attacks), but give it help from "up in chrome". If you could, for instance, modify the homepage url to be:

chrome://ubufox/content/startpage.html?locale=en-US

then your unprivileged page content could parse the arguments out of the URL and make the appropriate determination without needing to access prefs directly.

(Aside: Typically when we need to do that, we just put %LOCALE% in the url, and then ensure that code which is handling that URL passes it through the url formatter ( http://mxr.mozilla.org/mozilla-central/source/toolkit/components/urlformatter/public/nsIURLFormatter.idl ) but homepages don't get that treatment, currently. Still, it's another thing to consider - there might be a risk to urlformatting the homepage that I'm not really seeing right now, but outside of that, I don't see why we couldn't start urlformatting it.)
Note that we currently set locale-specific start pages at repack time.

http://mxr.mozilla.org/mozilla-central/source/other-licenses/branding/firefox/locales/browserconfig.properties

__AB_CD__ is preprocessed into the locale code (en-US by default, other locales done through repacking).

However, I don't think that will work for Ubuntu due to how they handle locales, but there might be a way...
After discussion with reed and gavin, I think I have a better idea for you, asac:

So first, you drop privileges on your start page, and you don't do any locale magic either, just a simple page that does the XHR check to see if you're online, and if so, goes there, and if not, goes to about:offlinestart (you'll need to register this as an about page, since unprivileged pages can't redirect to file:/// urls)

When you implement the about module, you have to supply a newChannel method. This is where you drop privilege, but it's also where you supply the actual content for the page, and this code has privilege. So you can check the pref, use that to construct a locale-specific chrome: or resource: or whatever url to use in the channel, drop the about pages privileges, and be off to the races - no privilege anywhere, no crazy build tricks.

Make sense?
Basically this, with some pref magic around the ios.newChannel call:

http://hg.mozilla.org/mozilla-central/annotate/ab6c401333dc/browser/components/certerror/aboutCertError.js#l55

(sorry for the lack of mxr linkage, that file's since been deleted)

Comment 11

9 years ago
(In reply to comment #9)
> 
> So first, you drop privileges on your start page, and you don't do any locale
> magic either, just a simple page that does the XHR check to see if you're
> online, and if so, goes there, and if not, goes to about:offlinestart (you'll
> need to register this as an about page, since unprivileged pages can't redirect
> to file:/// urls)
> 

Thanks Johnathan for your thoughts and hints on this. Only thing I am unsure about is how to make the initial page available using a chrome://xxx/content/... while keeping it unprivileged. If thats not possible, how would you suggest shipping the entry page?
(In reply to comment #11)

> Thanks Johnathan for your thoughts and hints on this. Only thing I am unsure
> about is how to make the initial page available using a
> chrome://xxx/content/... while keeping it unprivileged. If thats not possible,
> how would you suggest shipping the entry page?

Make it an about page, too? Direct linking to chrome: URLs isn't something we make a habit of - I suspect the odd-looking URLs will confuse users, and it also constrains your options in terms of things like privilege. By contrast, we use about: pages reasonably ubiquitously.

Honestly, you could probably simplify this even more:

Create one about page called about:start or about:ubuntuhome or whatever that:

- drops privilege
- has the correct localized content using the trick described in comment 9
- does the XHR check on load
  - if the XHR succeeds (user is online), redirects to your online start page, same experience as now
  - if the XHR fails, just sits on the current page which, thanks to the localization hijinx, already has the correct content (no more redirect to a second locally hosted page)

Under the covers, you still have multiple locales, but the experience is just a single about:start page that just always does the right thing, without any security complications.

Am I still speaking sanely?

Comment 13

9 years ago
(In reply to comment #12)
> 
> Honestly, you could probably simplify this even more:
> 
> Create one about page called about:start or about:ubuntuhome or whatever that:
> 
> - drops privilege
> - has the correct localized content using the trick described in comment 9
> - does the XHR check on load
>   - if the XHR succeeds (user is online), redirects to your online start page,
> same experience as now
>   - if the XHR fails, just sits on the current page which, thanks to the
> localization hijinx, already has the correct content (no more redirect to a
> second locally hosted page)
> 
> Under the covers, you still have multiple locales, but the experience is just a
> single about:start page that just always does the right thing, without any
> security complications.
> 
> Am I still speaking sanely?

Yes, thanks. i will check this out ...
Group: core-security
You need to log in before you can comment on or make changes to this bug.