You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by Jean-Francois Arcand <jf...@apache.org> on 2002/10/08 22:36:30 UTC
[Proposal] Security Audit
Hi,
I'm looking to do a Security Audit on the current Tomcat 5.0 codebase. I
would like to collect as more as information as where you think I should
look at (code, security hole, etc.). I'm planning to do the audit using
the default SecurityManager. Rigth now, I have started looking at:
- doPrivilege blocks. Are they small enough? Can they be reduced?
- JSP generated code. Are they secure? Can a malicious app uses the code
to access o.a.catalina code?
- Is catalina.policy restricted enough?
- Is our Classloader secure?
Any direction/ideas/recommendations will be appreciated.
Thanks,
-- Jeanfrancois
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [Proposal] Security Audit
Posted by Ian Darwin <ia...@darwinsys.com>.
> I'm looking to do a Security Audit on the current Tomcat 5.0 codebase. I
> would like to collect as more as information as where you think I should
> look at (code, security hole, etc.). I'm planning to do the audit using
> the default SecurityManager. Rigth now, I have started looking at:
Although their goals and technology are different (an OS written in C),
I believe anyone interested in helping might learn a lot by looking at OpenBSD (a
free UNIX-like OS whose entire code base has been subjected to a careful (and
ongoing!) security audit). They have some papers online;
go to www.openbsd.org and look at press.html (which has links to various
papers). Look for "auditing".
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [Proposal] Security Audit
Posted by Jean-Francois Arcand <jf...@apache.org>.
Costin Manolache wrote:
>AFAIK, the most important check is doPriviledged(). What we need
>to look for is if any of those blocks could be used by
>untrusted code to do something.
>
>The second very important check is the facades - making sure
>untrusted code can't get access to the real objects.
>
>We should also make sure that the facades are not reused or
>are reused only inside a context.
>
>It is nice to review all code for security and bugs ( and general
>quality ) - but IMO it is more important to review first the
>critical areas.
>
I will start looking at the doPrivilege block. One thing that I have
found is most Tomcat's doPrivilege block contains more operations that
they should. Minimizing what we put inside the doPrivilege is very
important. As an example (need to be optimized), I made some change to
the WebappClassLoader (see the diff.txt).
>
>The ClassLoader shouldn't create any major problems ( at least in
>delegating mode - in non delegating mode we can only trust the
>servlet experts that they did the resarch and can guarantee there's
>no security implications. I haven't heard anything convincing on this, but
>they should have this knowledge - otherwise it wouldn't be in the spec :-)
>
Other areas we can look first are:
- Admin Tool. Is the tool secure enougth?
- Invoker/Defaut Servlet ;-)
- The code Jasper generates. This is one place where facade will get
accessed.
-- Jeanfrancois
>
>
>Costin
>
>Bob Herrmann wrote:
>
>
>
>>FYI, Just to start off, I am going to review these classes. If
>>someone else also reviews them, thats probably a good thing...
>>
>># classes, package name
>>
>>17 o.a.c.deploy
>>9 o.a.c.users
>>44 o.a.c.*
>>34 o.a.jk.*
>>15 j.s.http
>>
>>Briefly, I am going to look for
>> - How/if a ClassLoader is used
>> - privilege blocks (are they small, use trusted values)
>> - look for non-final static variables (can they be abused)
>> - can methods/fields be made private?
>> - are mutable objects returned to caller (especially arrays)
>> think about returning clones
>> - non final equals/hashcode methods? (accessing sensitive stuff?)
>> - Serializable (exposes private stuff?)
>>
>>Does anyone publish a security checklist list like this?
>>
>>Blah Blah,
>>-bob
>>
>>
>>On Tue, 2002-10-08 at 16:36, Jean-Francois Arcand wrote:
>>
>>
>>>Hi,
>>>
>>>I'm looking to do a Security Audit on the current Tomcat 5.0 codebase. I
>>>would like to collect as more as information as where you think I should
>>>look at (code, security hole, etc.). I'm planning to do the audit using
>>>the default SecurityManager. Rigth now, I have started looking at:
>>>
>>>- doPrivilege blocks. Are they small enough? Can they be reduced?
>>>- JSP generated code. Are they secure? Can a malicious app uses the code
>>>to access o.a.catalina code?
>>>- Is catalina.policy restricted enough?
>>>- Is our Classloader secure?
>>>
>>>Any direction/ideas/recommendations will be appreciated.
>>>
>>>Thanks,
>>>
>>>-- Jeanfrancois
>>>
>>>
>>>--
>>>To unsubscribe, e-mail:
>>><ma...@jakarta.apache.org> For additional
>>>commands, e-mail: <ma...@jakarta.apache.org>
>>>
>>>
>
>
>
Re: [Proposal] Security Audit
Posted by Costin Manolache <cm...@yahoo.com>.
AFAIK, the most important check is doPriviledged(). What we need
to look for is if any of those blocks could be used by
untrusted code to do something.
The second very important check is the facades - making sure
untrusted code can't get access to the real objects.
We should also make sure that the facades are not reused or
are reused only inside a context.
It is nice to review all code for security and bugs ( and general
quality ) - but IMO it is more important to review first the
critical areas.
The ClassLoader shouldn't create any major problems ( at least in
delegating mode - in non delegating mode we can only trust the
servlet experts that they did the resarch and can guarantee there's
no security implications. I haven't heard anything convincing on this, but
they should have this knowledge - otherwise it wouldn't be in the spec :-)
Costin
Bob Herrmann wrote:
> FYI, Just to start off, I am going to review these classes. If
> someone else also reviews them, thats probably a good thing...
>
> # classes, package name
>
> 17 o.a.c.deploy
> 9 o.a.c.users
> 44 o.a.c.*
> 34 o.a.jk.*
> 15 j.s.http
>
> Briefly, I am going to look for
> - How/if a ClassLoader is used
> - privilege blocks (are they small, use trusted values)
> - look for non-final static variables (can they be abused)
> - can methods/fields be made private?
> - are mutable objects returned to caller (especially arrays)
> think about returning clones
> - non final equals/hashcode methods? (accessing sensitive stuff?)
> - Serializable (exposes private stuff?)
>
> Does anyone publish a security checklist list like this?
>
> Blah Blah,
> -bob
>
>
> On Tue, 2002-10-08 at 16:36, Jean-Francois Arcand wrote:
>> Hi,
>>
>> I'm looking to do a Security Audit on the current Tomcat 5.0 codebase. I
>> would like to collect as more as information as where you think I should
>> look at (code, security hole, etc.). I'm planning to do the audit using
>> the default SecurityManager. Rigth now, I have started looking at:
>>
>> - doPrivilege blocks. Are they small enough? Can they be reduced?
>> - JSP generated code. Are they secure? Can a malicious app uses the code
>> to access o.a.catalina code?
>> - Is catalina.policy restricted enough?
>> - Is our Classloader secure?
>>
>> Any direction/ideas/recommendations will be appreciated.
>>
>> Thanks,
>>
>> -- Jeanfrancois
>>
>>
>> --
>> To unsubscribe, e-mail:
>> <ma...@jakarta.apache.org> For additional
>> commands, e-mail: <ma...@jakarta.apache.org>
--
Costin
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [Proposal] Security Audit
Posted by Bob Herrmann <bo...@jadn.com>.
FYI, Just to start off, I am going to review these classes. If
someone else also reviews them, thats probably a good thing...
# classes, package name
17 o.a.c.deploy
9 o.a.c.users
44 o.a.c.*
34 o.a.jk.*
15 j.s.http
Briefly, I am going to look for
- How/if a ClassLoader is used
- privilege blocks (are they small, use trusted values)
- look for non-final static variables (can they be abused)
- can methods/fields be made private?
- are mutable objects returned to caller (especially arrays)
think about returning clones
- non final equals/hashcode methods? (accessing sensitive stuff?)
- Serializable (exposes private stuff?)
Does anyone publish a security checklist list like this?
Blah Blah,
-bob
On Tue, 2002-10-08 at 16:36, Jean-Francois Arcand wrote:
> Hi,
>
> I'm looking to do a Security Audit on the current Tomcat 5.0 codebase. I
> would like to collect as more as information as where you think I should
> look at (code, security hole, etc.). I'm planning to do the audit using
> the default SecurityManager. Rigth now, I have started looking at:
>
> - doPrivilege blocks. Are they small enough? Can they be reduced?
> - JSP generated code. Are they secure? Can a malicious app uses the code
> to access o.a.catalina code?
> - Is catalina.policy restricted enough?
> - Is our Classloader secure?
>
> Any direction/ideas/recommendations will be appreciated.
>
> Thanks,
>
> -- Jeanfrancois
>
>
> --
> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
--
Bob Herrmann <bo...@jadn.com>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [Proposal] Security Audit
Posted by Glenn Nielsen <gl...@mail.more.net>.
The more who review/audit tomcat for security, the better. :-)
Comments intermixed below.
Jean-Francois Arcand wrote:
> Hi,
>
> I'm looking to do a Security Audit on the current Tomcat 5.0 codebase. I
> would like to collect as more as information as where you think I should
> look at (code, security hole, etc.). I'm planning to do the audit using
> the default SecurityManager. Rigth now, I have started looking at:
>
> - doPrivilege blocks. Are they small enough? Can they be reduced?
I don't think there are more than a dozen doPrivileged() blocks in all
of catalina and jasper. They are relatively few and restricted to a
few specific methods in catalina which may get executed by some action
a servlet or jsp performs. For example, when a jsp page does a forward.
> - JSP generated code. Are they secure? Can a malicious app uses the code
> to access o.a.catalina code?
Class restrictions are implemented in two ways.
First, the catalina core API's are in server/lib so that they are not
one of the parent class loaders visible to a web app. Second, the
WebappClassLoader implements checkPackageAccess() and checkPackageDefinition().
These are only implemented if Tomcat was started with the SecurityManager.
One change we considered with Tomcat 4 was whether it should require using
the Java SecurityManager. You may want to open up that debate again with
Tomcat 5.
> - Is catalina.policy restricted enough?
Not for my needs, my security policies are much more restrictive.
But restrictive enough for some users. Perhaps there should be a second more
restrictive example catalina.policy.
> - Is our Classloader secure?
>
> Any direction/ideas/recommendations will be appreciated.
>
I don't have time right now to particpate in the security audit, but I will
make sure I review any findings.
One item that has been on my todo list for a while is a document on how to
write SecurityManager and web application friendly code. I find numerous
packages, frameworks, etc. which perform things in ways which are not
friendly to the SecurityManager or a web application.
I have been known to file bug reports with other jakarta projects when I run
across these issues. :-)
Regards,
Glenn
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [Proposal] Security Audit
Posted by Bob Herrmann <bo...@jadn.com>.
I can't think of anything more boring and tedious (bug fixing?) but I am
willing to help. Maybe we should divide up the classes.
Cheers,
-bob
On Tue, 2002-10-08 at 16:36, Jean-Francois Arcand wrote:
> Hi,
>
> I'm looking to do a Security Audit on the current Tomcat 5.0 codebase. I
> would like to collect as more as information as where you think I should
> look at (code, security hole, etc.). I'm planning to do the audit using
> the default SecurityManager. Rigth now, I have started looking at:
>
> - doPrivilege blocks. Are they small enough? Can they be reduced?
> - JSP generated code. Are they secure? Can a malicious app uses the code
> to access o.a.catalina code?
> - Is catalina.policy restricted enough?
> - Is our Classloader secure?
>
> Any direction/ideas/recommendations will be appreciated.
>
> Thanks,
>
> -- Jeanfrancois
>
>
> --
> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
--
Bob Herrmann <bo...@jadn.com>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>