Closed Bug 98298 Opened 23 years ago Closed 6 years ago

do not have stringbundle access from about:plugins

Categories

(Core :: Security, defect, P1)

Product:
Core
Component:
Security
Type:
defect

Tracking

()

Status:
RESOLVED WONTFIX
Milestone:
Future

People

(Reporter: ftang, Assigned: dveditz)

References

(
URL
)

Details

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
this one is blocking 56863
Blocks: 56863
Severity: normal → major
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 ?
Keywords: nsbranch
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?
Status: NEW → ASSIGNED
Keywords: nsbranch
The security bug that led to this problem was 88087.
>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?
>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. 
> 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.
Priority: -- → P1
Target Milestone: --- → mozilla0.9.5
>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?)



time marches on. Retargeting to 0.9.6.
Target Milestone: mozilla0.9.5 → mozilla0.9.6
>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.

Moving the most time-critical bugs and minor security fixes to 0.9.7
Target Milestone: mozilla0.9.6 → mozilla0.9.7
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
Target Milestone: mozilla0.9.7 → mozilla0.9.9
Mozilla1.0
Target Milestone: mozilla0.9.9 → mozilla1.0
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 adt@netscape.com.  You can search for
"Moving bugs not scheduled for a project" to quickly delete this bugmail.
Target Milestone: mozilla1.0 → mozilla1.2
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.
Summary: do not have XPConnectUniversial access from about:plugins → do not have stringbundle access from about:plugins
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.
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.
Futuring.
Target Milestone: mozilla1.2alpha → Future
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 :(
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?
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!
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.
Assignee: security-bugs → dveditz
Status: ASSIGNED → NEW
QA Contact: bsharma → toolkit
Dan, I guess we can close it now ? ;)
Flags: needinfo?(dveditz)
Status: NEW → RESOLVED
Closed: 6 years ago
Flags: needinfo?(dveditz)
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.