Last Comment Bug 902375 - Firefox 23: The Load of a local java applet (*jar) fails silently
: Firefox 23: The Load of a local java applet (*jar) fails silently
Status: VERIFIED FIXED
: regression, testcase
Product: Core
Classification: Components
Component: Plug-ins (show other bugs)
: 23 Branch
: All All
: -- normal with 4 votes (vote)
: mozilla26
Assigned To: John Schoenick [:johns]
: Ioana (away)
: Benjamin Smedberg [:bsmedberg]
Mentors:
: 904033 (view as bug list)
Depends on:
Blocks: CVE-2013-1717
  Show dependency treegraph
 
Reported: 2013-08-07 02:52 PDT by trackfirefox
Modified: 2013-10-10 05:50 PDT (History)
15 users (show)
Ms2ger: in‑testsuite?
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---
unaffected
wontfix
+
verified
+
verified
+
verified
unaffected


Attachments
testcase. unzip and open ./html/index.html (3.25 MB, application/octet-stream)
2013-08-07 03:34 PDT, trackfirefox
no flags Details
test case 2. java in a subdirectory (3.25 MB, application/octet-stream)
2013-08-07 08:11 PDT, trackfirefox
no flags Details
Actually use the optional parameter added explicitly for this purpose (1.05 KB, patch)
2013-08-07 15:05 PDT, John Schoenick [:johns]
benjamin: review+
bajaj.bhavana: approval‑mozilla‑aurora+
bajaj.bhavana: approval‑mozilla‑beta+
Details | Diff | Splinter Review
Strict file origin policy - handle case where the target is the parent directory of the source (1.51 KB, patch)
2013-08-07 15:09 PDT, John Schoenick [:johns]
bzbarsky: review+
Details | Diff | Splinter Review
Strict file origin policy - handle case where the target is the parent directory of the source. r=bz (1.71 KB, patch)
2013-08-20 15:37 PDT, John Schoenick [:johns]
john: review+
bajaj.bhavana: approval‑mozilla‑aurora+
bajaj.bhavana: approval‑mozilla‑beta+
Details | Diff | Splinter Review

Description trackfirefox 2013-08-07 02:52:23 PDT
User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:23.0) Gecko/20100101 Firefox/23.0 (Beta/Release)
Build ID: 20130730113002

Steps to reproduce:

A local web application intended to be an off-line DVD, uses a local java applet.
Up to version 22 it worked fine.

The html is:
<applet width="960" height="425" archive="jclic.jar" codebase="../jclic/" code="JClicApplet">
<param value="application/x-java-applet;version=1.4" name="type">
<param value="false" name="scriptable">
<param value="cap1-03J.jclic.zip" name="activityPack">
</applet>

Trying to set codebase to a full path: "/...../jclic"
and a full url: "file:///...../jclic" 

both still fail.

The error happens both in Mac OS and Windows with Version 23


Actual results:

The applet is not loaded.
No error is shown.
Java v is not invoked.


Expected results:

The applet loaded.
Comment 1 Scoobidiver (away) 2013-08-07 03:02:56 PDT
We need a testcase as an attachment and eventually a regression range using mozregression (see https://github.com/mozilla/mozregression).
Comment 2 trackfirefox 2013-08-07 03:34:10 PDT
Created attachment 786840 [details]
testcase. unzip and open ./html/index.html

A Test case for the problem.
Unzip and open ./html/index.html.
The applet being loaded is in ./jclic/jclic.jar
Comment 3 trackfirefox 2013-08-07 03:43:05 PDT
Hi!

Thanks Scoobidiver!

About mozregression, I'm affraid I'm not being able to correctly install (and use).
I'm not familiar with Mozilla development workflows.

What I can tell is:
It works correctly with release 22.0, Mac OS X and Windows
It fails with release 23.0 (today August 7, 2013), both Mac OS X and Windows.

Many thanks in advance.
Dino
Comment 4 Scoobidiver (away) 2013-08-07 05:42:05 PDT
The regression range is:
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=b48e06621dc9&tochange=dcbbfcdf7bb4
It's likely a regression from bug 888834 or bug 406541 .
Comment 5 Benjamin Smedberg [:bsmedberg] 2013-08-07 06:23:22 PDT
I believe that this is by design. Our same-origin policy for sites loaded from file: is that they may only access files in their directory and subdirectories. The codebase="../jclic/" indicates that this is trying to load Java from a parent directory. That is specifically what we were fixing.

See https://developer.mozilla.org/en-US/docs/Same-origin_policy_for_file:_URIs for background. If you flip the security.fileuri.strict_origin_policy pref to `false`, does that cause your Java to load? If so I expect that this is WONTFIX, but I'll let johns double-check me here.
Comment 6 trackfirefox 2013-08-07 08:11:13 PDT
Created attachment 786945 [details]
test case 2. java in a subdirectory
Comment 7 trackfirefox 2013-08-07 08:20:30 PDT
Hi Benjamin!

Thanks for your work!

First, I confirm that with security.fileuri.strict_origin_policy pref to `false`
it works.

We don't like the final user has to change the settings, so
we can rearrange to find the java in a subdirectory.
But we have prepared a second test case with this approach
(java in a subdirectory and security.fileuri.strict_origin_policy = true).
No success:
It does not load the java.

I have attached this second test case (case2.zip).

Please confirm us if you reproduce the same behaviour.

Many thanks again!

Dino.
Comment 8 Scoobidiver (away) 2013-08-07 10:00:36 PDT
The regression range for the second testcase is still the same.
Comment 9 bhavana bajaj [:bajaj] 2013-08-07 13:08:38 PDT
needinfo on John to help with comment #5 and understand if this is a valid bug ?
Comment 10 John Schoenick [:johns] 2013-08-07 15:02:28 PDT
The case where codebases outside of the current directory are blocked is intentional -- however, the case where subdirectories do not work properly is not :(
Comment 11 John Schoenick [:johns] 2013-08-07 15:05:43 PDT
Created attachment 787153 [details] [diff] [review]
Actually use the optional parameter added explicitly for this purpose

Sigh. Fail. Most of the code in 406541 was to split out NS_RelaxStrictFileOrigin to allow adding the aAllowDirectoryTarget parameter. If only the added security check actually called it...

I added this to the tests for bug 406541, which haven't landed yet.
Comment 12 John Schoenick [:johns] 2013-08-07 15:09:29 PDT
Created attachment 787154 [details] [diff] [review]
Strict file origin policy - handle case where the target is the parent directory of the source

Bonus edge case found while looking at this - the strict file origin logic might fail if the target of an operation is the parent directory of the given file, and aAllowDirectoryTarget = true. (with allowDirectoryTarget a file should be able to target its own directory)
Comment 13 Boris Zbarsky [:bz] (still a bit busy) 2013-08-07 20:14:09 PDT
Comment on attachment 787154 [details] [diff] [review]
Strict file origin policy - handle case where the target is the parent directory of the source

Can you assert that if NS_SUCCEEDED(rv) && allowed for the Equals() call (basically an else for the if you have there) then aAllowDirectoryTarget is true?

r=me with that
Comment 14 John Schoenick [:johns] 2013-08-12 13:39:26 PDT
*** Bug 904033 has been marked as a duplicate of this bug. ***
Comment 15 John Schoenick [:johns] 2013-08-20 15:37:32 PDT
Created attachment 793159 [details] [diff] [review]
Strict file origin policy - handle case where the target is the parent directory of the source. r=bz
Comment 16 John Schoenick [:johns] 2013-08-20 15:38:13 PDT
Comment on attachment 793159 [details] [diff] [review]
Strict file origin policy - handle case where the target is the parent directory of the source. r=bz

addressed review comments
Comment 19 Ivo Anjo 2013-08-22 07:41:08 PDT
I don't know what the procedure for backports is on mozilla, but could this be backported to at least FF 24, since it is going to be an ESR release?
Comment 20 John Schoenick [:johns] 2013-08-22 11:34:31 PDT
Comment on attachment 787153 [details] [diff] [review]
Actually use the optional parameter added explicitly for this purpose

[Approval Request Comment]
Bug caused by (feature/regressing bug #):
406541

User impact if declined:
Local (file://) pages that use Java don't work properly in some cases

Testing completed (on m-c, etc.):
On m-c

Risk to taking this patch (and alternatives if risky):
Very low, these changes only affect java applets on file URIs.

String or IDL/UUID changes made by this patch:
None
Comment 21 John Schoenick [:johns] 2013-08-22 11:35:10 PDT
Comment on attachment 793159 [details] [diff] [review]
Strict file origin policy - handle case where the target is the parent directory of the source. r=bz

see comment 20
Comment 22 John Schoenick [:johns] 2013-08-22 11:37:15 PDT
Tests for this will land with the 406541 tests
Comment 24 trackfirefox 2013-08-24 00:56:45 PDT
Hi All!

Just to confirm...

With Nightly 26.0a1 (2013-08-23), my testcase works correctly.

I will check with aurora and beta.

Thanks!!
Comment 25 Ioana (away) 2013-08-27 05:27:34 PDT
Verified as fixed on Firefox 24 beta 6 (20130826142034) - Windows 7 64bit, Ubuntu 13.04 32bit and Mac OSX 10.7.5.

The applet in the first testcase doesn't load - as specified by design.
The applet in the second testcase loads fine.
Comment 26 Ioana (away) 2013-09-12 06:38:13 PDT
Also verified on Firefox 25:
Mac OS X 10.8.4 - 20130912004004
Ubuntu 13.04 - 20130911004006
Windows 7 - 20130912004004
Comment 27 Bogdan Maris, QA [:bogdan_maris] 2013-10-10 05:50:47 PDT
Mozilla/5.0 (Windows NT 6.2; WOW64; rv:26.0) Gecko/20100101 Firefox/26.0
Mozilla/5.0 (X11; Linux i686; rv:26.0) Gecko/20100101 Firefox/26.0
Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:26.0) Gecko/20100101 Firefox/26.0

Verified as fixed on latest Aurora 26.0a2 (buildID: 20131010004002).

Note You need to log in before you can comment on or make changes to this bug.