Closed Bug 307626 Opened 19 years ago Closed 15 years ago

Firefox/Linux/Wine: Downloaded file is executed automatically

Categories

(Firefox :: File Handling, defect)

Product:
Firefox
Component:
File Handling
Platform:
x86
Windows XP
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED WORKSFORME

People

(Reporter: chofmann, Unassigned)

Details

(Keywords: qawanted, Whiteboard: [sg:high]) 

report from Hannes Mayer 

see below for original email]
Here is an update:

This is a simple PHP test script to demonstrate the problem:

<?
// script name: test.php
// call this script with: test.php/test.exe

header("Content-Type: audio/x-pn-realaudio");

// symlink of notepad.exe in current directory to
//   /usr/lib/wine/notepad.exe.so (in debian package wine-utils)
readfile("notepad.exe");
?>

Firefox just downloads "test.exe" and executes it immediately!
In this case notepad shows up, but could be any malicious code aswell!

Best regards,
Hannes.

---------- Forwarded message ----------
From: Hannes Mayer <debiandude@gmail.com>
Date: Aug 7, 2005 7:15 PM
Subject: Firefox/Linux/Wine: Downloaded file is executed automatically
To: security@mozilla.org


Dear Firefox-Team!

Version info: FireFox 1.0.5
OS: Linux Debian stable with WINE installed

I've just discovered something pretty scary:

While being on amazon
http://www.amazon.com/exec/obidos/tg/detail/-/B0000015KR/002-5031764-6125631?v=glance
I've clicked on
http://www.amazon.com/exec/obidos/clipserve/B0000015KR001004/1/002-5031764-6125631
(scroll down to "Listen to Samples" - "Realplayer" - "Listen"-Link)

and TATA!! Suddenly WINE came up with a window, telling me:
wine: cannot determine executable type for L"Z:\\tmp\\hurl.exe"

After following the "amazon-realplayer-link" with
http://www.rexswain.com/httpview.html

I saw that after some redirects it ends up with this:

GET /scripts/hurl.exe?~kk-600111/0009587_0104_00_0002.ra HTTP/1.1
Host: www.content.loudeye.com
Content-Type: audio/x-pn-realaudio
Content:
pnm://rm.content.loudeye.com/~kk-600111/0009587_0104_00_0002.ra

Taking a look into /tmp/hurl.exe I found that it contains
pnm://rm.content.loudeye.com/~kk-600111/0009587_0104_00_0002.ra

This is pretty alarming to me, since the realplayer URL could be some
malicious executable aswell, cause damage/data loss etc.. to the system.

If you have any further questions, just email me.

Best regards,
Hannes.
follow up questions and reponse from Hannes 

Subject:
Re: UPDATE: Firefox/Linux/Wine: Downloaded file is executed automatically
From:
Hannes Mayer <debiandude@gmail.com>
Date:
Tue, 16 Aug 2005 22:23:52 +0200
To:
Chris Hofmann <chofmann@mozilla.org>

Hi Chris!

On 8/16/05, Chris Hofmann <chofmann@mozilla.org> wrote:
[...]
> > Just to confirm, you are running the Linux version of firefox and WINE
> > seems to be picking up on the .exe extension and launches the
> > executable; is that correct?

Yes, I'm running the official Linux version of Firefox from
mozilla.org (*not* the debian package). On the amazon-page where I
discovered that problem, the application on the server providing the
real-stream is an .exe. Firefox downloaded that file, saved it as .exe
and WINE was launched to run the .exe.

> > If Firefox runs a windows version under WINE, I'm wondering if you get
> > the same response.

I'm sorry I can't test this scenario, since I don't have a Windows
installation in WINE. But I doubt that anyone is running the
Windows-Firefox under WINE on Linux anyway.
 
> > Also wondering if there are configuration settings under WINE to control
> > the launching of programs?

I dunno. Usually one has to run any windows binary with "wine
some.exe" anyway, hence my suspicion that the problem is only within
Firefox.

> > If WINE is our of the picture does the Linux Firefox handle the script
> > as expected?

If I disable wine (chmod -x /usr/bin/wine), nothing happens in Firefox.
I just tried the following:

In "Preferences - Downloads - File Types" I have
"RA    RealPlayer File    Open with"

In "Change Action"  "Open them in the Default application" was
selected. This triggered WINE to open the .exe.
But when I change the selection to "Open them in this application" and
give the path to the realplayer, the realplayer comes up and it works
as expected.

This does solve the problem that the right application is launched,
but IMO the security issue still persists. I didn't change the "Change
Action" for real-streams, so I guess this is the default setting.

Best regards,
Hannes.

> > These are the things we will start looking at.  Let me know if they seem
> > on track or you can provide some insight into the problem.
> > 
> > Thanks
> > 
> > Chris Hofmann

cbiesinger wrote:

Oh, I see... I assume this is what happened:
- No setting for audio/x-pn-realaudio anywhere (Mailcap, Gnome settings)
- A Gnome setting that maps .exe to wine

In such a case, we use the mapping from the extension... so we end up with wine
as the handler for that file.

thoughs from bz

Sounds like an interaction with gconf or some such mess too.  That is, it sounds
like WINE is registered as a default handler for .exe files, that when we look
for the default application for this case we somehow end up with it as the
"helper app" in spite of the MIME type (why?) and that WINE executes .exe files
even if they don't have the execute bit set.  No different than having "perl" as
the helper application for ".pl" files, basically.

So how are we ending up with WINE here?  Could whoever can reproduce this run:

env NSPR_LOG_FILE=/tmp/helperlog.txt NSPR_LOG_MODULES=HelperAppService:5 firefox

then reproduce the problem and see what that gives us?  I'm somewhat curious why
we get WINE as the helper here...

In any case, this is EXACTLY why we used to have a "prompt the first time"
policy for helper apps for Mozilla.  For Firefox the decision was made to not do
this, so users no longer have that protection from misconfigured OS helper app
settings.  If the file were sent as application/octet-stream instead of the type
it's using, I'd fully expect us to get the helper based on the extension and end
up with WINE in this case.

-Boris 

We do need to do _something_ about this -- this is a remote execution flaw,
basically.
Flags: blocking1.8b5?
should we stop looking up helper apps by extension? I guess that'd kinda suck...
It also wouldn't help, since the same effect can be gotten by just sending the
right MIME type from the server.
in the end, we can't really do much if the helper app wants to shoot users in
their feet, can we? we do show the dialog. (right?)
Last I checked, by default Firefox just executes the helper app, no questions
asked, no dialog shown.  But maybe that got changed?  I recall making the
argument that it should be changed, but I don't know what the result was.
Firefox should *not* be executing any helper app without asking, at least not by
default. People do want the option on the helper app dialog to check the "Always
do this action" box though.

Hey, did that change? In 1.0.6 if I click on a .wav I get the helper app dialog.
In 1.5 it just launches QuickTime (on my particular setup) without asking --
what's up?

But what have we agreed to do from the dialog? I guess we've agreed to hand that
type off to the OS, we should really be agreeing to hand off to a specific
application. And we should show which application it is to the user. If the OS
handler for that type has changed we should bring up the dialog again.
Flags: blocking1.8b5? → blocking1.8b5+
Hmm... With a clean profile 1.5 just launches?  That's odd...

And I agree that if the helper changes we should probably reask.
Flags: blocking1.8b5+ → blocking1.8b5-
looks like a good test case for checking out major releases at the least.  how is firefox 3 looking on this bug?
Marking sg:high due to critical nature of exploit mitigated by being Linux+WINE only.

Can we verify whether this still repros in FF3, or even FF2?
Whiteboard: [sg:high]
Is WINE still common enough to rate as high instead of moderate?  Based on the tiers, this looks like sg:moderate at best.  Given that it's three years old, I'd like to get QA to actually repro this so we can get real data on how this is happening...
anyone know any gconf or wine folks that might help investigate this?
CCing a few people who have reported bugs under WINE, since they might be able to help determine whether this bug still exists and/or help us figure out the right thing to do here.
Firefox trunk (20090123), wine 1.0-rc3 (opensuse 11.0 package)

I can't quite reproduce; I get a save as / cancel dialog as expected.  With fiddling I can get it to automatically download the file (by sending it as a mime type that I had otherwise set to do the default action with).  In that case, however, I get an unknown error dialog instead (probably because I haven't figured out how to get things to register with wine).

The only way I can think of that would make this happen is if the user attempted to register audio/x-pn-realaudio with RealPlayer-running-in-Wine, but did it as "wine /path/to/realplayer.exe %1" (instead of using a wrapper script); that would cause things to go haywire and attempt to launch things with wine where it was meant to be started with realplayer.
 Marking WFM based on comment 16.  But it would be nice to get concurrence, especially from Hannes.
Status: NEW → RESOLVED
Closed: 15 years ago
Resolution: --- → WORKSFORME
Group: core-security → core-security-release
Group: core-security-release
You need to log in before you can comment on or make changes to this bug.