Comments on: Firefox File Handling Woes

By: parts

parts — Wed, 23 Jul 2008 08:00:38 +0000

Damont said:

I’m using the following settings to prevent FF from calling external applications without user interaction:

user_pref(”network.protocol-handler.external-default”, false);
user_pref(”network.protocol-handler.external.mailto”, false);
user_pref(”network.protocol-handler.external.news”, false);
user_pref(”network.protocol-handler.external.nntp”, false);
user_pref(”network.protocol-handler.external.snews”, false);

When I click on, e.g., a mailto link, nothing happens, but I can still copy the e-mail adress to my mail client manually . . .

settings doesn’t work

By: Holidays in Egypt

Holidays in Egypt — Tue, 15 Apr 2008 20:09:32 +0000

At least Firefox handles this well

By: ascii

ascii — Tue, 09 Oct 2007 17:14:32 +0000

External protocol security for FF

http://www.ush.it/2007/07/25/clientside-security-hardening-mozilla-firefox/

convert to the proper user_pref();

By: Simon

Simon — Sat, 08 Sep 2007 15:06:30 +0000

NB: A better work-around would be to toggle the following prefs instead:

user_pref(“network.protocol-handler.warn-external.mailto”, true);
user_pref(“network.protocol-handler.warn-external.news”, true);
user_pref(“network.protocol-handler.warn-external.nntp”, true);
user_pref(“network.protocol-handler.warn-external.snews”, true);

With those set, you’ll still be able to use all URI protocols, but get a chance to review the URIs first and cancel anything suspicious.

By: Benny K (Security4all)

Benny K (Security4all) — Fri, 07 Sep 2007 15:50:40 +0000

Put ‘network.protocol-handler.external’ in the filter and put the unused URI to false.

By: EL-Equipo » Blog Archive » Firefox File Handling Woes

EL-Equipo » Blog Archive » Firefox File Handling Woes — Thu, 06 Sep 2007 13:00:15 +0000

[...] We contacted Mozilla a while ago about the issue and they are working on it. We’re going to refrain from giving out the exact details of how this particular issue is executed (based mainly on the efforts and conversations we’ve had with Jesse Ruderman), but we’ll include a screenshot of a payload in action. In the screenshot below, we use the mailto URI, which passes the URI to the Windows File Handler, which calls the appropriate program (in this case Windows Scripting Host), which in turn calls our attacker controlled file. We’ve purposely pointed the Windows Scripting Host to a file that doesn’t exist as the error message allows the user to see that WSH is using the URI passed from Firefox. Quelle [...]

By: Damont

Damont — Thu, 06 Sep 2007 12:59:31 +0000

I’m using the following settings to prevent FF from calling external applications without user interaction:

user_pref(“network.protocol-handler.external-default”, false);
user_pref(“network.protocol-handler.external.mailto”, false);
user_pref(“network.protocol-handler.external.news”, false);
user_pref(“network.protocol-handler.external.nntp”, false);
user_pref(“network.protocol-handler.external.snews”, false);

When I click on, e.g., a mailto link, nothing happens, but I can still copy the e-mail adress to my mail client manually . . .

By: CHIP Online 0-security-blog » Blog Archiv » Firefox plagt immer noch die URI-Lücke

Thu, 06 Sep 2007 12:08:19 +0000

[...] hingewiesen habe, dass die URI-Lücke in Firefox 2.0.0.6 geschlossen ist. Jetzt muss ich im Blog von Billy (BK) Rios lesen, dass das Problem immer noch existiert. Kurz zusammengefasst: Es gibt immer noch einige [...]

By: MattLee

MattLee — Wed, 05 Sep 2007 18:27:45 +0000

is there a way threw about:config to prevent such security flaws? i know using about:config you can reduce firefox memory, how about security issues?

By: Resuna

Resuna — Wed, 05 Sep 2007 17:06:08 +0000

This appears to be another side effect of a general problem that both Apple and Microsoft have created.

The real problem is that the OS doesn’t provide a way for applications to publish whether they are designed for sandboxed use or not. They have only one set of file type bindings (or only one mechanism to invoke handlers) for local use (say by Windows Explorer or Finder) and for use by documents in a sandbox (that would be used by browsers, mail software, and so on). So applications have to guess at what is safe or not, *or* maintain their own list of safe applications.

All browsers using the native application bindings on Windows and OS X have been subject to this attack in the past. And they will remain subject to this attack in the future. The ONLY solution is to set up separate lists of applications to handle documents, and for these applications to use the “sandboxed list”. If the OS vendor doesn’t provide a mechanism to distinguish between sandboxed and unsandboxed applications and APIs, then the only guaranteed method of preventing this class of attack is to set up a separate set of bindings and lobby helper application developers to register with it.