Closed Bug 88183 Opened 23 years ago Closed 22 years ago

navigator.plugins leaks path names

Categories

(Core Graveyard :: Plug-ins, defect)

Product:
Core Graveyard
Component:
Plug-ins
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
VERIFIED FIXED
Milestone:
mozilla1.0.1

People

(Reporter: bbaetz, Assigned: dveditz)

References

(
URL
)

Details

(Keywords: privacy, Whiteboard: [adt2 rtm] [ETA 06/26])

Attachments

(1 file)

Show only the leaf name by default
2.78 KB, patch
peterlubczynski-bugs
: review+
alecf
: superreview+
jud
: approval+
Details | Diff | Splinter Review 
Going to the above page (which is our about:plugins page, served from an http
url), shows that we are giving out the full path of the plugin. If you're
running a copy of the browser installed in your home directory, then this will
give any web page your username. If bug 45699 is ever fixed (allowing plugins on
a per-profile basis), this will presumably also leak the profile path (including
salt).

Bug 9323 deals with the fact that we were only giving out the filename, not the
full path. I think that this fix should be reverted, at least for
non-signed/chrome scripts. Even though ns4 gives out the full path, I don't see
why a web page should be allowed to access this, or what we can break by
disallowing it, but I'm willing to be convinced. Theres not much point in a
salted profile directory if anyone can find the salt, though. And you can do fun
stuff if you know the full path to a users home directory, together with any
other security bugs which may exist.

I got convinced to file this as nsconf based on the privacy/security issues (And
the lack of a useful security bug group). I'm not strongly attached to that
argument though, especially since ns4 leaks this info as well, so feel free to
open this up if you disagree.
Note: On Mac, you only get the filename, no path, in about:plugins.
So, now as we have a separate mFullPath member in nsPluginTag, would it make 
sense to not to store the full path in mFileName on Windows and Unix?
We should probably use something like nsIFile in nsPlugingTag and then get the
path from that.

Can a user get the full path without going to about:plugins? This would be bad
if profile-based plugins gave away the profile path, but otherwise, I don't see
any problems in revealing the path to the plugin DLL?
Yes, they can use navigator.plugins from js - thats how the about:plugins works.
Go to the lxr url - thats an html page served from http which will be identical
to the about:plugins page. (lxr doesn't print its headers for html files)

Is there a reason for this to be a non-public bug? See my last paragraph in
comment 0.
*** Bug 144860 has been marked as a duplicate of this bug. ***
Changing from Netscape confidential to security-sensitive.  I think this bug
should be public because it's easy to discover and because it's been open for 10
months.
assignee_accessible: 0 → 1
Group: netscapeconfidential? → security?
CC list accessible: true
qacontact_accessible: 0 → 1
Accessible to reporter
*** Bug 145635 has been marked as a duplicate of this bug. ***
I'm webmaster and I fully support Reporter. I can't see any reasons to allow
JavaScript in Web pages to read pathnames and filenames of plugins, unlike
description or MIME types.

About "Help/About plugins" menu item:

In my opinion, this item should be removed from Help menu and transferred to
Preferences menu (probably it might be placed beside Images item). And user
should be enabled to switch each plugin (or even each MIME type) on or off
separately.

Maybe, for plugins, should be enabled more flexible policy like Images
(allow/deny loading from non-originating servers, alerts, permissions etc.).
This may be very useful not only for Images and Plugins, but for Iframes. In the
future, policy for Images, Iframes, Plugins and Java applets might be grouped in
special submenu in Preferences.

Sounds this reasonable and should I open new bug for this suggestion?
back to mstoltz
Assignee: av → mstoltz
So, lets open this up. We have a couple of dupes on this, and I wasn't too
convinced by Jesse's arguments to make this what was then an nsconf bug when I
filed it.

Mitch, any objections? I filed it, but I was interning for NS at the time.
Relating Bug 9323

Please, give even one reason for Web JavaScript to know filename of plugin, no
difference with or without path to plugin. I think, Plugin.filename must return
undefined value or empty string in non-chrome scripts.

I have opened bug 147866 for subsequent discussion about "Help/About plugins".
Nominating for 1.0.1 (I think).
Keywords: adt1.0.1, mozilla1.0.1
marking adt1 rtm.  Please lower the impact if you don't think it's as severe.
Removing the adt1.0.1 because there's no patch (but marking nsbeta1+ to keep on
the rtm radar).  Once you have a patch that's ready to land on the branch,
please add back the adt1.0.1 keyword.
Keywords: adt1.0.1 → nsbeta1+
Whiteboard: [adt1 rtm]
making adt2 rtm per discussion with Mitch.
Whiteboard: [adt1 rtm] → [adt2 rtm]
->dveditz
Assignee: mstoltz → dveditz
Status: NEW → ASSIGNED
Patch to show only the leafname by default. Added a pref to revert to the old
behavior for help in debugging plugin problems (example: turns out we're
loading a broken version of pluginX from some automatic scan) and also to
minimize any risk this might cause broken pages.
Good, but, IMHO, only palliative. Maybe, there is a point for using signed or
chrome script in "about:plugins" and return "undefined" for non-signed scripts?
Comment on attachment 88082 [details] [diff] [review]
Show only the leaf name by default

r=peterl
Attachment #88082 - Flags: review+
manko@zhurnal.ru: I'm not sure what you mean. Do you mean we shouldn't provide
any part of the plugin path to Web scripts? Or no plugin information at all? If
so, I consider that a separate issue - there are legitimate reasons to tell
websites which plugins are installed (if not *where* they are installed). People
who are very concerned about privacy would probably appreciate an option to not
reveal any plugin information, but that won't be the default.
*** Bug 152652 has been marked as a duplicate of this bug. ***
Replying comment #19
Of course, I mean only information about files. For Web scripts, information
about mime types and descriptions (Plugin.description and MimeTypes array) might
be useful (for example, to display movie on website in appropriate format for
user software to understand). But information about filename (even without path)
isn't needed for webmasters.

I would hope all information about my browser, which isn't significant for
correct displaying Web pages, will be hidden for Web scripts. This is simple
privacy reason, isn’t it?
This does not need to be a confidential bug, the facts on this are well known
and there are several privacy-advocate sites out there that will demonstrate
they know your plugin path in order to scare you into buying their products.
This property is documented on Netscape's website and in many books.

We are fixing this bug primarily to limit potential damage from undiscovered
future attacks, in particular since profile plugins leak the salted profile
path.   Unless someone objects I'll open up the bug when I check in.
Keywords: privacy
Comment on attachment 88082 [details] [diff] [review]
Show only the leaf name by default

sr=alecf
Attachment #88082 - Flags: superreview+
pls get this landed on the trunk. once QA has verified it as fixed, add adt1.0.1
to nominate if it for the branch.
Blocks: 143047
Keywords: approval
Whiteboard: [adt2 rtm] → [adt2 rtm] [ETA 06/25]
Target Milestone: --- → mozilla1.0.1
Checked in on trunk. Please verify
Status: ASSIGNED → RESOLVED
Closed: 22 years ago
Resolution: --- → FIXED
checked on win and linux trunk 0624. I have the Codeweaver crossover plugin on 
linux. I can still see the paths to the plugins supported by it ( 
like..u/shrir/crossover/support.dotwine/jake_windows...) . Other than 
that..everything is ok on windows and linux. I cannot see any direct paths to 
any plugin anymore (only see filename). Can u chek  about crossover on linux and 
see if it might be an issue?
What's the crossover plugin? Where are you seeing full paths reported by it --
in about:plugins? in the navigator.plugins array itself? From your example it's
at least not leaking your salted profile name.

Please test the Mac, too, I want to make sure I didn't break anything as it was
slightly different from the others (already didn't show paths).
Keywords: adt1.0.1
crossover is a plugin for linux from COdeweavers.com

http://www.codeweavers.com/products/crossover/download_demo.php?dl=1

Am seeing the full path in 'about:plugins'. No, doe snot leak my profile name or 
anything. Will check mac immediately.
os x and 9.2 on trunk 0624 is fine as well. I see plugins listed like the way 
they were b4.
Adding adt1.0.1+ on behalf of the adt for checkin to the 1.0 branch.  Please get
drivers approval before checking in. When you check this into the branch, please
change the mozilla1.0.1+ keyword to fixed1.0.1
Keywords: adt1.0.1 → adt1.0.1+
Marking as verified per Comment #28 From shrirang khanzode.
Status: RESOLVED → VERIFIED
Whiteboard: [adt2 rtm] [ETA 06/25] → [adt2 rtm] [ETA 06/26]
Attachment #88082 - Flags: approval+
please checkin to the 1.0.1 branch. once there, remove the "mozilla1.0.1+"
keyword and add the "fixed1.0.1" keyword.
Keywords: mozilla1.0.1 → mozilla1.0.1+
Checked into the branch
Keywords: mozilla1.0.1+ → fixed1.0.1
Opening bug as discussed earlier
Group: security?
Keywords: fixed1.0.1 → verified1.0.1
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: