Rossen Raykov wrote:
With the Security Manager turned on, this "hack" will not work. So there is no security issue here. Of course without SecurityManager, you can do whatever you want.Probably you can define interface and use casting while you are accessing your Principle implementation. Frankly, I didn’t try it but it seems like usable solution.
There is another technique that is quarantined to work though. It is very simple and employs only Java’s Reflection. Four days ago I send an e-mail to [EMAIL PROTECTED] explaining how Reflection may be used to extract user’s password from org.apache.catalina.realm.GenericPrincipal and so fare I didn’t get any response. Probably this is not treated as security issue so let me make it public.
Attached you will find my original e-mail to [EMAIL PROTECTED] explaining
how this may be accomplished and how one can protect himself from such
exposure.
-- Jeanfrancois
Regards, Rossen Raykov
-----Original Message-----owto.html, so I'll use it's terminology.
From: John H [mailto:[EMAIL PROTECTED] Sent: Thursday, April 15, 2004 1:32 PM
To: Tomcat Users List
Subject: Re: Extending GenericPrincipal/RealmBase: Essentially a classloader question
Webapps can see GenericPrincipal only when I move catalina.jar to common/lib. That's the kicker. Catalina has supplied a nice generic principal that implements java.security.Principal in useful ways, but then prevents me from using it in my webapps (directly or through extensions).
I must be missing the reasoning behind that.
----- Original Message ----- From: "Benjamin Armintor" <[EMAIL PROTECTED]>
To: "Tomcat Users List" <[EMAIL PROTECTED]>
Sent: Thursday, April 15, 2004 12:34 PM
Subject: RE: Extending GenericPrincipal/RealmBase: Essentially a classloader question
Can your webapps see GenericPrincipal? Looking at the JavaDocs for the Catalina api, it looks like the session façade your get app gets is going to have access to a java.security.Principal (likely also a façade), not a GenericPrincipal. Maybe instead of extending a class in the server/Catalina classloader, you could implement another subclass of java.security.Principal, and have that class loaded in the common classloader.
Benjamin J. Armintor Systems Analyst ITS-Systems: Mainframe Group University of Texas - Austin tele: (512) 232-6562 email: [EMAIL PROTECTED]
-----Original Message-----
From: John H [mailto:[EMAIL PROTECTED]
Sent: Thursday, April 15, 2004 11:25 AM
To: Tomcat Users List
Subject: Extending GenericPrincipal/RealmBase: Essentially a classloader question
HI all,
He have implemented our own realm and principal buy extending org.apache.catalina.realm.RealmBase and GenericPrincipal.
(Using TC5.0.19 on Solaris and Windows. Realm defined in <Context>.)
By doing this, however, we've got ourselves into sort of a catch 22 in terms of classloading. Hopefully someone can offer some assistance.
I've referenced the Class Loader HOW-TO at http://jakarta.apache.org/tomcat/tomcat-5.0-doc/class-loader-h
RealmBase and GenericPrincipal are located in catalina.jar, which resides physically in server/lib. The howo defines this jar as in the Catalina class loader. The definition says that the Catalina classes are totally invisible to web applications, which seems true enough. In order to extend these, I must locate my jar in server/lib. So far so good.
The problem is that I need to use my extension of GenericPrincipal within my webapps.
I tried moving my jar to common/lib, since, according to the parent tree in the howto, it is visible to both the Catalina branch and the webapp branch. Doing this causes a NoClassDefFoundError for GenericPrincipal. Apparently since the Catalina classloader is below the common classloader, it can't find GenericPrincipal.
The only solution that appears to work is moving the entire contents of server/lib to common/lib, essentially 'promoting' all of the classes normally in the Catalina class loader to the common class loader.
Is this the best solution? It seems to me that I should be able to extend RealmBase/GenericPrincipal without having to move jars around.
Any ideas?
John
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
------------------------------------------------------------------------
Subject: Principal's password exposure From: "Rossen Raykov" <[EMAIL PROTECTED]> Date: Sun, 11 Apr 2004 23:31:07 -0400 To: <[EMAIL PROTECTED]>
Tomcat's implementation of java.security.Principal org.apache.catalina.realm.GenericPrincipal is exposing user's password to the applications.
Class info: GenericPrincipal is having method declared as: <code> public String getPassword() </code> which returns principal's password. This method is used by the various realm implementations in the same package.
Problem description:
Although GenericPrincipal is instantiated by a different class loader an
application may use Java's reflection to obtain principal's password.
This problem exists in both 4.x and 5.x implementations and probably in all
earlier versions.
Example: <code> Principal p = request.getUserPrincipal(); Method m = p.getClass().getMethod("getPassword", new Class[] {}); String pwd = (String) m.invoke(p, new Object [] {} ); </code>
Proposed solution:
The method descriptor should not be declared as public.
Leaving it with default visibility will prevent this problem from happening.
<code>
String getPassword()
</code>
Regards, Rossen Raykov
------------------------------------------------------------------------
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
