Kind of a wierd security request

[Michael Rimov <ri...@centercomp.com>]

Hello All,

<FlameProofing Statement>
This may be better directed specifically to the Tomcat Developers.  Please 
correct me if  I'm wrong, please converse with me if you think I might be 
wrong :-)
</FlameProofing Statement>

I just got done reading eWeek's summary on how OpenHack was struck 
down.  The biggest thing that allowed the person that cracked the system to 
penetrate as far as he did was the fact that Perl was running and the 
hacker could run perl scripts with the same permissions as the eCommerce 
that was utilizing perl.

Ok, so what's my point?  Well, because of the servlet engine running on top 
of a JVM, it most likely will allow hackers,  one way or another, to 
execute arbitrary Java code with the same permissions of the servlet 
container.  I'm also concerned about people putting Trojan servlets in the 
system.  Now, of course, a lot of this problem may be mitigated though 
proper permission settings, but who ever really gets it perfect?

So what I'd really like to see is a modification to the Tomcat Class Loader 
that allows (upon an option within the config file) to refuse to load any 
servlet unless the jar/war has been signed by somebody you expect.

Because I'm talking about war files, this should take care of JSP pages 
too, right?  The option, of course, would effectively block anything that 
wasn't packaged in a WAR/JAR file.

Of course, it would be really slick if this could _also_ be done with the 
JVM's default class loader, so no arbitrary classes with a main function 
would be executed unless it was also packaged and signed.  But since that's 
the JVM and this is the Tomcat list, I won't go down that road, and I don't 
even know if its possible.  (I'm very much a newbie to the java environment)

Can anybody comment?  Is this something that could possibly go into the 
Developer's wish-list or is this something that's better done (due to 
library requirements) by spinning off a different project?

Thanks for any input on this!
						-Mike

Re: Kind of a wierd security request

[Michael Rimov <ri...@centercomp.com>]

>This is the sort of discussion that is germane on the TOMCAT-DEV mailing list
>... you might consider subscribing there and posing these questions.  I do 
>have
>a few scattered comments, although not really any definitive answer for you.

Very true.  After I read up on the Java security api's that you've talked 
about, I may follow up there.

>If you set up CGI environments wrong, you've got pretty much the same 
>potential
>vulnerabilities.  The language in use is by no means the only issue.
True, that's why I'm attempting to find out how to cross apply it to the 
java environment.  I don't recall ever really seeing any major posts on the 
BugTraq list regarding java-based servers, so I'm kind of fishing for 
problems that the java language in-itself doesn't take care of .

> > Because I'm talking about war files, this should take care of JSP pages
> > too, right?  The option, of course, would effectively block anything that
> > wasn't packaged in a WAR/JAR file.
> >
>
>You could do this too, but it's a lot more work -- Tomcat currently has to
>unpack a WAR file to actually run the application, because it has internal
>assumptions that resources like JSP pages are in disk files.

Bummer.  Thanks for the information on that.

>Check out the security model that is built in to Java -- especially the fine
>grained enhancements added with JDK 1.2.  And check out the ability to run a
>Tomcat web app under a security manager where you configure the permissions.
>You'll find that there is a lot of room to accomplish thse kinds of things,
>without touching anything other than the startup scripts for Tomcat.

Fantastic.  I really appreciate this, and I suspect that it will do a lot 
to prevent the kind of issues I'm looking at.

>serious (and most likely) issue -- where an attacker gets write access to your
>server's disk.  If they have that, they can sign WARs with the names you 
>expect
>(for example), bypassing any security you've built in.  I'm not saying "don't
>bother implementing security inside Tomcat".  I am saying "don't rely on
>implementing security inside Tomcat to protect you from all possible attacks."

That's true, of course.  And I totally agree with you.  I do look at it as 
"onion skin" security, in that I'm looking at putting on as many layers 
that have to be broken through as possible.

Thank you for your very informative reply!
                                                 -Mike

Re: Kind of a wierd security request

["Craig R. McClanahan" <Cr...@eng.sun.com>]

Michael Rimov wrote:

> Hello All,
>
> <FlameProofing Statement>
> This may be better directed specifically to the Tomcat Developers.  Please
> correct me if  I'm wrong, please converse with me if you think I might be
> wrong :-)
> </FlameProofing Statement>
>

This is the sort of discussion that is germane on the TOMCAT-DEV mailing list
... you might consider subscribing there and posing these questions.  I do have
a few scattered comments, although not really any definitive answer for you.

>
> I just got done reading eWeek's summary on how OpenHack was struck
> down.  The biggest thing that allowed the person that cracked the system to
> penetrate as far as he did was the fact that Perl was running and the
> hacker could run perl scripts with the same permissions as the eCommerce
> that was utilizing perl.
>

If you set up CGI environments wrong, you've got pretty much the same potential
vulnerabilities.  The language in use is by no means the only issue.

>
> Ok, so what's my point?  Well, because of the servlet engine running on top
> of a JVM, it most likely will allow hackers,  one way or another, to
> execute arbitrary Java code with the same permissions of the servlet
> container.  I'm also concerned about people putting Trojan servlets in the
> system.  Now, of course, a lot of this problem may be mitigated though
> proper permission settings, but who ever really gets it perfect?
>

Injecting code into a servlet container (like Tomcat) means one of two things is
going on:

* Your servlet container supports loading code from "foreign" places
  at all -- either because the internal class loader itself loads from
  arbitrary places, or because it lets you write and install a servlet
  that defines a class loader that loads from arbirary places.

* Your attacker has gained write access to the TOMCAT_HOME
  directory -- in which case nothing you do inside the JVM is going
  to protect you in the slightest, since he/she can work around the
  problem.

On the first thing, Tomcat's class loader loads from defined places -- although
since it is open source, it could certainly be modified to load across the
network, but then you are on your own.  Also, Tomcat can be configured to run
web applications under a security manager, so you can configure such things as
"you cannot talk to the network" or "you cannot create a thread" or "you cannot
create your own classloader".  The name of the game is to not allow foreign code
at all.

On the second thing, you've got much more serious problems than servlet security
to deal with :-)

>
> So what I'd really like to see is a modification to the Tomcat Class Loader
> that allows (upon an option within the config file) to refuse to load any
> servlet unless the jar/war has been signed by somebody you expect.
>

This is technically feasible, but means you would be giving up the ability to
run "unpacked" web apps that have classes under WEB-INF/classes.

>
> Because I'm talking about war files, this should take care of JSP pages
> too, right?  The option, of course, would effectively block anything that
> wasn't packaged in a WAR/JAR file.
>

You could do this too, but it's a lot more work -- Tomcat currently has to
unpack a WAR file to actually run the application, because it has internal
assumptions that resources like JSP pages are in disk files.

>
> Of course, it would be really slick if this could _also_ be done with the
> JVM's default class loader, so no arbitrary classes with a main function
> would be executed unless it was also packaged and signed.  But since that's
> the JVM and this is the Tomcat list, I won't go down that road, and I don't
> even know if its possible.  (I'm very much a newbie to the java environment)
>

Check out the security model that is built in to Java -- especially the fine
grained enhancements added with JDK 1.2.  And check out the ability to run a
Tomcat web app under a security manager where you configure the permissions.
You'll find that there is a lot of room to accomplish thse kinds of things,
without touching anything other than the startup scripts for Tomcat.

>
> Can anybody comment?  Is this something that could possibly go into the
> Developer's wish-list or is this something that's better done (due to
> library requirements) by spinning off a different project?
>
> Thanks for any input on this!
>

These kinds of security things are doable, but they do not deal with the most
serious (and most likely) issue -- where an attacker gets write access to your
server's disk.  If they have that, they can sign WARs with the names you expect
(for example), bypassing any security you've built in.  I'm not saying "don't
bother implementing security inside Tomcat".  I am saying "don't rely on
implementing security inside Tomcat to protect you from all possible attacks."

>                                                 -Mike

Craig McClanahan