Uploaded image for project: 'Batik'
  1. Batik
  2. BATIK-450

Incorrect implementation of org.mozilla.javascript.SecurityController

    XMLWordPrintableJSON

Details

    • Bug
    • Status: Resolved
    • Resolution: Fixed
    • 1.8
    • None
    • Scripting
    • None
    • Operating System: other
      Platform: Other

    Description

      From my message to Batik mail list:

      On Thu, 05 Feb 2004 14:38:23 -0500, "Thomas DeWeese"
      <Thomas.DeWeese@Kodak.com> said:

      >> ...
      >> Actually Batik gives the Rhino interpreter the class loader to use.
      >> So the class loader is from the Batik Context not the Rhino context.
      >> The Class loader also appears to associate an appropriate code source
      >> (i.e. the document's URL) with the created classes.
      >>
      >
      >>> > Now due to bugs in class loader implementations in many released JVMs
      >>> > (Sun JVMs <= 1.4.1 that I checked has this bug) it also means that Rhino
      >>> > code can potentially gain AllPermissions. This is in turn means that pure
      >>> > JavaScript script can gain AllPermissions due to problematic
      >>> > implementation of SecurityController.
      >
      >>
      >> I guess I am unaware of these bugs - do they rely on being able
      >> to create a class loader? If so the Rhino code is not allowed to do
      >> so.

      To be completely clear: the current implementation of
      org.mozilla.javascript.SecurityController in Batik allows scripts to run
      with the same permissions that Rhino classes have.

      Here is extract from
      ./resources/org/apache/batik/apps/svgbrowser/resources/svgbrowser.policy
      (other policy files have the same fragments) :

      grant codeBase "${app.dev.base}/lib/js.jar" {
      permission java.lang.RuntimePermission "createClassLoader";
      permission java.net.SocketPermission "*", "listen, connect, resolve,
      accept";
      permission java.lang.RuntimePermission "accessDeclaredMembers";
      permission java.util.PropertyPermission
      "org.mozilla.javascript.JavaAdapter", "read";
      permission java.util.PropertyPermission
      "org.mozilla.javascript.JavaAdapterClassName", "read";
      permission java.io.FilePermission "<<ALL FILES>>", "read";
      };

      Which means that Rhino classes and scripts they execute in the current
      Batik can create class loaders, make arbitrary network connections and
      read arbitrary files. If that is not enough, then the bugs in JVM
      ClassLoader implementations means that scripts can gain AllPemissions as
      long as they have "createClassLoader" permission.

      Attachments

        1. 26727.diff
          7 kB
          Igor Bukanov
        2. 26727.diff
          6 kB
          Igor Bukanov
        3. 26727.shutter.diff
          2 kB
          Igor Bukanov
        4. bad_security.svg
          2 kB
          Igor Bukanov
        5. security.patch
          5 kB
          Thomas DeWeese

        Activity

          People

            batik-dev@xmlgraphics.apache.org Batik Developer's Mailing list
            igor@fastmail.fm Igor Bukanov
            Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

            Dates

              Created:
              Updated:
              Resolved: