Velocity
  1. Velocity
  2. VELOCITY-179

prevent execution of methods on Class, ClassLoader and related classes

    Details

    • Type: Improvement Improvement
    • Status: Closed
    • Priority: Minor Minor
    • Resolution: Fixed
    • Affects Version/s: 1.4
    • Fix Version/s: 1.5
    • Component/s: Engine
    • Labels:
      None
    • Environment:
      Operating System: All
      Platform: All

      Description

      Template designers currently have the capability to acquire a ClassLoader,
      instantiate an arbitrary class, and call an arbitrary method. (Example: [1],
      although more compact examples exist). This is a drastic break with the MVC
      model, as template designers can execute any arbitary code. It gets worse if
      you have untrusted template designers who might call methods that erase files,
      execute arbitrary SQL code, or shut down the VM. This has been discussed on
      the dev list [2].

      This patch prevents any method from being called on objects of a class that
      has reflection, classloader, or runtime capabilities. (List at the end of the
      report [4]). It's configurable with a property, but the default is ON, as
      security restrictions, IMHO, should be strict by default.

      An alternate solution to this issue would be to prohibit the ClassLoader
      through the Java Security Manager, as proposed here [4]. I believe this
      solution to be too difficult for the typical developer. It's complex, and
      requires knowledge of the Velocity source code. Essentially, you have to
      split the files that execute the methods on the Java classes into a separate
      JAR file, then designate that jar file as not have permission to call
      getClassLoader. This requires that you (A) know what those Velocity classes
      are (B) understand how to work with the security manager, which is quite
      complex, and (C) have to modify the Velocity package every time there is a new
      release. I think it would be better if this is handled natively within
      Velocity.

      Finally, this patch does not include docs or test cases. I'd be willing to
      write both, if a committer is willing to put in the patch.

      [1] Example of VTL to call arbitray method
      http://nagoya.apache.org/eyebrowse/ReadMsg?listName=velocity-
      dev@jakarta.apache.org&msgNo=6114

      [2] Related discussion
      http://nagoya.apache.org/eyebrowse/ReadMsg?listId=102&msgNo=5980
      http://nagoya.apache.org/eyebrowse/ReadMsg?listName=velocity-
      user@jakarta.apache.org&msgNo=10444

      [3] Classes affected

      java.lang.Class
      java.lang.ClassLoader
      java.lang.Compiler
      java.lang.Package
      java.lang.Process
      java.lang.InheritableThreadLocal
      java.lang.Runtime
      java.lang.RuntimePermission
      java.lang.SecurityManager
      java.lang.System
      java.lang.Thread
      java.lang.ThreadGroup
      java.lang.ThreadLocal
      java.lang.reflect.*

      [4] Java security manager proposal
      http://nagoya.apache.org/eyebrowse/ReadMsg?listName=velocity-
      dev@jakarta.apache.org&msgNo=6012

      1. ASF.LICENSE.NOT.GRANTED--testcases.xml.patch
        2 kB
        Will Glass-Husain
      2. ASF.LICENSE.NOT.GRANTED--IntrospectorTestCase4.java
        7 kB
        Will Glass-Husain
      3. ASF.LICENSE.NOT.GRANTED--patch2b.txt
        7 kB
        Will Glass-Husain
      4. ASF.LICENSE.NOT.GRANTED--patch2.txt
        7 kB
        Will Glass-Husain
      5. ASF.LICENSE.NOT.GRANTED--patch1.txt
        1 kB
        Will Glass-Husain

        Activity

        Will Glass-Husain created issue -
        Jeff Turner made changes -
        Field Original Value New Value
        issue.field.bugzillaimportkey 20341 12315049
        Will Glass-Husain made changes -
        Assignee Velocity-Dev List [ velocity-dev@jakarta.apache.org ]
        Environment Operating System: All
        Platform: All
        Operating System: All
        Platform: All
        Description Template designers currently have the capability to acquire a ClassLoader,
        instantiate an arbitrary class, and call an arbitrary method. (Example: [1],
        although more compact examples exist). This is a drastic break with the MVC
        model, as template designers can execute any arbitary code. It gets worse if
        you have untrusted template designers who might call methods that erase files,
        execute arbitrary SQL code, or shut down the VM. This has been discussed on
        the dev list [2].

        This patch prevents any method from being called on objects of a class that
        has reflection, classloader, or runtime capabilities. (List at the end of the
        report [4]). It's configurable with a property, but the default is ON, as
        security restrictions, IMHO, should be strict by default.

        An alternate solution to this issue would be to prohibit the ClassLoader
        through the Java Security Manager, as proposed here [4]. I believe this
        solution to be too difficult for the typical developer. It's complex, and
        requires knowledge of the Velocity source code. Essentially, you have to
        split the files that execute the methods on the Java classes into a separate
        JAR file, then designate that jar file as not have permission to call
        getClassLoader. This requires that you (A) know what those Velocity classes
        are (B) understand how to work with the security manager, which is quite
        complex, and (C) have to modify the Velocity package every time there is a new
        release. I think it would be better if this is handled natively within
        Velocity.

        Finally, this patch does not include docs or test cases. I'd be willing to
        write both, if a committer is willing to put in the patch.

        [1] Example of VTL to call arbitray method
        http://nagoya.apache.org/eyebrowse/ReadMsg?listName=velocity-
        dev@jakarta.apache.org&msgNo=6114

        [2] Related discussion
        http://nagoya.apache.org/eyebrowse/ReadMsg?listId=102&msgNo=5980
        http://nagoya.apache.org/eyebrowse/ReadMsg?listName=velocity-
        user@jakarta.apache.org&msgNo=10444

        [3] Classes affected

        java.lang.Class
        java.lang.ClassLoader
        java.lang.Compiler
        java.lang.Package
        java.lang.Process
        java.lang.InheritableThreadLocal
        java.lang.Runtime
        java.lang.RuntimePermission
        java.lang.SecurityManager
        java.lang.System
        java.lang.Thread
        java.lang.ThreadGroup
        java.lang.ThreadLocal
        java.lang.reflect.*

        [4] Java security manager proposal
        http://nagoya.apache.org/eyebrowse/ReadMsg?listName=velocity-
        dev@jakarta.apache.org&msgNo=6012
        Template designers currently have the capability to acquire a ClassLoader,
        instantiate an arbitrary class, and call an arbitrary method. (Example: [1],
        although more compact examples exist). This is a drastic break with the MVC
        model, as template designers can execute any arbitary code. It gets worse if
        you have untrusted template designers who might call methods that erase files,
        execute arbitrary SQL code, or shut down the VM. This has been discussed on
        the dev list [2].

        This patch prevents any method from being called on objects of a class that
        has reflection, classloader, or runtime capabilities. (List at the end of the
        report [4]). It's configurable with a property, but the default is ON, as
        security restrictions, IMHO, should be strict by default.

        An alternate solution to this issue would be to prohibit the ClassLoader
        through the Java Security Manager, as proposed here [4]. I believe this
        solution to be too difficult for the typical developer. It's complex, and
        requires knowledge of the Velocity source code. Essentially, you have to
        split the files that execute the methods on the Java classes into a separate
        JAR file, then designate that jar file as not have permission to call
        getClassLoader. This requires that you (A) know what those Velocity classes
        are (B) understand how to work with the security manager, which is quite
        complex, and (C) have to modify the Velocity package every time there is a new
        release. I think it would be better if this is handled natively within
        Velocity.

        Finally, this patch does not include docs or test cases. I'd be willing to
        write both, if a committer is willing to put in the patch.

        [1] Example of VTL to call arbitray method
        http://nagoya.apache.org/eyebrowse/ReadMsg?listName=velocity-
        dev@jakarta.apache.org&msgNo=6114

        [2] Related discussion
        http://nagoya.apache.org/eyebrowse/ReadMsg?listId=102&msgNo=5980
        http://nagoya.apache.org/eyebrowse/ReadMsg?listName=velocity-
        user@jakarta.apache.org&msgNo=10444

        [3] Classes affected

        java.lang.Class
        java.lang.ClassLoader
        java.lang.Compiler
        java.lang.Package
        java.lang.Process
        java.lang.InheritableThreadLocal
        java.lang.Runtime
        java.lang.RuntimePermission
        java.lang.SecurityManager
        java.lang.System
        java.lang.Thread
        java.lang.ThreadGroup
        java.lang.ThreadLocal
        java.lang.reflect.*

        [4] Java security manager proposal
        http://nagoya.apache.org/eyebrowse/ReadMsg?listName=velocity-
        dev@jakarta.apache.org&msgNo=6012
        Fix Version/s 1.5 [ 12310253 ]
        Bugzilla Id 20341
        Will Glass-Husain made changes -
        Bugzilla Id 20341
        Fix Version/s 1.5 [ 12310253 ]
        Fix Version/s 1.6 [ 12310290 ]
        Henning Schmiedehausen made changes -
        Assignee Will Glass-Husain [ wglass ]
        Bugzilla Id 20341
        Will Glass-Husain made changes -
        Fix Version/s 1.5 [ 12310253 ]
        Fix Version/s 1.6 [ 12310290 ]
        Resolution Fixed [ 1 ]
        Status Open [ 1 ] Resolved [ 5 ]
        Henning Schmiedehausen made changes -
        Status Resolved [ 5 ] Closed [ 6 ]
        Mark Thomas made changes -
        Workflow jira [ 12325054 ] Default workflow, editable Closed status [ 12551929 ]
        Mark Thomas made changes -
        Workflow Default workflow, editable Closed status [ 12551929 ] jira [ 12552316 ]

          People

          • Assignee:
            Will Glass-Husain
            Reporter:
            Will Glass-Husain
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development