98298 - do not have stringbundle access from about:plugins

Status: RESOLVED WONTFIX

(Core :: Security, defect, P1)

Description

[Frank Tang]

I try to fix 56863 and I test agaisnt chrome://global/content/plugins.html it
work fine. But while I use "Help:About plugins" or type about:plugins to that
page, it deny my access to the property . Because of that I have back out my
change to plungs.html 

to reproduce the problem 
1. in your local tree, go to xpfe/global/resources/content/
2. cvs update -r 1.4 plugins.html (to check out the version I backed out)
3. goto xpfe/global
4. nmake -f makefile.win
5. run the app and click Help:about plugins

6. type chrome://global/content/plugins.html
you will see 6 load correctly, but not 5

Comment 1

[Frank Tang]

this one is blocking 56863

Comment 2

[Frank Tang]

mstoltz: is that possible that you can fix this for us to unblock 56863 for us ?
how difficult / risk to fix this one ? we want to access string bunlde 
"chrome://global/locale/plugins.properties" from "about:plugins". Is that 
possible that you grant "UniversalXPConnnect" access to "about:plugins" ? When 
can you work on it ?

Comment 3

[Mitchell Stoltz (not reading bugmail)]

Is there any way to do localizability without XPConnect access? Alternatively,
we could make StringBundles accessible from about:plugins without requiring
XPConnect access. I'd rather do that than back out my earlier change which
removed XPConnect access from about:plugins, as that change protects us from
potential serious security problems. I will try to do that. Is this urgent? Do
you need it for 0.9.4?

Comment 4

[Mitchell Stoltz (not reading bugmail)]

The security bug that led to this problem was 88087.

Comment 5

[[e-mail] (away - not reading bugmail)]

>make StringBundles accessible from about:plugins without requiring
>XPConnect access

mstolz:

could you please do that? I believe it's a requirement from the localization
team to see localizability of the plugin page in Netscape branch builds very
soon. Would you have an ETA on this, is this going to be relatively easy to
implement?

Comment 6

[Frank Tang]

>that change protects us from potential serious security problems.
I really doubt disable XPConnect from about: page may protect us from any 
serious security problem, especially the redirect page is in chrome:// url. 

Comment 7

[Mitchell Stoltz (not reading bugmail)]

> I really doubt disable XPConnect from about: page may protect us from any 
> serious security problem

It does, and it already has. See see bugs 90386 and 88167. Can you explain the
reasoning by which you arrived at the above conclusion?

As I said above, I propose to make string bundles accessible without full
XPConnect access, if that is possible in a secure way. This should satisfy both
of our concerns.

Comment 8

[Frank Tang]

>As I said above, I propose to make string bundles accessible without full
XPConnect access
No objection to that. Do you know how to do that?

I still do not understand why about: is differ to chrome: is that true any
security hole which involve teh about: could also be reproduced by using
chrome:// url instead? If not, why ? (for example, for 88167, can the same bug
be reproduce if the page point to a chrome:// page instead of about: page?)

Comment 9

[Mitchell Stoltz (not reading bugmail)]

time marches on. Retargeting to 0.9.6.

Comment 10

[Frank Tang]

>Is there any way to do localizability without XPConnect access? Alternatively,
>we could make StringBundles accessible from about:plugins without requiring
>XPConnect access.

How? I am not aware such mechanism. I am open if you can find a way to do so.

Comment 11

[Mitchell Stoltz (not reading bugmail)]

Moving the most time-critical bugs and minor security fixes to 0.9.7

Comment 12

[Jacob Kjome]

I'm wondering if this bug is causeing both my script to display installed
plugins and about:plugins to fail with the following errors (from js console):

Error: uncaught exception: [Exception... "Component returned failure code:
0x80004005 (NS_ERROR_FAILURE) [nsIDOMPlugin.name]"  nsresult: "0x80004005
(NS_ERROR_FAILURE)"  location: "JS frame ::
http://www.visi.com/~hoju/assets/scripts/browserinfo.js ::
getExtendedBrowserInfo :: line 88"  data: no]

Error: uncaught exception: [Exception... "Component returned failure code:
0x80004005 (NS_ERROR_FAILURE) [nsIDOMPlugin.name]"  nsresult: "0x80004005
(NS_ERROR_FAILURE)"  location: "JS frame ::
jar:resource:///chrome/toolkit.jar!/content/global/plugins.html :: <TOP_LEVEL>
:: line 95"  data: no]

Are these cause by this bug, another existing bug, or is this a new bug?

jake

Comment 13

[Mitchell Stoltz (not reading bugmail)]

Mozilla1.0

Comment 14

[scottputterman]

Moving Netscape owned 0.9.9 and 1.0 bugs that don't have an nsbeta1, nsbeta1+,
topembed, topembed+, Mozilla0.9.9+ or Mozilla1.0+ keyword.  Please send any
questions or feedback about this to [e-mail].  You can search for
"Moving bugs not scheduled for a project" to quickly delete this bugmail.

Comment 15

[Robert Kaiser]

mstoltz, any chance we get stringbundle access from about:plugins soon?

I have a very cool patch for making that page localizeable (bug 56863) and
themeable (bug 131477), so that this will really fit into a modern browser - but
it's still blocked by this bug.

Comment 16

[rbs]

Maybe you should just go ahead and land your patch for bug 131477 rather than
being totally blocked and missing everything. Since you have already nicely
isolated the strings, it is easy for anyone to edit in just the header if they
want to localize.

Comment 17

[Robert Kaiser]

rbs:
I'll land that one first anyway.
Even though, L10n can't change files sitting in content, only files in locale
(en-US.jar and similar) can be safely changed. And therefore, we have to access
plugins.properties from there (which is already catched by our L10n tools and
already translated, BTW).
We just would need a safe way to access a string bundle living in chrome: from
this about:plugins page.

Comment 18

[Mitchell Stoltz (not reading bugmail)]

Futuring.

Comment 19

[Robert Kaiser]

Mitchell, does that mean you/your employer doesn't care about l12y of about:plugins?

I think that would be a shame but unfortunately I can't code well enough to make
that work myself :(

Comment 20

[Boris Zbarsky [:bzbarsky]]

I was thinking...is there a general security issue (privacy?) with content being
able to get at stringbundles? If not, we could give them classinfo and make them
accessible off somewhere like the window or document (a la
window.getSelection()).  Not the cleanest approach, but the best I can think of
that does not involve modifying CAPS.  jst?  Thoughts?

Comment 21

[Robert Kaiser]

From Comment #3 (2001-09-05, Mitchell Stoltz):
"we could make StringBundles accessible from about:plugins without requiring
XPConnect access [...] I will try to do that"

How many years do we have to wait for this?
I think there was noone against that solution here, right?
You talked about it as it was quite easy for you (it's impossible for me as I
don't know any of that code)...

Mitchell, please, give us that patch!

Comment 22

[Robert Kaiser]

timeless suggested to create a stringbundle service in similar way to how
nsSidebar.js creates window.sidebar - basically create some nsStringBundle.js in
parallel that hooks up window.stringbundle and use that for unprivileged
strindundle access. This JS code has to do the needed security checks though, so
that we can't access any stringbundle from any document.

Comment 23

[Sylvestre Ledru [:Sylvestre]]

Dan, I guess we can close it now ? ;)