Uploaded image for project: 'JDK'
  1. JDK
  2. JDK-8034230

Applet caller check should not compare URLs

    Details

    • Type: Bug
    • Status: Resolved
    • Priority: P3
    • Resolution: Fixed
    • Affects Version/s: 7u51
    • Fix Version/s: 8u11
    • Component/s: deploy
    • Labels:
    • Subcomponent:
    • Resolved In Build:
      b01
    • CPU:
      x86_64
    • OS:
      linux_2.6

      Backports

        Description

        FULL PRODUCT VERSION :
        java version "1.7.0_51"
        Java(TM) SE Runtime Environment (build 1.7.0_51-b13)
        Java HotSpot(TM) 64-Bit Server VM (build 24.51-b03, mixed mode)

        ADDITIONAL OS VERSION INFORMATION :
        Debian Linux 6 Kernel 2.6.32 amd64
        presumably, the bug is cross-platform

        EXTRA RELEVANT SYSTEM CONFIGURATION :
        Firefox 26

        A DESCRIPTION OF THE PROBLEM :
        The applet manifest attribute Caller-Allowable-Codebase can limit JS caller to specific websites. However, in some unusual cases, there is possibility to call applet from different site. This is due to the URL compare algorithm, which does DNS lookup and compares resolved addresses.

        ADDITIONAL REGRESSION INFORMATION:
        The attribute Caller-Allowable-Codebase was introduced in 7u45 (also affected), so there is no way how to reproduce buggy behavior in earlier versions.

        STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
        1) Set up DNS to point two different names (server1 and server2) to the same IP address of webserver.
        2) Create HTML page with embedded applet and JS calling that applet.
        3) Create applet with "Caller-Allowable-Codebase: https://server1".
        3) Sign the applet.
        4) Put the HTML page and applet to the webserver.
        5) Open https://server1/page.html, JS can call the applet.
        6) In another browser tab, open https://server2/page.html, JS can also call the applet.
        7) Close and reopen browser and repeat steps 5 and 6 in reverse order, JS in page from neither server2 nor server1 can call the applet.

        There are also DNS lookups for server names observable when accessing the applet, even in the scenario behind proxy server (DNS lookups for external names make no sense there).

        EXPECTED VERSUS ACTUAL BEHAVIOR :
        EXPECTED -
        JS on page from server1 should call applet, JS on page from server2 should not call the applet, regardless of the order.
        ACTUAL -
        see steps 6 and 7

        ERROR MESSAGES/STACK TRACES THAT OCCUR :
        The problem seems to be due to the improper URL comparison algortihm used. With attached debugger and breakpoint set to java.net.InetAddress.getByName, the stack shows URL comparison done by java.net.URL (use of java.net.URI instead would solve the problem completely):

        "Applet 1 LiveConnect Worker Thread"
        java.net.InetAddress.getByName(InetAddress.java:1048)
        java.net.URLStreamHandler.getHostAddress(URLStreamHandler.java:437)
        java.net.URLStreamHandler.hashCode(URLStreamHandler.java:354)
        java.net.URL.hashCode(URL.java:877)
        java.util.HashMap.hash(HashMap.java:366)
        java.util.HashMap.getEntry(HashMap.java:466)
        java.util.HashMap.get(HashMap.java:421)
        com.sun.deploy.security.CPCallbackHandler.isJSCallerInWhiteList
        com.sun.deploy.security.CPCallbackHandler.access$300
        com.sun.deploy.security.CPCallbackHandler$ParentCallback.checkJS2JavaAccess
        com.sun.deploy.security.CPCallbackHandler$ParentCallback.access$200
        com.sun.deploy.security.CPCallbackHandler.checkUntrustedAccess
        sun.plugin2.applet.Plugin2ClassLoader.checkUntrustedAccess
        sun.plugin2.applet.Plugin2Manager.checkUntrustedAccess
        sun.plugin2.main.client.LiveConnectSupport$PerAppletInfo.isLiveconnectCallAllowed
        sun.plugin2.main.client.LiveConnectSupport$PerAppletInfo.doObjectOp
        sun.plugin2.main.client.LiveConnectSupport$PerAppletInfo$LiveConnectWorker.run
        java.lang.Thread.run(Thread.java:744)


        REPRODUCIBILITY :
        This bug can be reproduced always.

          Attachments

            Issue Links

              Activity

                People

                • Assignee:
                  dtitov Daniil Titov
                  Reporter:
                  webbuggrp Webbug Group
                • Votes:
                  0 Vote for this issue
                  Watchers:
                  3 Start watching this issue

                  Dates

                  • Created:
                    Updated:
                    Resolved: