tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Craig R. McClanahan" <Craig.McClana...@eng.sun.com>
Subject Re: Kind of a wierd security request
Date Tue, 08 Aug 2000 23:27:59 GMT
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



Mime
View raw message