You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by Paul Speed <ps...@progeeks.com> on 2001/11/29 08:57:31 UTC
servlets-ssi.renametojar
Hello,
I'm currently looking into the security issues pertaining to enabling
this by default. I followed the conversation for why it is the way
it is, but now that I'm actually in the guts of the thing, I don't
think I fully understand.
The issue as I remember it is that the SsiExec class in servlets-ssi.jar
could be exploited even if SSI support wasn't enabled in the web.xml
file. The part I'm fuzzy on is how this can be true.
Since servlets-ssi.jar is loaded into the server class loader
(server/lib) it seems to me that it would be impossible for a rogue
webapp to access any classes in this jar.
In any case, my solution should protect from these kinds of attacks
also, I'm just not sure they're possible.
I'll be submitting a patch shortly that should allow SSI support to
be enabled by default but would require a specific configuration
change to get the "exec" directive to work.
-Paul Speed
P.S.: I'd be curious to know of anyone actually using the "exec"
directive. Looking at the code, I'm not sure I see how it works
for non-CGI stuff.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: servlets-ssi.renametojar
Posted by Paul Speed <ps...@progeeks.com>.
Hello,
In my playing around with security, I've been attempting to break-out
the AllPermission for the $(catalina.home}/server classes into
something more granular to allow more refined tweaking. Here's what I
have so far:
grant codeBase "file:${catalina.home}/server/-" {
permission java.lang.RuntimePermission "*";
permission java.io.FilePermission "<<ALL FILES>>",
"read,write,delete";
permission java.util.PropertyPermission "*", "read,write";
permission java.security.SecurityPermission "*";
permission java.net.SocketPermission "*:0-",
"accept,connect,listen,resolve";
permission java.net.NetPermission "*";
permission java.io.SerializablePermission "*";
permission org.apache.naming.JndiPermission "*";
};
I've already removed the execute from the FilePermission and I've
left out the reflection permission since that's a really really ugly
one. Some of the above are probably way too broad... but certainly
no broader than AllPermission. I decided to start from the other
end of the spectrum and work backwards. With the above, I can still
run my own stuff and the tester stuff.
Incidentally, the tester webapp fails to initialize when the security
manager is enabled. Since it uses PropertyEditorManager in one of
its files, it requires PropertyPermission "*", "read,write" in order
to run. I'm still trying to figure out how to enabled this just for
the tester app (I have it working if I stick it in the general grant
section). The docs in catalina.policy don't seem to be helping much.
The other curious thing about this particular error is that it doesn't
show up as an access failure when using the debugging built into the
security manager.
-Paul
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: servlets-ssi.renametojar
Posted by Paul Speed <ps...@progeeks.com>.
Glenn Nielsen wrote:
[snip]
>
> Glad to hear you had success using Tomcat with the Java SecurityManager.
> Where I work we have several different installs of Tomcat. All of them
> use a much more restrictive policy file than the default catalina.policy.
> At one point the Tomcat 4 Security Manager docs included an example
> of a more restrictive policy than the default catalina.policy that
> Tomcat 4 is distributed with. If I have time, I will update those docs
> for the Tomcat 4.0.2 release. And perhaps add an example catalina.policy
> to the distribution which is more restrictive. Hmmm, now that the
> framework is there for the admin web application, perhaps an easier
> to understand interface could be added to if for configuring the catalina.policy
> file.
I may have to take a look at these examples. Trying to whittle down
AllPermission by guess work is a daunting task to say the least. ;)
I'll RTFM before I complain too loudly. :)
>
> > All that being said, my patches for disabling the exec directive
> > might still be useful. Since it simply removes the directive from
> > consideration it causes it to be treated as an unknown command
> > rather than a security error. Currently, unknown commands can be
> > ignored with the correct option. In an ideal world, all of the
> > directives would be configurable but that seemed like overkill.
> >
>
> Yes, that might be useful. I just don't want to see Tomcat 4
> littered with alot of 'security' code when security can be enforced
> using the Java SecurityManager and a policy file.
I whole-heartedly agree with that.
-Paul
>
> > Anyway, I'm going to try and setup your proposal here locally
> > and see if I find any problems.
>
> Let me know how it works out.
>
> Thanks,
>
> Glenn
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: servlets-ssi.renametojar
Posted by Glenn Nielsen <gl...@voyager.apg.more.net>.
Paul Speed wrote:
>
> Glenn Nielsen wrote:
> >
> > I am pleased to see the interest in security issues.
> >
> > But when developing solutions for security issues we need to remember
> > that Tomcat4 can use the Java SecurityManager. And in almost all
> > cases the security needed can be achieved by using catalina.policy.
> > We should leverarge the Java SecurityManager as much as possible to
> > solve these types of security issues rather than writing and relying
> > on our own code to enforce security.
> >
> > The issue you are addressing Paul can also be addressed by my
> > PROPOSAL a week ago. If Tomcat is running with the Java SecurityManager
> > the SSI servlet can't perform an exec unless it has been granted permission
> > to do so.
>
> Yes. I like it. I hadn't thought about creating yet another class
> area to provide finer grain security for just the catalina servlets.
> I'll have to search for your original proposal and take a look. More
> below...
>
> >
> > --------------------------------------------------------------------------
> > 1. Create $CATALINA_HOME/servlets/lib and $CATALINA_HOME/servlets/classes.
> > This is where global servlets provided with Tomcat 4 can be installed.
> >
> > 2. Move the following jar files into $CATALINA_HOME/servlets/lib
> >
> > servlets-cgi.renametojar
> > servlets-common.jar
> > servlets-default.jar
> > servlets-invoker.jar
> > servlets-manager.jar
> > servlets-snoop.jar
> > servlets-ssi.jar
> > servlets-webdav.jar
> >
> > 3. Update the class loader creation in Bootstrap.java for the catalina loader
> > to look for jar files and classes in $CATALINA_HOME/servlets in addition
> > to $CATALINA_HOME/server.
> >
> > 4. Update the default catalina.policy so that it provides explicit
> > permissions for each jar file in $CATALINA_HOME/servlets/lib.
> >
> > 5. Update the documentation regarding the above changes.
> >
> > Please vote +1 so I can implement the above changes.
> > ------------------------------------------------------------------
>
> I'm not a committer but I'm willing to help with this. So that's my
> +1 for what it's worth.
>
> >
> > It is time to consider making use of the Java SecurityManager the
> > default startup option for Tomcat, or even require that Tomcat be
> > run with the Java SecurityManager.
>
> I agree. I had heard horror stories about getting tomcat to run
> with the security manager, but I found it very easy. It took me
> a bit to figure out that the server class loader runs with
> AllPermission and that's why Runtime.exec() is allowed in these
> servlets. I think that even with moving the servlets to their own
> area that the server policy should probably be finer grained.
> AllPermission is convenient but there are clearly a few things that
> that even these classes shouldn't be allowed to do. (Runtime.exec
> for example) Having the server area explicitly spell out its
> security needs will also make fine-tuning that security easier for
> the more paranoid sys admins.
>
Glad to hear you had success using Tomcat with the Java SecurityManager.
Where I work we have several different installs of Tomcat. All of them
use a much more restrictive policy file than the default catalina.policy.
At one point the Tomcat 4 Security Manager docs included an example
of a more restrictive policy than the default catalina.policy that
Tomcat 4 is distributed with. If I have time, I will update those docs
for the Tomcat 4.0.2 release. And perhaps add an example catalina.policy
to the distribution which is more restrictive. Hmmm, now that the
framework is there for the admin web application, perhaps an easier
to understand interface could be added to if for configuring the catalina.policy
file.
> All that being said, my patches for disabling the exec directive
> might still be useful. Since it simply removes the directive from
> consideration it causes it to be treated as an unknown command
> rather than a security error. Currently, unknown commands can be
> ignored with the correct option. In an ideal world, all of the
> directives would be configurable but that seemed like overkill.
>
Yes, that might be useful. I just don't want to see Tomcat 4
littered with alot of 'security' code when security can be enforced
using the Java SecurityManager and a policy file.
> Anyway, I'm going to try and setup your proposal here locally
> and see if I find any problems.
Let me know how it works out.
Thanks,
Glenn
----------------------------------------------------------------------
Glenn Nielsen glenn@more.net | /* Spelin donut madder |
MOREnet System Programming | * if iz ina coment. |
Missouri Research and Education Network | */ |
----------------------------------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: servlets-ssi.renametojar
Posted by Paul Speed <ps...@progeeks.com>.
Glenn Nielsen wrote:
>
> I am pleased to see the interest in security issues.
>
> But when developing solutions for security issues we need to remember
> that Tomcat4 can use the Java SecurityManager. And in almost all
> cases the security needed can be achieved by using catalina.policy.
> We should leverarge the Java SecurityManager as much as possible to
> solve these types of security issues rather than writing and relying
> on our own code to enforce security.
>
> The issue you are addressing Paul can also be addressed by my
> PROPOSAL a week ago. If Tomcat is running with the Java SecurityManager
> the SSI servlet can't perform an exec unless it has been granted permission
> to do so.
Yes. I like it. I hadn't thought about creating yet another class
area to provide finer grain security for just the catalina servlets.
I'll have to search for your original proposal and take a look. More
below...
>
> --------------------------------------------------------------------------
> 1. Create $CATALINA_HOME/servlets/lib and $CATALINA_HOME/servlets/classes.
> This is where global servlets provided with Tomcat 4 can be installed.
>
> 2. Move the following jar files into $CATALINA_HOME/servlets/lib
>
> servlets-cgi.renametojar
> servlets-common.jar
> servlets-default.jar
> servlets-invoker.jar
> servlets-manager.jar
> servlets-snoop.jar
> servlets-ssi.jar
> servlets-webdav.jar
>
> 3. Update the class loader creation in Bootstrap.java for the catalina loader
> to look for jar files and classes in $CATALINA_HOME/servlets in addition
> to $CATALINA_HOME/server.
>
> 4. Update the default catalina.policy so that it provides explicit
> permissions for each jar file in $CATALINA_HOME/servlets/lib.
>
> 5. Update the documentation regarding the above changes.
>
> Please vote +1 so I can implement the above changes.
> ------------------------------------------------------------------
I'm not a committer but I'm willing to help with this. So that's my
+1 for what it's worth.
>
> It is time to consider making use of the Java SecurityManager the
> default startup option for Tomcat, or even require that Tomcat be
> run with the Java SecurityManager.
I agree. I had heard horror stories about getting tomcat to run
with the security manager, but I found it very easy. It took me
a bit to figure out that the server class loader runs with
AllPermission and that's why Runtime.exec() is allowed in these
servlets. I think that even with moving the servlets to their own
area that the server policy should probably be finer grained.
AllPermission is convenient but there are clearly a few things that
that even these classes shouldn't be allowed to do. (Runtime.exec
for example) Having the server area explicitly spell out its
security needs will also make fine-tuning that security easier for
the more paranoid sys admins.
All that being said, my patches for disabling the exec directive
might still be useful. Since it simply removes the directive from
consideration it causes it to be treated as an unknown command
rather than a security error. Currently, unknown commands can be
ignored with the correct option. In an ideal world, all of the
directives would be configurable but that seemed like overkill.
Anyway, I'm going to try and setup your proposal here locally
and see if I find any problems.
-Paul
>
> Regards,
>
> Glenn
>
> Paul Speed wrote:
> >
> > Hello,
> >
> > I'm currently looking into the security issues pertaining to enabling
> > this by default. I followed the conversation for why it is the way
> > it is, but now that I'm actually in the guts of the thing, I don't
> > think I fully understand.
> >
> > The issue as I remember it is that the SsiExec class in servlets-ssi.jar
> > could be exploited even if SSI support wasn't enabled in the web.xml
> > file. The part I'm fuzzy on is how this can be true.
> >
> > Since servlets-ssi.jar is loaded into the server class loader
> > (server/lib) it seems to me that it would be impossible for a rogue
> > webapp to access any classes in this jar.
> >
> > In any case, my solution should protect from these kinds of attacks
> > also, I'm just not sure they're possible.
> >
> > I'll be submitting a patch shortly that should allow SSI support to
> > be enabled by default but would require a specific configuration
> > change to get the "exec" directive to work.
> >
> > -Paul Speed
> >
> > P.S.: I'd be curious to know of anyone actually using the "exec"
> > directive. Looking at the code, I'm not sure I see how it works
> > for non-CGI stuff.
> >
> > --
> > To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> > For additional commands, e-mail: <ma...@jakarta.apache.org>
>
> --
> ----------------------------------------------------------------------
> Glenn Nielsen glenn@more.net | /* Spelin donut madder |
> MOREnet System Programming | * if iz ina coment. |
> Missouri Research and Education Network | */ |
> ----------------------------------------------------------------------
>
> --
> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: servlets-ssi.renametojar
Posted by Glenn Nielsen <gl...@voyager.apg.more.net>.
I am pleased to see the interest in security issues.
But when developing solutions for security issues we need to remember
that Tomcat4 can use the Java SecurityManager. And in almost all
cases the security needed can be achieved by using catalina.policy.
We should leverarge the Java SecurityManager as much as possible to
solve these types of security issues rather than writing and relying
on our own code to enforce security.
The issue you are addressing Paul can also be addressed by my
PROPOSAL a week ago. If Tomcat is running with the Java SecurityManager
the SSI servlet can't perform an exec unless it has been granted permission
to do so.
--------------------------------------------------------------------------
1. Create $CATALINA_HOME/servlets/lib and $CATALINA_HOME/servlets/classes.
This is where global servlets provided with Tomcat 4 can be installed.
2. Move the following jar files into $CATALINA_HOME/servlets/lib
servlets-cgi.renametojar
servlets-common.jar
servlets-default.jar
servlets-invoker.jar
servlets-manager.jar
servlets-snoop.jar
servlets-ssi.jar
servlets-webdav.jar
3. Update the class loader creation in Bootstrap.java for the catalina loader
to look for jar files and classes in $CATALINA_HOME/servlets in addition
to $CATALINA_HOME/server.
4. Update the default catalina.policy so that it provides explicit
permissions for each jar file in $CATALINA_HOME/servlets/lib.
5. Update the documentation regarding the above changes.
Please vote +1 so I can implement the above changes.
------------------------------------------------------------------
It is time to consider making use of the Java SecurityManager the
default startup option for Tomcat, or even require that Tomcat be
run with the Java SecurityManager.
Regards,
Glenn
Paul Speed wrote:
>
> Hello,
>
> I'm currently looking into the security issues pertaining to enabling
> this by default. I followed the conversation for why it is the way
> it is, but now that I'm actually in the guts of the thing, I don't
> think I fully understand.
>
> The issue as I remember it is that the SsiExec class in servlets-ssi.jar
> could be exploited even if SSI support wasn't enabled in the web.xml
> file. The part I'm fuzzy on is how this can be true.
>
> Since servlets-ssi.jar is loaded into the server class loader
> (server/lib) it seems to me that it would be impossible for a rogue
> webapp to access any classes in this jar.
>
> In any case, my solution should protect from these kinds of attacks
> also, I'm just not sure they're possible.
>
> I'll be submitting a patch shortly that should allow SSI support to
> be enabled by default but would require a specific configuration
> change to get the "exec" directive to work.
>
> -Paul Speed
>
> P.S.: I'd be curious to know of anyone actually using the "exec"
> directive. Looking at the code, I'm not sure I see how it works
> for non-CGI stuff.
>
> --
> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
--
----------------------------------------------------------------------
Glenn Nielsen glenn@more.net | /* Spelin donut madder |
MOREnet System Programming | * if iz ina coment. |
Missouri Research and Education Network | */ |
----------------------------------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
[PATCH] SSI Security
Posted by Paul Speed <ps...@progeeks.com>.
As promissed...
I've attached my patches to allow the "exec" directive to be enabled
or disabled (disabled by default). The extra safety check I've built
in isn't really necessary, but it causes no harm and may prevent some
accidental foot-shootings in the future.
ssi-exec.patch is a diff -u from the catalina/src directory. (We'll
see if the attachment actually works to the list since I've had
problems with that before.)
Left up to discussion is the vulnerability of the jar file itself.
I contend that since the jar is in the server/lib class loader that
it is perfectly safe. Indeed, when I played with moving it into
shared it resulted in broken dependencies with at least one class
in server/lib.
If it is not safe then it brings up a larger issue since all
server/lib class have AllPermission and can therefore do whatever
they want. If these classes are exploitable by webapps then it seems
to me that security should be set more fine grained (including not
allowing file execute for any file). Otherwise, there's always risk
that some backdoor will be left open.
-Paul