onload XPI install still possible locally; download prompt remotely

RESOLVED DUPLICATE of bug 252758

Status

Core Graveyard
Installer: XPInstall Engine
--
major
RESOLVED DUPLICATE of bug 252758
14 years ago
3 years ago

People

(Reporter: Steffen Wilberg, Assigned: dveditz)

Tracking

Trunk
x86
Windows XP

Firefox Tracking Flags

(Not tracked)

Details

(URL)

Attachments

(3 attachments)

(Reporter)

Description

14 years ago
I stumbled upon a web site which prompted me to install an xpi. I didn't need to
do anything. xpi.whitelist.required is set to true and the site is not on my
whitelist.
First, this was supposed to be fixed by bug 238684. Second, this was supposed to
be blocked by xpi.whitelist.required (which results in Firefox displaying a
yellow info bar).

I can reproduce this with
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7) Gecko/20040806
Firefox/0.9.1+ and Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8a3)
Gecko/20040805.

Testcase upcoming.
(Reporter)

Comment 1

14 years ago
Created attachment 155352 [details]
testcase

This merely calls an obscured script from a remote location. There are several
prompts, one of which is a xpi install dialog. On the original site, only the
xpi install dialog pops up.
(Reporter)

Comment 2

14 years ago
Hrm. I get a download dialog when opening the testcase remotely. I think this is
what I saw on the real page. I only get a xpi install dialog when opening the
testcase from my local disk.

But downloading the xpi still seems to be a security risk since the user might
install the xpi by dragging it to the extension manager etc. And why does the
onlad xpi install work locally?
(Reporter)

Comment 3

14 years ago
Created attachment 155355 [details]
the obscured script

Just in case the script gets removed from the remote location. Can somebody
decipher that?
(Reporter)

Comment 4

14 years ago
This is the site I stumbled upon that:
http://www.cracks.am/cracks/a7.html

Just click on any link in the main area.
Summary: onload XPI install still possible → onload XPI install still possible locally; download prompt remotely
Attachment #155355 - Attachment mime type: application/octet-stream → text/plain
The onload block was a stop-gap, equivalent to the earliest generation popup
blocking which is easily defeated but better than nothing. Can't really do more
without exposing more DOM guts, but the whitelisting was supposed to pick up the
slack.

Whitelisting doesn't apply to file urls. You're still going to get an install
confirmation prompt and we figure something on your own machine is something you
put there.

When whitelisting's turned on I get a "save as" box instead of an install
prompt. We probably can't prevent that, there are too many legitimate ways to
trigger that.

This is creepy, nasty code. I tried to decipher it but I'm not sure I got it
right. It's a bunch of cryptic functions refering to cryptic variables. I don't
see where the variables are defined (some are used as if they were
navigator.userAgent), and I don't see where the functions get called in the
first place.

I'll try unescaping again, maybe it got an incomplete file, then I'll attach it
Created attachment 155472 [details]
An attempt to decrypt

This is what the escaped text turns into, with line breaks added for
readability.

The only problem is that the obscured form is fully functional if you wrap
<script></script> around it, while my decrypted form is not. For one thing
there's an out of place quote in a for() in the last function, and it's not
complete.

Even if that function was just missing a single closing brace, what code is
calling these functions? where are the variables getting set? In the very first
function there's a for()..else construct -- what?

Also when the obscured script runs and whitelisting is turned off there are a
couple prompts to press "YES" -- but there's no text like that anywhere, and no
calls to js's prompt().
Jesse: have time to help us decipher this nasty script? I don't know that
there's anything actually wrong here (whitelist required blocking seems to be
working) but I can't figure out how it's doing what it's doing so I might be
missing something.
Assignee: xpi-engine → dveditz
same script discussed in an earlier bug, duping.

*** This bug has been marked as a duplicate of 252758 ***
Group: security
Status: NEW → RESOLVED
Last Resolved: 14 years ago
Resolution: --- → DUPLICATE
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.