Bug 982558 - icedtea-web: proxy PAC support does not work
icedtea-web: proxy PAC support does not work
Status: CLOSED ERRATA
Product: Fedora
Classification: Fedora
Component: icedtea-web (Show other bugs)
19
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Omair Majid
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2013-07-09 05:52 EDT by Florian Weimer
Modified: 2013-07-25 20:31 EDT (History)
3 users (show)

See Also:
Fixed In Version: icedtea-web-1.4-3.fc19
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2013-07-25 20:31:49 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Florian Weimer 2013-07-09 05:52:26 EDT
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 10:58:15 EDT
(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 11:18:27 EDT
(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 19:36:58 EDT
(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 19:40:17 EDT
(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 18:24:49 EDT
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-24 20:45:58 EDT
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-25 20:31:49 EDT
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.

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