It was discovered that the IcedTea-Web used codebase attribute of the <applet> tag on the HTML page that hosts Java applet in the Same Origin Policy (SOP) checks. As the specified codebase does not have to match the applet's actual origin, this allowed malicious site to bypass SOP via spoofed codebase value. Note that for Java applets, origin used for SOP checks is the site from which applet was loaded, not the site hosting the page embedding applet: https://code.google.com/p/browsersec/wiki/Part2#Same-origin_policy_for_Java Acknowledgement: This issue was discovered by Red Hat Product Security.
After several emails and various checks, it seems that theoretical solution maybe - app can get code from both codebase and docbase - code from codeabse can connect only to codebase - code from docbase can connect only to docbase What to do when code from codebase wont to connect to codebase via code from docbase? (nad vice versa).
It seems that this behaviour is regression when urlpermission was adde: http://icedtea.classpath.org/hg/icedtea-web/annotate/d700c395b040/netx/net/sourceforge/jnlp/SecurityDesc.java#380 In its parent http://icedtea.classpath.org/hg/icedtea-web/file/d2bebf24c3ef/netx/net/sourceforge/jnlp/SecurityDesc.java is no mentioning of codebase[2] or docbase, but only usage of place, from where the code is going[1] [1] http://icedtea.classpath.org/hg/icedtea-web/file/d2bebf24c3ef/netx/net/sourceforge/jnlp/SecurityDesc.java#l344 [2] http://icedtea.classpath.org/hg/icedtea-web/annotate/d700c395b040/netx/net/sourceforge/jnlp/SecurityDesc.java#l413
(In reply to jiri vanek from comment #2) > - app can get code from both codebase and docbase Would this also imply that app will only be able to get code from codebase or docbase and not anywhere else? Oracle plugin does not have such restriction, so this could lead to compatibility issues. > - code from codeabse can connect only to codebase > - code from docbase can connect only to docbase I do not see Oracle plugin allowing connections to docbase that is different from codebase. AFAICS, only the first of the above two is allowed. > What to do when code from codebase wont to connect to codebase via code from > docbase? (nad vice versa). I see such connections rejected by Oracle plugin. So not only origin of the code, but also origins of all code higher up the stack.
When thew patch from #c3 was included[1] there was some discussion about codebase [2] but it does not seems to be what was implemented at the end. However Andrew's question about"case F" is quote correct. There are cases when no connection is correct:-/ [1] http://icedtea.classpath.org/hg/icedtea-web/rev/d700c395b040 [2] http://mail.openjdk.java.net/pipermail/distro-pkg-dev/2014-July/028609.html
(In reply to Tomas Hoger from comment #4) > (In reply to jiri vanek from comment #2) > > - app can get code from both codebase and docbase > > Would this also imply that app will only be able to get code from codebase > or docbase and not anywhere else? Oracle plugin does not have such > restriction, so this could lead to compatibility issues. Lets assume ITW is doing it correctly right now and lets focus(me) on mian issue > > > - code from codeabse can connect only to codebase > > - code from docbase can connect only to docbase > > I do not see Oracle plugin allowing connections to docbase that is different > from codebase. AFAICS, only the first of the above two is allowed. > > > What to do when code from codebase wont to connect to codebase via code from > > docbase? (nad vice versa). > > I see such connections rejected by Oracle plugin. So not only origin of the > code, but also origins of all code higher up the stack. So the only valid allowed connections should be to the places from where the jars were downloaded. If no jar is downloaded, then codebase. Right? Also - the port is included. What about this cornercases: some.url/resource1.jar another.url/resource2.jar codebase=some.url In this case both some.url and another.url are supposed tobe allowed? some.url/resource1.jar another.url/resource2.jar Again, both some.url and another.url are supposed tobe allowed? another.url/resource2.jar codebase=some.url In this case only the another.url should be allowed, right? this should be applied to both URLpermissions and socketpermissions, oook?
The code in this arrea contains[1] permissions.add(new SocketPermission(downloadHost,"connect, accept")); This do not enforce port. Imho is bug, and fix delivered to this bug will cover it too (As imho both url and socket permissions should be set same) The already mentioned thread is pointing to it [2] [1] http://icedtea.classpath.org/hg/icedtea-web/file/d2bebf24c3ef/netx/net/sourceforge/jnlp/SecurityDesc.java#l345 [2] http://mail.openjdk.java.net/pipermail/distro-pkg-dev/2014-July/028514.html
(In reply to jiri vanek from comment #5) > When thew patch from #c3 was included[1] there was some discussion about > codebase [2] but it does not seems to be what was implemented at the end. > However Andrew's question about"case F" is quote correct. There are cases > when no connection is correct:-/ > > [1] http://icedtea.classpath.org/hg/icedtea-web/rev/d700c395b040 > [2] http://mail.openjdk.java.net/pipermail/distro-pkg-dev/2014-July/028609.html Have you tested the case F with Oracle plugin? AFAICS, it allows connections to example.com:80. That is consistent with what was noted above: code that originates from codebase is allowed to connect to codebase host. Regarding the other examples with different ports, they seem incorrect. I've not done all the testing yet, but what I see is that Oracle 8 now includes port number as part of the origin specification. That's difference from Oracle 7. If you load applet from a codebase on http://example.com, 7 allows it to connect back to other ports, while 8 only allows connecting back to port 80. (In reply to jiri vanek from comment #6) > So the only valid allowed connections should be to the places from where the > jars were downloaded. Uhm, no. I only see Oracle allowing connections to codebase, and only for code that also originates from codebase and is not called by code from elsewhere. > If no jar is downloaded, then codebase. Right? Is there a way to have code that is not from any jar and is also not from codebase? If the only way to load .class code is from codebase, than codebase is its origin. > Also - the port is included. That seems to depend on the version - see above. > some.url/resource1.jar > another.url/resource2.jar > codebase=some.url > In this case both some.url and another.url are supposed tobe allowed? Oracle plugin only allows connection to codebase. > some.url/resource1.jar > another.url/resource2.jar > Again, both some.url and another.url are supposed tobe allowed? If there's no explicit codebase, it's set implicitly based on docbase, right? Based on codebase, one or none of the two would be allowed. > another.url/resource2.jar > codebase=some.url > In this case only the another.url should be allowed, right? No, I only see Oracle plugin allow connections to codebase as noted above. > this should be applied to both URLpermissions and socketpermissions, oook? Version dependent. 8 no longer allows socket connections anywhere. That's what this ITW upstream bug is about: http://icedtea.classpath.org/bugzilla/show_bug.cgi?id=2472 (In reply to jiri vanek from comment #7) > This do not enforce port. Imho is bug, and fix delivered to this bug will > cover it too (As imho both url and socket permissions should be set same) They are not the same in Oracle 8. It does not allow socket permission, as that would not allow it check if connection is to the same host name. And without that, it can't separate different named vhosts hosted on the same server / IP.
(In reply to Tomas Hoger from comment #8) > (In reply to jiri vanek from comment #5) > > When thew patch from #c3 was included[1] there was some discussion about > > codebase [2] but it does not seems to be what was implemented at the end. > > However Andrew's question about"case F" is quote correct. There are cases > > when no connection is correct:-/ > > > > [1] http://icedtea.classpath.org/hg/icedtea-web/rev/d700c395b040 > > [2] http://mail.openjdk.java.net/pipermail/distro-pkg-dev/2014-July/028609.html > > Have you tested the case F with Oracle plugin? AFAICS, it allows > connections to example.com:80. That is consistent with what was noted > above: code that originates from codebase is allowed to connect to codebase > host. Agree. > > Regarding the other examples with different ports, they seem incorrect. > I've not done all the testing yet, but what I see is that Oracle 8 now > includes port number as part of the origin specification. That's difference > from Oracle 7. If you load applet from a codebase on http://example.com, 7 > allows it to connect back to other ports, while 8 only allows connecting > back to port 80. [*] I would really liek to keep ITW jdk-version independent. Looking to changes in oracle jdk and plugin, I would much rather follow the port restrictingbehaviour of jdk8 > > (In reply to jiri vanek from comment #6) > > So the only valid allowed connections should be to the places from where the > > jars were downloaded. > > Uhm, no. I only see Oracle allowing connections to codebase, and only for > code that also originates from codebase and is not called by code from > elsewhere. So only resources in codebase are allowed connections to codebase. Others can do no connections, right? > > > If no jar is downloaded, then codebase. Right? > > Is there a way to have code that is not from any jar and is also not from > codebase? Should be not possible > If the only way to load .class code is from codebase, than > codebase is its origin. Right. > > > Also - the port is included. > > That seems to depend on the version - see above. As said in [1] > > > some.url/resource1.jar > > another.url/resource2.jar > > codebase=some.url > > In this case both some.url and another.url are supposed to be allowed? > > Oracle plugin only allows connection to codebase. So resource1.jar can conect to some.url but resource2.jar can not connect anywhere, right? (as you are explaining in [**] > > > some.url/resource1.jar > > another.url/resource2.jar > > Again, both some.url and another.url are supposed tobe allowed? > [**] > If there's no explicit codebase, it's set implicitly based on docbase, > right? Based on codebase, one or none of the two would be allowed. Right. > > > another.url/resource2.jar > > codebase=some.url > > In this case only the another.url should be allowed, right? > > No, I only see Oracle plugin allow connections to codebase as noted above. So resource2.jar can not make any connections, right? > > > this should be applied to both URLpermissions and socketpermissions, oook? > > Version dependent. 8 no longer allows socket connections anywhere. That's > what this ITW upstream bug is about: > > http://icedtea.classpath.org/bugzilla/show_bug.cgi?id=2472 > > (In reply to jiri vanek from comment #7) > > This do not enforce port. Imho is bug, and fix delivered to this bug will > > cover it too (As imho both url and socket permissions should be set same) > Again. I would like to restrict by 8's way and include port, as said in [*] > They are not the same in Oracle 8. It does not allow socket permission, as > that would not allow it check if connection is to the same host name. And > without that, it can't separate different named vhosts hosted on the same > server / IP. As [**] ... I wonted to avoid per jar sandboxes, as ITW is not exactly ready for them. But it looks like the only way.
s/As [**] ... /As [*] ...
(In reply to jiri vanek from comment #9) > > Regarding the other examples with different ports, they seem incorrect. > > I've not done all the testing yet, but what I see is that Oracle 8 now > > includes port number as part of the origin specification. That's difference > > from Oracle 7. If you load applet from a codebase on http://example.com, 7 > > allows it to connect back to other ports, while 8 only allows connecting > > back to port 80. > [*] > I would really liek to keep ITW jdk-version independent. > Looking to changes in oracle jdk and plugin, I would much rather follow the > port restricting behaviour of jdk8 Would it even be possible? JDK8 policy implementation seems to depend on URLPermission, which is new in JDK8. > > Uhm, no. I only see Oracle allowing connections to codebase, and only for > > code that also originates from codebase and is not called by code from > > elsewhere. > > So only resources in codebase are allowed connections to codebase. > Others can do no connections, right? That's what I see in my testing, yes. > > > some.url/resource1.jar > > > another.url/resource2.jar > > > codebase=some.url > > > In this case both some.url and another.url are supposed to be allowed? > > > > Oracle plugin only allows connection to codebase. > > So resource1.jar can conect to some.url but resource2.jar can not connect > anywhere, right? (as you are explaining in [**] Assuming resource1 contains the main class of the applet and code that attempts to make connection is not called by some other code in resource2. If main class of the applet is in resource2, and it calls some code in resource1, that attempts to establish connection to codebase, it is not allowed to do so. > > > another.url/resource2.jar > > > codebase=some.url > > > In this case only the another.url should be allowed, right? > > > > No, I only see Oracle plugin allow connections to codebase as noted above. > > So resource2.jar can not make any connections, right? Correct.
This issue is no longer relevant as modern browsers do not support Java applets any more.