88183 - navigator.plugins leaks path names

Status: VERIFIED FIXED

(Core Graveyard :: Plug-ins, defect)

Description

[Bradley Baetz (:bbaetz)]

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.

Comment 1

[Peter Lubczynski]

Note: On Mac, you only get the filename, no path, in about:plugins.

Comment 2

[av (gone)]

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?

Comment 3

[Peter Lubczynski]

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?

Comment 4

[Bradley Baetz (:bbaetz)]

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.

Comment 5

[Jesse Ruderman]

*** Bug 144860 has been marked as a duplicate of this bug. ***

Comment 6

[Jesse Ruderman]

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.

Comment 7

[Brendan Eich [:brendan]]

*** Bug 145635 has been marked as a duplicate of this bug. ***

Comment 8

[Manko]

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?

Comment 9

[Mitchell Stoltz (not reading bugmail)]

back to mstoltz

Comment 10

[Bradley Baetz (:bbaetz)]

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.

Comment 11

[Manko]

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".

Comment 12

[Mitchell Stoltz (not reading bugmail)]

Nominating for 1.0.1 (I think).

Comment 13

[scottputterman]

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.

Comment 14

[scottputterman]

making adt2 rtm per discussion with Mitch.

Comment 15

[Mitchell Stoltz (not reading bugmail)]

->dveditz

Comment 16

[Daniel Veditz [:dveditz]]

Attachment: Show only the leaf name by default

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.

Comment 17

[Manko]

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 18

[Peter Lubczynski]

Comment on attachment 88082 [details] [diff] [review]
Show only the leaf name by default

r=peterl

Comment 19

[Mitchell Stoltz (not reading bugmail)]

[e-mail]: 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.

Comment 20

[Peter Lubczynski]

*** Bug 152652 has been marked as a duplicate of this bug. ***

Comment 21

[Manko]

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?

Comment 22

[Daniel Veditz [:dveditz]]

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.

Comment 23

[Alec Flett]

Comment on attachment 88082 [details] [diff] [review]
Show only the leaf name by default

sr=alecf

Comment 24

[Jaime Rodriguez, Jr.]

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.

Comment 25

[Daniel Veditz [:dveditz]]

Checked in on trunk. Please verify

Comment 26

[shrirang khanzode]

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?

Comment 27

[Daniel Veditz [:dveditz]]

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).

Comment 28

[shrirang khanzode]

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.

Comment 29

[shrirang khanzode]

os x and 9.2 on trunk 0624 is fine as well. I see plugins listed like the way 
they were b4.

Comment 30

[Paul Wyskoczka]

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

Comment 31

[Jaime Rodriguez, Jr.]

Marking as verified per Comment #28 From shrirang khanzode.

Comment 32

[Judson Valeski]

please checkin to the 1.0.1 branch. once there, remove the "mozilla1.0.1+"
keyword and add the "fixed1.0.1" keyword.

Comment 33

[Daniel Veditz [:dveditz]]

Checked into the branch

Comment 34

[Daniel Veditz [:dveditz]]

Opening bug as discussed earlier