295018 - Search plugins can't use local files anymore

Status: RESOLVED WONTFIX

(Firefox :: Search, defect)

Description

[Xavier Robin]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; fr-CH; rv:1.7.8) Gecko/20050511 Firefox/1.0.4
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; fr-CH; rv:1.7.8) Gecko/20050511 Firefox/1.0.4

Due to Bug 290037 local search doesn't work in Firefox >= 1.0.3.

This means that searchplugins like :
<search
name="...."
action="file://///machine/search.html" 

or :
<search
name="...."
action="file://d:/machine/search.html"

just stopped working when switching to Firefox 1.0.3. This is a major problem
for companies that developped searchplugins based on the file:// protocol.

Reproducible: Always

Steps to Reproduce:




File protocol should be re-enabled or at leaste there should be a pref to enable
it if needed.

Comment 1

[kungfx]

Yes !
Why block local URl in search plugins ??? It s important for development
into a compagny or univerties (...) to keep local URL (or not)in a search plugin.

Perhaps create an option (in about:config) to check YES or NO this security
limitation...

Comment 2

[Jean-Marc Desperrier]

I'm not sure this is going to be reenabled, but we should suggest a migration
option, maybe indicate how to create an extension to do such searches ?

Comment 3

[Daniel Veditz [:dveditz]]

I'm not against whitelisting file:, which would be a simple change to the patch
in bug 290037
-        !StringBeginsWith(action, NS_LITERAL_STRING("https:")))
+        !StringBeginsWith(action, NS_LITERAL_STRING("https:")) &&
+        !StringBeginsWith(action, NS_LITERAL_STRING("file:")))

The file: could point back at the attacker's server, but if someone convinces
you to install their search plugins in order to spy on your search requests they
could do that just as easily with http:

I'll nominate for 1.0.5 because it's a regression, but likely only security
fixes will be taken for the branch.

Comment 4

[Daniel Veditz [:dveditz]]

Attachment: allow file: as a search plugin action

Comment 5

[Christopher Aillon (sabbatical, not receiving bugmail)]

Comment on attachment 184346 [details] [diff] [review]
allow file: as a search plugin action

Hmm, you'd think that after all the issues people constantly have with file:
uris, they would stop using them and just set up an intranet web server.
r=caillon

Comment 6

[Daniel Veditz [:dveditz]]

Not holding up a 1.0.x security release

Comment 7

[kungfx]

This regression is a security problem : 

We use some local search plugins in the search bar in my compagny into Firefox
1.0.2, we can't upgrade to FF 1.0.4 because this bug. So we have some security
problems (resolved in upgrading Firefox 1.0.4) !

Same problems in university, we need used 2 Firefox versions, the first one
FF 1.0.2 for internal use only (with local search), and FF 1.0.4 for Net use (with
all recent securities)...... VERY BAD REGRESSION.

Comment 8

[Asa Dotzler [:asa]]

Comment on attachment 184346 [details] [diff] [review]
allow file: as a search plugin action

1.0.5 has already shipped; unsetting approval request.

Comment 9

[Darin Fisher]

Not going to block 1.8.1 for this bug.  It looks like there hasn't been interest in landing the current patch on the trunk even.

Comment 10

[:Gavin Sharp [email: [e-mail]]]

Unless this is a SeaMonkey bug, this has already been FIXED. The new Firefox search service that is shipping in Firefox 2 has no such restrictions.

Comment 11

[:Gavin Sharp [email: [e-mail]]]

This was filed against Firefox, so moving there.

Comment 12

[:Gavin Sharp [email: [e-mail]]]

Turns out that the Firefox 2 search service still has this bug.

Comment 13

[:Gavin Sharp [email: [e-mail]]]

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

Comment 14

[Mike Connor [:mconnor]]

This doesn't seem useful, in general.  One can run a local webserver easily enough, which is more likely the case for testing a search service, vs. a static file on disk.

Comment 15

[kungfx]

Yes it's easy to run and use searchplugin with a local web server, but this restriction impose a web server environment.

For example, in my university, we need to distribute some portables CD-ROM including lessons in ".htlm" format. So it's not possible for all students to use webserver to explore these portable distributions. Such a shame .

Firefox it's not restricted just for net or local server environment, why not to have choice with an "about:config" option ? 

Comment 16

[A. Sel.]

What in general is speaking against allowing "file" or at least "chrome" as a scheme compared to "http"?

Why restrict the scheme anyway? In the end, all that the nsSearchService does, is constructing a URL based on the search-terms and the URL-template defined in the SearchPlugin ... and load this URL in the browser. 

I, f. ex., defined my own ProtocolHandler in an extension and would love to use a search-plugin for my own scheme. 

I am eager to know the reasons for this restriction.

Thanks!

Comment 17

[A. Sel.]

[Update]

I understand blocking "javascript:" and maybe data (because it can be used for javascript as well) as both open up security issues. 

Can't we just check for those and allow everything else?

Cheers.

Comment 18

[:Gavin Sharp [email: [e-mail]]]

If you combine the ability to cause certain URIs to be loaded (i.e. using a search plugin that you've convinced the user to install) with an XSS vulnerability, then you have a potentially serious problem.

Granted, that scenario is a bit far fetched and unlikely to be a problem in practice. But no one has come up with very compelling use cases for allowing additional schemes that can't be addressed in other ways, so from my point of view there's little benefit in loosening the restrictions.

Comment 19

[A. Sel.]

But to be able to load certain URI's, Firefox needs to know the protocol. And custom protocol-handlers can only be added via extension. So in your scenario the bad guy has to convince the user to install the extension AND the search plugin. 

If he got the user to install his extension, he can already do any harm he wants - he doesn't need an additional search-plugin and any XSS vulnerability.

Even if you don't want to allow all protocols, what speaks against adding "chrome"?

Thanks for your response!

Comment 20

[A. Sel.]

[Update - again]

I was partially wrong about the ProtocolHandlers, as the bad guy could also convince the user to install a Web-ProtocolHandler (+ the search-plugin; a lot of convincing to do for the poor guy). Anyway, you could check if the search-plugin url leads to a Web-ProtocolHandler and not allow it in that case.

We would need to add a member to nsIDOMClientInformation to retrieve a list of registered Web-ProtocolHandler's.

That's really a bit of work (although it shouldn't be too much), so let's first take a look at allowing "chrome" for which you also would need an extension to be able to do harm.

Cheers.

Comment 21

[:Gavin Sharp [email: [e-mail]]]

I'm not worried about custom protocol handlers, I'm worried about some of our defaults. Being able to load chrome:// or moz-image:// or any number of other built-in handlers could be problematic.

Comment 22

[A. Sel.]

Oh. Now you are surprising me! ;)

The only situation I can think of, where a SearchPlugin can do harm by using a "chrome"-URL is, when there is already an existing standard-Firefox xul-file or whatever that will do this harm when being opened in the browser. And for moz-icon, I can't even imagine anything problematic when opening such a URL.

What kind of security issues are you thinking about?

Thanks for this discussion!

Cheers,
André

Comment 23

[:Gavin Sharp [email: [e-mail]]]

As I mentioned earlier, the ability to load chrome:// URIs combined with an XSS vulnerability. I don't really want to dive into the security implications here - perhaps you should focus on describing what you want to accomplish that requires this bug to be fixed :)

Comment 24

[A. Sel.]

Alright, that might be easier. :)

For my extension I basically need a searchplugin that opens up a page which has chrome-access. that's why i have written my own protocolhandler that will create a xul-page based on the input it gets (the search-term). There are some more reasons for this protocolhandler to exist, but they are not important here ...

So what i am trying to accomplish, is to be able to use this protocol in the searchplugin:
<Url type="text/html" method="GET" template="my-search:{searchTerms}"/>

Unfortunately nsSearchService has the hard-coded restriction for "http" and "https" in it.

Comment #15 already proposed to have a about:config-preference for additional allowed protocols. Makes sense to me. 

Alternatively nsSearchService could also get a new method addAllowedProtocol("my-search"), which the extension-developer can call on startup.

In both cases you could still forbid some default-protocols like chrome, if you really really don't want those to be usable.

What do you think?

Cheers.