Closed
Bug 298202
Opened 19 years ago
Closed 19 years ago
java preference ignored depending on java plugin install location
Categories
(Core Graveyard :: Java: OJI, defect)
Tracking
(Not tracked)
RESOLVED
FIXED
People
(Reporter: fehe, Assigned: doronr)
References
()
Details
(Keywords: fixed1.8)
Attachments
(1 file)
1.34 KB,
patch
|
jst
:
review+
shaver
:
superreview+
cbeard
:
approval1.8b4+
|
Details | Diff | Splinter Review |
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b2) Gecko/20050619 Firefox/1.0+
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b2) Gecko/20050619 Firefox/1.0+
If you have javascript enabled but you have java disabled, certain websites can
invoke full java capability via a "malicious" javascript. This appears to be
the scheme utilized at the linked URL.
Reproducible: Always
Steps to Reproduce:
1. Install Sun JRE 5.0 Update 3
2. Install the latest Deer Park alpha 1 trunk
3. Copy NPJava11.dll, NPJava11.dll, NPJava12.dll, NPJava13.dll, NPJava14.dll,
NPJava32.dll, NPJPI150_03.dll, and NPOJI610.dll, from "C:\Program
Files\Java\jre1.5.0_03\bin" to your Deer Park plugins directory
4. Launch Deer Park
5. Under Tools-->Options, disable both Javascript and Java
6. Visit http://www.theage.com.au/articles/2003/10/05/1065292455917.html
7. Notice that Java does not launch (i.e. no icon in the XP system tray)
8. Now go back to Tools-->Options and enable only Javascript (you can also
enable "but disable common annoyances" if you like - it will not make a
difference) but leave Java disabled.
9. Once again, visit http://www.theage.com.au/articles/2003/10/05/1065292455917.html
10. This time you should notice that Java has launced, because the Java icon
appears in the XP system tray!
Actual Results:
Firefox preference for Java is circumvented by the website and full-blow Java
support is enabled.
Expected Results:
No website should be capable of circumventing firefox preferences and enabling
"ANY" features that the user has intentionally disabled - especially Java!
My system: Windows XP, SP2 + fully patched with all current XP updates. My only
firewall is the Windows XP firewall (i.e. no egress or miscellaneous filtering -
Adblock excepted).
Updated•19 years ago
|
Component: Preferences → Security
QA Contact: preferences → firefox
No action?
You can also use (obviously) JRE 5.0 Update 4, which was just released, to
reproduce this.
Comment 2•19 years ago
|
||
I don't believe that it is the site bypassing the preference... rather it is the
preference not being honored when the plugins are placed in either the app's
plugins directory or the plugins directory above the profile directory (e.g.
mozilla/plugins). I know the preference was honored in earlier builds so I
suspect this is a regression. A regression window would be helpful here.
Comment 3•19 years ago
|
||
BTW: the preference was honored for me when the java plugins were NOT in app,
etc. and it was honored when they were not located in either of those locations
Confirmed. It only occurs when the plugins are placed in the Firefox plugins
directory.
There was a time when I could not get Java applets to work in Firefox (I believe
earlier than 0.8 ) until I copied the plugins over. Ever since then, that is
what I automatically did with each install.
Now I have verified that applets work without placing those plugins in the
Firefox directory. Not sure how to proceed from here.
Comment 5•19 years ago
|
||
I can confirm this behavior as well. A few notes though:
1) This does not occur on the website http://www.java.com/en/ I haven't been
seeking out a ton of test sites due to time constraints though.
2) It should be noted that no actual java code execution takes place. Then
again, the test page in the bug doesn't actually execute any java code even when
you have it properly enabled. Whether or not java code can actually be executed
via this bug, instead of just opening the java console, remains to be thoroughly
tested.
HOWEVER, since even the console should not be opening with Java disabled... this
is definitely a bug. It's the severity I'm unsure about.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Summary: If javascript is enabled, sites can bypass Firefox preferences and enable full java → java preference ignored depending on java plugin install location
Updated•19 years ago
|
Product: Firefox → Core
Updated•19 years ago
|
Component: Security → Plug-ins
Updated•19 years ago
|
Flags: blocking1.8b4?
Updated•19 years ago
|
Flags: blocking1.8b4? → blocking1.8b4+
Comment 6•19 years ago
|
||
Johnny, this looks bad. Can you look into it or recommend someone else?
Assignee: nobody → jst
Flags: blocking1.8b4+ → blocking1.8b4?
Updated•19 years ago
|
Flags: blocking1.8b4? → blocking1.8b4+
Comment 7•19 years ago
|
||
doron, is this something you could help us investigate? JST is pretty doomed
right now. If not, any ideas who could help out?
Assignee | ||
Comment 8•19 years ago
|
||
This seems to be related to JavaScript calling the Java object, so Java is being
initated by JavaScript (var x = Java.etc) and not via markup.
Note that 1.7 has this behavior as well, so not a regression. It just seems we
don't honor the preference when the JS Engine invokes the Java object.
I wouldn't call this bad really.
Assignee | ||
Comment 9•19 years ago
|
||
http://lxr.mozilla.org/seamonkey/source/js/src/liveconnect/jsj_JavaPackage.c
seems to be the code in question, and I defer to shaver. This is supposed to be
standalone code and all, so someone who knows the engine needs to figure out how
(if at all) we should do this.
Comment 10•19 years ago
|
||
What in that file, specifically, do you think is the code in question? All of
LiveConnect's interaction with the JVM is mediated through the callbacks
installed here:
http://lxr.mozilla.org/seamonkey/source/modules/oji/src/lcglue.cpp#402
so if something is not honouring the pref correctly, it'll be elsewhere.
When this is happening, what do we find for the status at
http://lxr.mozilla.org/seamonkey/source/modules/oji/src/jvmmgr.cpp#73
?
Assignee | ||
Comment 11•19 years ago
|
||
debugger shows status as nsJVMStatus_Enabled.
Assignee | ||
Comment 12•19 years ago
|
||
nsJVMManager::nsJVMManager adds an pref observer, but doesn't actually get the
prev value and call SetJVMEnabled -
http://lxr.mozilla.org/seamonkey/source/modules/oji/src/nsJVMManager.cpp#368
Adding that seems to fix the issue for me. Not sure if that is the right way to go.
Comment 13•19 years ago
|
||
Sounds good to me too -- I'll give you the bug as a prize for your detective
work! Wanna put a patch up?
Assignee: jst → doronr
Component: Plug-ins → Java: OJI
Assignee | ||
Comment 14•19 years ago
|
||
Attachment #193188 -
Flags: superreview?(shaver)
Comment 15•19 years ago
|
||
Comment on attachment 193188 [details] [diff] [review]
proposed patch
If we can't get the pref, we default to...what? I guess "on", because that's
what we get without that code. sr=shaver
Attachment #193188 -
Flags: superreview?(shaver) → superreview+
Assignee | ||
Comment 16•19 years ago
|
||
(In reply to comment #15)
> (From update of attachment 193188 [details] [diff] [review] [edit])
> If we can't get the pref, we default to...what? I guess "on", because that's
> what we get without that code. sr=shaver
>
I could call SetJVMEnabled(prefBool) if we couldn't get the prefservice or pref,
since prefBool defaults to true.
Assignee | ||
Updated•19 years ago
|
Attachment #193188 -
Flags: approval1.8b4?
Assignee | ||
Updated•19 years ago
|
Attachment #193188 -
Flags: review?(jst)
Comment 17•19 years ago
|
||
Comment on attachment 193188 [details] [diff] [review]
proposed patch
r=jst
Attachment #193188 -
Flags: review?(jst) → review+
Updated•19 years ago
|
Attachment #193188 -
Flags: approval1.8b4? → approval1.8b4+
Comment 18•19 years ago
|
||
bah. you're duplicating code. i'd prefer you poke Observe and pretend the pref
has changed.
Assignee | ||
Comment 19•19 years ago
|
||
checked into trunk/1.8 branch
You need to log in
before you can comment on or make changes to this bug.
Description
•