249677 - cancel does not delete temporary file in helper app dialog, if default action = save

Status: VERIFIED FIXED

(Core Graveyard :: File Handling, defect)

Description

[Daniel Wang]

A few days ago, I encountered a Web page that attemps to install the
"sbc_netscape.xpi" spyware. I said no. Today I did a full system antivirus scan
and to my amazement the file is in my C:\Documents and Settings\<user>\Local
Settings\Temp\ .

I noticed that if you do location = URL_to_binary_file, a download prompt
appears, and the file is being downloaded silently to the temp folder. The file
is deleted, however, if you click cancel.

I speculate the attacker site did some kind of JS magic to get the file
downloaded. I'll try to find where I visited and get the code. Meanwhile, please
feel free to mark this as invalid. I just want to warn you guys first.

[reference: http://forums.mozillazine.org/viewtopic.php?p=466923#466923]

Comment 1

[Christian :Biesinger (don't email me, ping me on IRC)]

>I noticed that if you do location = URL_to_binary_file, a download prompt
>appears, and the file is being downloaded silently to the temp folder.

this is by design. (although this may change, see bug 69938)

given
>  The file is deleted, however, if you click cancel.
this is invalid.


the mozillazine link seems to be about something else (something concerning xpi
installs in general)


I'm confused by the first part of comment 0. can you explain it? that seems to
be about an XPI install dialog? are you saying that in that case, the file is
not deleted?

Comment 2

[Daniel Wang]

> I'm confused by the first part of comment 0. can you explain it? that seems to
> be about an XPI install dialog? are you saying that in that case, the file is
> not deleted?

Yes. I was prompted a XPI install dialog (not a download dialog), and somehow
the file is downloaded to the temporary directory and not deleted. I couldn't
find the page that causes this. I'll try to investigate this further.

Comment 3

[Daniel Wang]

Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8a2) Gecko/20040702
k, this is weird

location.href="http://www2.flingstone.com/cab/sbc_netscape.xpi"; gives a
download prompt dialog, and clicking cancel does not remove the file. (This is
on a Windows 2000 advanced user account.) I believe I was in an adminstrator
account when I last tested (and the file was removed).

It's possible that what I saw was a download prompt, not a install prompt.

Comment 4

[Daniel Wang]

really confirming. (sorry for the bugspam)

On the 20040702 build, cancelling download prompt does not delete the file (on
admin or adv user account). On Mozilla 1.7 final, this does not occur.

Comment 5

[Christian :Biesinger (don't email me, ping me on IRC)]

urg. I believe you're correct. -> me, probably caused by bug 244448

Does the file already have the correct filename while the dialog is still shown,
or is it something like <random string>.<ext>?

Comment 6

[Christian :Biesinger (don't email me, ping me on IRC)]

Attachment: patch

Comment 7

[Christian :Biesinger (don't email me, ping me on IRC)]

I don't think that failure to delete this file is a security issue, really. mind
if I clear the security flag?

>Does the file already have the correct filename while the dialog is still shown,
>or is it something like <random string>.<ext>?

seems to be the random filename in my testing, as expected.

Comment 8

[Daniel Wang]

it's <random string>.<ext>

> I don't think that failure to delete this file is a security issue, really. mind
> if I clear the security flag?

fine with me.

Comment 9

[Johnny Stenback (:jst)]

Comment on attachment 152285 [details] [diff] [review]
patch

sr=jst

Comment 10

[Christian :Biesinger (don't email me, ping me on IRC)]

Checking in nsExternalHelperAppService.cpp;
/cvsroot/mozilla/uriloader/exthandler/nsExternalHelperAppService.cpp,v  <-- 
nsExternalHelperAppService.cpp
new revision: 1.265; previous revision: 1.264
done