navigator.plugins leaks path names

VERIFIED FIXED in mozilla1.0.1

Status

()

VERIFIED FIXED
18 years ago
15 years ago

People

(Reporter: bbaetz, Assigned: dveditz)

Tracking

({privacy})

Trunk
mozilla1.0.1
privacy
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

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

Attachments

(1 attachment)

(Reporter)

Description

18 years ago
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

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

Comment 2

17 years ago
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

17 years ago
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?
(Reporter)

Comment 4

17 years ago
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

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

Comment 6

17 years ago
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. ***

Comment 8

17 years ago
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
(Reporter)

Comment 10

17 years ago
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

17 years ago
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

Comment 13

17 years ago
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]

Comment 14

17 years ago
making adt2 rtm per discussion with Mitch.
Whiteboard: [adt1 rtm] → [adt2 rtm]
->dveditz
Assignee: mstoltz → dveditz
(Assignee)

Updated

17 years ago
Status: NEW → ASSIGNED
(Assignee)

Comment 16

17 years ago
Created attachment 88082 [details] [diff] [review]
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

17 years ago
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

17 years ago
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.

Comment 20

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

Comment 21

17 years ago
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?
(Assignee)

Comment 22

17 years ago
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 23

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

sr=alecf
Attachment #88082 - Flags: superreview+

Comment 24

17 years ago
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
(Assignee)

Comment 25

17 years ago
Checked in on trunk. Please verify
Status: ASSIGNED → RESOLVED
Last Resolved: 17 years ago
Resolution: --- → FIXED

Comment 26

17 years ago
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?
(Assignee)

Comment 27

17 years ago
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

Comment 28

17 years ago
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

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

Comment 30

17 years ago
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+

Comment 31

17 years ago
Marking as verified per Comment #28 From shrirang khanzode.
Status: RESOLVED → VERIFIED
Whiteboard: [adt2 rtm] [ETA 06/25] → [adt2 rtm] [ETA 06/26]

Updated

17 years ago
Attachment #88082 - Flags: approval+

Comment 32

17 years ago
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+
(Assignee)

Comment 33

17 years ago
Checked into the branch
Keywords: mozilla1.0.1+ → fixed1.0.1
(Assignee)

Comment 34

17 years ago
Opening bug as discussed earlier
Group: security?

Updated

17 years ago
Keywords: fixed1.0.1 → verified1.0.1
You need to log in before you can comment on or make changes to this bug.