Bug 982558

Summary: icedtea-web: proxy PAC support does not work
Product: [Fedora] Fedora Reporter: Florian Weimer <fweimer>
Component: icedtea-webAssignee: Omair Majid <omajid>
Status: CLOSED ERRATA QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 19CC: dbhole, jvanek, omajid
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: icedtea-web-1.4-3.fc19 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2013-07-26 00:31:49 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Florian Weimer 2013-07-09 09:52:26 UTC
Proxy PAC support has several problems:

The settings are not inherited from the browser configuration.  Even if the browser uses a proxy PAC URL, icedtea-web will still issue a direction connect.

If I configure the proxy PAC URL using itweb-settings.itweb, I get an exception.  This is not related to the actual Javascript contents, it happens during Rhino initialization:

java.security.AccessControlException: access denied ("java.util.PropertyPermission" "java.vm.name" "read")
        at java.security.AccessControlContext.checkPermission(AccessControlContext.java:372)
        at java.security.AccessController.checkPermission(AccessController.java:559)
        at java.lang.SecurityManager.checkPermission(SecurityManager.java:549)
        at net.sourceforge.jnlp.runtime.JNLPSecurityManager.checkPermission(JNLPSecurityManager.java:284)
        at java.lang.SecurityManager.checkPropertyAccess(SecurityManager.java:1302)
        at java.lang.System.getProperty(System.java:707)
        at org.mozilla.javascript.ScriptRuntime.getTopPackageNames(ScriptRuntime.java:228)
        at org.mozilla.javascript.ScriptRuntime.initStandardObjects(ScriptRuntime.java:206)
        at org.mozilla.javascript.Context.initStandardObjects(Context.java:1044)
        at org.mozilla.javascript.Context.initStandardObjects(Context.java:988)
        at net.sourceforge.jnlp.runtime.RhinoBasedPacEvaluator$EvaluatePacAction.run(RhinoBasedPacEvaluator.java:235)
        at net.sourceforge.jnlp.runtime.RhinoBasedPacEvaluator$EvaluatePacAction.run(RhinoBasedPacEvaluator.java:212)
        at java.security.AccessController.doPrivileged(Native Method)
        at net.sourceforge.jnlp.runtime.RhinoBasedPacEvaluator.getProxiesWithoutCaching(RhinoBasedPacEvaluator.java:133
        at net.sourceforge.jnlp.runtime.RhinoBasedPacEvaluator.getProxies(RhinoBasedPacEvaluator.java:104)
        at net.sourceforge.jnlp.runtime.JNLPProxySelector.getFromPAC(JNLPProxySelector.java:348)
        at net.sourceforge.jnlp.runtime.JNLPProxySelector.select(JNLPProxySelector.java:205)
        at sun.net.www.protocol.http.HttpURLConnection.plainConnect(HttpURLConnection.java:925)
        at sun.net.www.protocol.http.HttpURLConnection.connect(HttpURLConnection.java:849)
        at sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:1299)
        at sun.misc.URLClassPath$Loader.getResource(URLClassPath.java:537)
        at sun.misc.URLClassPath.getResource(URLClassPath.java:199)
        at java.net.URLClassLoader$1.run(URLClassLoader.java:358)
        at java.net.URLClassLoader$1.run(URLClassLoader.java:355)
        at java.security.AccessController.doPrivileged(Native Method)
        at java.net.URLClassLoader.findClass(URLClassLoader.java:354)
        at net.sourceforge.jnlp.runtime.JNLPClassLoader$CodeBaseClassLoader.access$1801(JNLPClassLoader.java:2323)
        at net.sourceforge.jnlp.runtime.JNLPClassLoader$CodeBaseClassLoader$1.run(JNLPClassLoader.java:2352)
        at net.sourceforge.jnlp.runtime.JNLPClassLoader$CodeBaseClassLoader$1.run(JNLPClassLoader.java:2350)
        at java.security.AccessController.doPrivileged(Native Method)
        at net.sourceforge.jnlp.runtime.JNLPClassLoader$CodeBaseClassLoader.findClassNonRecursive(JNLPClassLoader.java:
        at net.sourceforge.jnlp.runtime.JNLPClassLoader.findClass(JNLPClassLoader.java:1753)
        at net.sourceforge.jnlp.runtime.JNLPClassLoader.loadClassExt(JNLPClassLoader.java:1770)
        at net.sourceforge.jnlp.runtime.JNLPClassLoader.loadClass(JNLPClassLoader.java:1567)
        at net.sourceforge.jnlp.Launcher.createApplet(Launcher.java:779)
        at net.sourceforge.jnlp.Launcher.getApplet(Launcher.java:717)
        at net.sourceforge.jnlp.Launcher$TgThread.run(Launcher.java:969)

(This appears to be the only additional permission that is needed to get the scripting engine to start.)

Lastly, proxy PAC support exposes the Java sandbox to potentially less-than-fully-trusted Javascript code.

Perhaps proxy PAC support in the plugin is not needed anymore?

Relevant package versions:

firefox-22.0-1.fc19.x86_64
java-1.7.0-openjdk-1.7.0.25-2.3.10.4.fc19.x86_64
icedtea-web-1.4-2.fc19.x86_64

Comment 1 Omair Majid 2013-07-09 14:58:15 UTC
(In reply to Florian Weimer from comment #0)
> The settings are not inherited from the browser configuration.  Even if the
> browser uses a proxy PAC URL, icedtea-web will still issue a direction
> connect.

This sounds like a bug. We actually try to read settings from the browser (only Firefox at the moment) and use those. Do you have details on how to reproduce?

> If I configure the proxy PAC URL using itweb-settings.itweb, I get an
> exception.  This is not related to the actual Javascript contents, it
> happens during Rhino initialization:
> 
> java.security.AccessControlException: access denied
> ("java.util.PropertyPermission" "java.vm.name" "read")

> (This appears to be the only additional permission that is needed to get the
> scripting engine to start.)

I wonder why the runtime is even trying to access this...This property is not in the list of properties readable by everyone, but it seems fairly safe to expose this.

> Lastly, proxy PAC support exposes the Java sandbox to potentially
> less-than-fully-trusted Javascript code.

We actually use a separate and even more restricted sandbox for executing (just) this js code [1]. Do you have any suggestion on locking it down even more?

> Perhaps proxy PAC support in the plugin is not needed anymore?

I think it makes sense to support everything other browsers and networking applications use.

[1] http://icedtea.classpath.org/hg/icedtea-web/file/87c9fc859a21/netx/net/sourceforge/jnlp/runtime/RhinoBasedPacEvaluator.java#l125

Comment 2 Florian Weimer 2013-07-09 15:18:27 UTC
(In reply to Omair Majid from comment #1)
> (In reply to Florian Weimer from comment #0)
> > The settings are not inherited from the browser configuration.  Even if the
> > browser uses a proxy PAC URL, icedtea-web will still issue a direction
> > connect.
> 
> This sounds like a bug. We actually try to read settings from the browser
> (only Firefox at the moment) and use those. Do you have details on how to
> reproduce?

Uhm, I put a file:/// URL to a .js file into the Firefox networking configuration, and the plugin didn't load it (but Firefox did).

> > If I configure the proxy PAC URL using itweb-settings.itweb, I get an
> > exception.  This is not related to the actual Javascript contents, it
> > happens during Rhino initialization:
> > 
> > java.security.AccessControlException: access denied
> > ("java.util.PropertyPermission" "java.vm.name" "read")
> 
> > (This appears to be the only additional permission that is needed to get the
> > scripting engine to start.)
> 
> I wonder why the runtime is even trying to access this...This property is
> not in the list of properties readable by everyone, but it seems fairly safe
> to expose this.

It's listed in java.policy (the default policy) as:

  permission java.util.PropertyPermission "java.vm.name", "read";

(Your permission set replaces the default policy.)

> > Lastly, proxy PAC support exposes the Java sandbox to potentially
> > less-than-fully-trusted Javascript code.
> 
> We actually use a separate and even more restricted sandbox for executing
> (just) this js code [1]. Do you have any suggestion on locking it down even
> more?

You should not install the Java proxies into the Javascript world, so that e.g. java.lang.String will not be available, and check that you do not leak Java objects into the interpreter (including exceptions, which might be tricky).  This will reduce the attack surface considerably.  Parts of pac-funcs.js will have to be rewritten, though.

Comment 3 Omair Majid 2013-07-22 23:36:58 UTC
(In reply to Florian Weimer from comment #2)
> (In reply to Omair Majid from comment #1)
> > (In reply to Florian Weimer from comment #0)
> > > The settings are not inherited from the browser configuration.  Even if the
> > > browser uses a proxy PAC URL, icedtea-web will still issue a direction
> > > connect.
> > 
> > This sounds like a bug. We actually try to read settings from the browser
> > (only Firefox at the moment) and use those. Do you have details on how to
> > reproduce?
> 
> Uhm, I put a file:/// URL to a .js file into the Firefox networking
> configuration, and the plugin didn't load it (but Firefox did).

Fixed upstream:
http://icedtea.classpath.org/hg/icedtea-web/rev/6904f82aa501

> > > java.security.AccessControlException: access denied
> > > ("java.util.PropertyPermission" "java.vm.name" "read")
> > 
> > > (This appears to be the only additional permission that is needed to get the
> > > scripting engine to start.)
> > 
> > I wonder why the runtime is even trying to access this...This property is
> > not in the list of properties readable by everyone, but it seems fairly safe
> > to expose this.
> 
> It's listed in java.policy (the default policy) as:
> 
>   permission java.util.PropertyPermission "java.vm.name", "read";
> 
> (Your permission set replaces the default policy.)

We discussed this bit upstream and decided that we don't want to follow java.policy here. The PAC script is possibly remote code so even some of the policies listed in java.policy (such as SocketPermission "listen") are unnecessary.

Comment 4 Omair Majid 2013-07-22 23:40:17 UTC
(In reply to Florian Weimer from comment #2)
> You should not install the Java proxies into the Javascript world, so that
> e.g. java.lang.String will not be available, and check that you do not leak
> Java objects into the interpreter (including exceptions, which might be
> tricky).  This will reduce the attack surface considerably.  Parts of
> pac-funcs.js will have to be rewritten, though.

Tracking upstream now: http://icedtea.classpath.org/bugzilla/show_bug.cgi?id=1504

Comment 5 Fedora Update System 2013-07-23 22:24:49 UTC
icedtea-web-1.4-3.fc19 has been submitted as an update for Fedora 19.
https://admin.fedoraproject.org/updates/icedtea-web-1.4-3.fc19

Comment 6 Fedora Update System 2013-07-25 00:45:58 UTC
Package icedtea-web-1.4-3.fc19:
* should fix your issue,
* was pushed to the Fedora 19 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing icedtea-web-1.4-3.fc19'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2013-13572/icedtea-web-1.4-3.fc19
then log in and leave karma (feedback).

Comment 7 Fedora Update System 2013-07-26 00:31:49 UTC
icedtea-web-1.4-3.fc19 has been pushed to the Fedora 19 stable repository.  If problems still persist, please make note of it in this bug report.