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. ***
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.
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]
Assignee: mstoltz → dveditz
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.
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+
email@example.com: 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.
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.
Whiteboard: [adt2 rtm] → [adt2 rtm] [ETA 06/25]
Target Milestone: --- → mozilla1.0.1
Checked in on trunk. Please verify
Status: ASSIGNED → RESOLVED
Last Resolved: 17 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).
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]
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
You need to log in before you can comment on or make changes to this bug.