268925 - Ability to execute arbitrary remote js, including js that writes local files

Status: RESOLVED INVALID

(Firefox :: General, defect)

Description

[Daryl L. L. Houston]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.5) Gecko/20041107 Firefox/1.0
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.5) Gecko/20041107 Firefox/1.0

It's possible to use XMLHttpRequest to retrieve the text from a remote
javascript file and then to eval that text and execute the javascript within a
local scope. This circumvents the need to sign remote scripts and can be done
without enabling UniversalXPConnect. In theory, one would simply suggest that
application developers be careful not to write code that would execute arbitrary
remote javascript, but this doesn't account for malicious coders who might make
extensions available, for example, and use them to tamper with the users'
machines. It may be that this is a jslib issue and not a Gecko issue, but I
wasn't sure where else to report it.

Reproducible: Always
Steps to Reproduce:
1. Install jstest package (attached).
2. Edit xul.js (in zip file), replacing the second parameter to the "save()"
call to a local file on your system (or to a file that doesn't exist yet in a
writable directory).
3. Place xul.js (in zip file) on a remote server.
4. Edit the button in jstest.xul within package so that the parameter to
"execute()" in the "oncommand" parameter points to the file created in step 2.
5. Run the package and press the button.
Actual Results:  
A file is written to the local path specified in the remote script containing
the text sent as the first parameter to the remote "save()" function.

Expected Results:  
No unsigned remote javascript should be able to perform certain actions, such as
local file operations.

Comment 1

[Daryl L. L. Houston]

Attachment: Package and remote js referenced in bug report

Comment 2

[Jesse Ruderman]

The attachment is an extension that (intentionally?) introduces a security hole
by calling eval() on data obtained through XMLHttpRequest.  JavaScript does not
have taint-based security (it does not remember which variables contain or were
influenced by untrusted data) in Mozilla.  Invalid.

If you install a malicious extension, you have already lost.  Invalid.

Chrome JS authors should avoid using eval().  There are usually alternatives
that don't involve treating a string as JavaScript code.

Comment 3

[Daryl L. L. Houston]

Right, as I noted in the report, any sane developer with good intentions isn't
going to exploit this ability. Malicious developers might, though. So Developer
X creates an extension that's supposed to help you manage your porn. A million
users download it, little suspecting (as they're just pr0n connoisseurs with no
clue about security and no way of knowing to view the source of an extension
prior to installing it) that every tenth load (for example), the extension is
executing malicious remote code. Saying that this is invalid is a little like
saying tough luck to users who install spyware in IE (intentionally or not). I
think not addressing something like this is just asking for a PR nightmare. The
first time some jerk releases such an extension and a bunch of people find
things gone awry on their systems, there will be cries that Firefox is no more
secure than IE. I guess my point is that maybe javascript *should* have
taint-based security in Mozilla, if possible.

Comment 4

[Jesse Ruderman]

Extensions can run arbitrary native code.  Therefore, they can download and run
arbitrary native code.  Hence "If you install a malicious extension, you have
already lost.  Invalid."

If you think extensions should be less powerful (unable to create files, run
programs, etc), file a bug for that.  But I don't think that's going to happen.

Comment 5

[Daryl L. L. Houston]

Fair enough. I do think extensions will become an issue later, especially as
Firefox gains popularity. The vetting process for any extensions hosted at umo
will need to be very strict (if it's not already, and I gather from talking to
the maintainer that it's not), and a concerted effort to make sure Joe User
understands that extensions aren't part of or supported by Firefox will need to
be made. Savvy users understand this already, but it's not the savvy users who
are most often affected by any sort of malware. I'll cut out the Henny Penny act
now, though. Thanks for reviewing the bug report.