tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeanfrancois Arcand <jfarc...@apache.org>
Subject Re: Extending GenericPrincipal/RealmBase: Essentially a classloader question
Date Fri, 16 Apr 2004 14:12:24 GMT


Rossen Raykov wrote:

>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 security@apache.org 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 security@apache.org explaining
>how this may be accomplished and how one can protect himself from such
>exposure.
>  
>
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.

-- Jeanfrancois


>Regards,
>Rossen Raykov
>
>
>  
>
>>-----Original Message-----
>>From: John H [mailto:tomcatlist@bellsouth.net] 
>>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" <Ben.Armintor@austin.utexas.edu>
>>To: "Tomcat Users List" <tomcat-user@jakarta.apache.org>
>>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: b.armintor@its.utexas.edu
>>
>>
>>
>>-----Original Message-----
>>From: John H [mailto:tomcatlist@bellsouth.net]
>>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
>>    
>>
>owto.html, so I'll use it's terminology.
>
>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: tomcat-user-unsubscribe@jakarta.apache.org
>For additional commands, e-mail: tomcat-user-help@jakarta.apache.org
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
>For additional commands, e-mail: tomcat-user-help@jakarta.apache.org
>
>  
>
>
> ------------------------------------------------------------------------
>
> Subject:
> Principal's password exposure
> From:
> "Rossen Raykov" <raykovr@hotmail.com>
> Date:
> Sun, 11 Apr 2004 23:31:07 -0400
> To:
> <security@apache.org>
>
>
> 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: tomcat-user-unsubscribe@jakarta.apache.org
>For additional commands, e-mail: tomcat-user-help@jakarta.apache.org
>


---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-user-help@jakarta.apache.org


Mime
View raw message