You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by bu...@apache.org on 2001/03/12 22:27:37 UTC
[Bug 389] New - Security Issue? Important attributes exposed by ServletContext can be modified BugRat Report#682
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=389
*** shadow/389 Mon Mar 12 13:27:37 2001
--- shadow/389.tmp.1035 Mon Mar 12 13:27:37 2001
***************
*** 0 ****
--- 1,22 ----
+ +============================================================================+
+ | Security Issue? Important attributes exposed by ServletContext can be modi |
+ +----------------------------------------------------------------------------+
+ | Bug #: 389 Product: Tomcat 4 |
+ | Status: UNCONFIRMED Version: 4.0 Beta 1 |
+ | Resolution: Platform: All |
+ | Severity: Normal OS/Version: All |
+ | Priority: High Component: Catalina |
+ +----------------------------------------------------------------------------+
+ | Assigned To: craig.mcclanahan@eng.sun.com |
+ | Reported By: rmandava@talentportal.com |
+ | CC list: Cc: |
+ +----------------------------------------------------------------------------+
+ | URL: |
+ +============================================================================+
+ | DESCRIPTION |
+ Hi:
+
+ The attributes such as "org.apache.catalina.classloader", "org.apache.catalina.jsp_classpath" are exposed through ServletContext and can be easily modified. No security violation is generated and anybody with an application installed on the web server can modify these variables. Is n't it a security problem for Tomcat?
+
+ Thanks
+ -Ramesh
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, email: tomcat-dev-help@jakarta.apache.org
Re: [Bug 389] New - Security Issue? Important attributes exposed
byServletContext can be modified BugRat Report#682
Posted by "Craig R. McClanahan" <cr...@apache.org>.
On Mon, 12 Mar 2001, Glenn Nielsen wrote:
> "Craig R. McClanahan" wrote:
> >
> > On Mon, 12 Mar 2001, Glenn Nielsen wrote:
> >
> > > The latest version of Tomcat 4.0 from CVS supports the Java SecurityManager.
> > > Tomcat 4.0 Beta 1 did not.
> > >
> > > The Java SecurityManager can restrict access to those properties and do a
> > > great deal more to assist you in running a secure application server.
> > >
> > > I wouldn't consider what you reported as a bug now that the Java SecurityManager
> > > has been implemented.
> > >
> >
> > I think the issue is still real (assuming that you don't have total
> > control over the code installed in your web app), because context
> > attributes are mutable. These attributes were originally introduced to
> > avoid code dependencies between Jasper and the servlet container it runs
> > in. Now that we have a JNDI context, I think that might be a more
> > appropriate mechanism, because the context itself is immutable.
> >
>
> Sounds like a good idea. I have been finding JNDI very handy for populating
> resources to Tomcat Hosts.
>
On that topic, the J2EE spec recommends having resources available for
implementations of javax.mail.Session and javax.mail.Transport. I don't
have a problem with your specialized object factory for messaging, but
what do you think about building generic ones for Session and Transport as
well?
> > > BTW, if you are attending ApacheCon 2001 Apr 4-6, I will be presenting a session on
> > > "Tomcat Server and Application Security" that goes into great detail on
> > > how the Java SecurityManager works and using it with Tomcat.
> > >
> >
>
> Make that:
>
> - F03 "Tomcat Server and Application Security"
>
I will definitely be there, and look forward to meeting you in person.
> > Gee, maybe I'd better come and learn :-). I will definitely be there,
> > because I'm presenting two other Tomcat related sessions and one on web
> > application architectures:
> > - TH13 "The Tomcat Servlet Container" (will cover 4.0 architecture)
> > - TH09 "Migrating Apache JServ Applications to Tomcat"
> > - W16 "Recommendations for Java-Based Web Application Architectures"
> >
>
> Sheesh, I had enough trouble getting 1 presentation ready on time, let alone three!
> No wonder you have been relatively inactive on these lists lately.
>
You know how, when you're budgeting, you ask for more than you expect to
get so you'll be satisfied with the results? Well, they accepted many
more of my proposals than I expected.
But that's nothing compared to what JavaOne did to me (three sessions and
four BOFs). I will definitely be using StarOffice as much as Emacs over
the next few weeks. Fortunately, there is at least some overlap in
subject matter.
> BTW, did you see my proposal regarding how Tomcat 4.0 should handle
> unpacking of war files? I would like to implement it this week.
> Any comments on that?
>
One other reason for relative inactivity is that my token card enabling
remote access to my Sun email account decided to die, so I haven't seen
anything on the mailing lists from about Wednesday through Friday last
week. Could you resent this proposal (to me privately is fine since
everyone else has seen it)?
> Regards,
>
> Glenn
>
Craig
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, email: tomcat-dev-help@jakarta.apache.org
Re: [Bug 389] New - Security Issue? Important attributes exposed
byServletContext can be modified BugRat Report#682
Posted by Glenn Nielsen <gl...@voyager.apg.more.net>.
"Craig R. McClanahan" wrote:
>
> On Mon, 12 Mar 2001, Glenn Nielsen wrote:
>
> > The latest version of Tomcat 4.0 from CVS supports the Java SecurityManager.
> > Tomcat 4.0 Beta 1 did not.
> >
> > The Java SecurityManager can restrict access to those properties and do a
> > great deal more to assist you in running a secure application server.
> >
> > I wouldn't consider what you reported as a bug now that the Java SecurityManager
> > has been implemented.
> >
>
> I think the issue is still real (assuming that you don't have total
> control over the code installed in your web app), because context
> attributes are mutable. These attributes were originally introduced to
> avoid code dependencies between Jasper and the servlet container it runs
> in. Now that we have a JNDI context, I think that might be a more
> appropriate mechanism, because the context itself is immutable.
>
Sounds like a good idea. I have been finding JNDI very handy for populating
resources to Tomcat Hosts.
> > BTW, if you are attending ApacheCon 2001 Apr 4-6, I will be presenting a session on
> > "Tomcat Server and Application Security" that goes into great detail on
> > how the Java SecurityManager works and using it with Tomcat.
> >
>
Make that:
- F03 "Tomcat Server and Application Security"
> Gee, maybe I'd better come and learn :-). I will definitely be there,
> because I'm presenting two other Tomcat related sessions and one on web
> application architectures:
> - TH13 "The Tomcat Servlet Container" (will cover 4.0 architecture)
> - TH09 "Migrating Apache JServ Applications to Tomcat"
> - W16 "Recommendations for Java-Based Web Application Architectures"
>
Sheesh, I had enough trouble getting 1 presentation ready on time, let alone three!
No wonder you have been relatively inactive on these lists lately.
BTW, did you see my proposal regarding how Tomcat 4.0 should handle
unpacking of war files? I would like to implement it this week.
Any comments on that?
Regards,
Glenn
----------------------------------------------------------------------
Glenn Nielsen glenn@more.net | /* Spelin donut madder |
MOREnet System Programming | * if iz ina coment. |
Missouri Research and Education Network | */ |
----------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, email: tomcat-dev-help@jakarta.apache.org
Re: [Bug 389] New - Security Issue? Important attributes exposed by
ServletContext can be modified BugRat Report#682
Posted by "Craig R. McClanahan" <cr...@apache.org>.
On Mon, 12 Mar 2001, Glenn Nielsen wrote:
> The latest version of Tomcat 4.0 from CVS supports the Java SecurityManager.
> Tomcat 4.0 Beta 1 did not.
>
> The Java SecurityManager can restrict access to those properties and do a
> great deal more to assist you in running a secure application server.
>
> I wouldn't consider what you reported as a bug now that the Java SecurityManager
> has been implemented.
>
I think the issue is still real (assuming that you don't have total
control over the code installed in your web app), because context
attributes are mutable. These attributes were originally introduced to
avoid code dependencies between Jasper and the servlet container it runs
in. Now that we have a JNDI context, I think that might be a more
appropriate mechanism, because the context itself is immutable.
> BTW, if you are attending ApacheCon 2001 Apr 4-6, I will be presenting a session on
> "Tomcat Server and Application Security" that goes into great detail on
> how the Java SecurityManager works and using it with Tomcat.
>
Gee, maybe I'd better come and learn :-). I will definitely be there,
because I'm presenting two other Tomcat related sessions and one on web
application architectures:
- TH13 "The Tomcat Servlet Container" (will cover 4.0 architecture)
- TH09 "Migrating Apache JServ Applications to Tomcat"
- W16 "Recommendations for Java-Based Web Application Architectures"
> Regards,
>
> Glenn
>
Craig
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, email: tomcat-dev-help@jakarta.apache.org
Re: [Bug 389] New - Security Issue? Important attributes exposed by
ServletContext can be modified BugRat Report#682
Posted by Glenn Nielsen <gl...@voyager.apg.more.net>.
The latest version of Tomcat 4.0 from CVS supports the Java SecurityManager.
Tomcat 4.0 Beta 1 did not.
The Java SecurityManager can restrict access to those properties and do a
great deal more to assist you in running a secure application server.
I wouldn't consider what you reported as a bug now that the Java SecurityManager
has been implemented.
BTW, if you are attending ApacheCon 2001 Apr 4-6, I will be presenting a session on
"Tomcat Server and Application Security" that goes into great detail on
how the Java SecurityManager works and using it with Tomcat.
Regards,
Glenn
bugzilla@apache.org wrote:
>
> http://nagoya.apache.org/bugzilla/show_bug.cgi?id=389
>
> *** shadow/389 Mon Mar 12 13:27:37 2001
> --- shadow/389.tmp.1035 Mon Mar 12 13:27:37 2001
> ***************
> *** 0 ****
> --- 1,22 ----
> + +============================================================================+
> + | Security Issue? Important attributes exposed by ServletContext can be modi |
> + +----------------------------------------------------------------------------+
> + | Bug #: 389 Product: Tomcat 4 |
> + | Status: UNCONFIRMED Version: 4.0 Beta 1 |
> + | Resolution: Platform: All |
> + | Severity: Normal OS/Version: All |
> + | Priority: High Component: Catalina |
> + +----------------------------------------------------------------------------+
> + | Assigned To: craig.mcclanahan@eng.sun.com |
> + | Reported By: rmandava@talentportal.com |
> + | CC list: Cc: |
> + +----------------------------------------------------------------------------+
> + | URL: |
> + +============================================================================+
> + | DESCRIPTION |
> + Hi:
> +
> + The attributes such as "org.apache.catalina.classloader", "org.apache.catalina.jsp_classpath" are exposed through ServletContext and can be easily modified. No security violation is generated and anybody with an application installed on the web server can modify these variables. Is n't it a security problem for Tomcat?
> +
> + Thanks
> + -Ramesh
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
> For additional commands, email: tomcat-dev-help@jakarta.apache.org
--
----------------------------------------------------------------------
Glenn Nielsen glenn@more.net | /* Spelin donut madder |
MOREnet System Programming | * if iz ina coment. |
Missouri Research and Education Network | */ |
----------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, email: tomcat-dev-help@jakarta.apache.org