https://issues.apache.org/bugzilla/show_bug.cgi?id=48960

           Summary: SSI Servlet should support safe configuration
           Product: Tomcat 6
           Version: unspecified
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: major
          Priority: P2
         Component: Catalina
        AssignedTo: dev@tomcat.apache.org
        ReportedBy: yair.le...@citi.com


The current configuration of the SSI module is "All" or "None". The "ALL"
option will expose all the legacy Apache SSI directive (echo, printenv, if,
exec, ...). As documented, allowing SSI will allow execution of arbitrary
programs using the "exec". As a result, there is no safe way to expose
sites/projects containing SSI directive, without taking a security risk, or
reviewing of every file.

The "exec" directive, with the cmd option is a major risk. Even for Apache, you
have the option to allowing the "safe" include (includeNoExec). The
includeNoExec allow pages to be served, even when the content is not reviewed,
or when users are allowed to upload content to the site.

I have a big site which need to be converted into JSP. I would like to use the
SSI servlet to allow for transition over time. The extra risk from ( from exec
cmd) make it impossible to deploy the SSI.

My request: Modify the configuration of SSI as follow: By default, it will only
allow "safe" directive (no exec cmd=...). This will eliminate the risk from
arbitrary execution of commands ("del *.*"). It will also remove many potentail
load problems. The cmd= should only be allowed using a directive like
"allowUnsafeExec", which will default to false.

I think that the change will make it easier to use the SSI feature, without
exposing the server to big risk. The risk associated with the "safer" version
of SSI is similar to the risk from running JSP pages.

-- 
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Reply via email to