Return-Path: Delivered-To: apmail-jakarta-tomcat-dev-archive@apache.org Received: (qmail 51388 invoked from network); 28 Feb 2002 22:45:55 -0000 Received: from unknown (HELO nagoya.betaversion.org) (192.18.49.131) by daedalus.apache.org with SMTP; 28 Feb 2002 22:45:55 -0000 Received: (qmail 20780 invoked by uid 97); 28 Feb 2002 22:45:54 -0000 Delivered-To: qmlist-jakarta-archive-tomcat-dev@jakarta.apache.org Received: (qmail 20764 invoked by uid 97); 28 Feb 2002 22:45:53 -0000 Mailing-List: contact tomcat-dev-help@jakarta.apache.org; run by ezmlm Precedence: bulk List-Unsubscribe: List-Subscribe: List-Help: List-Post: List-Id: "Tomcat Developers List" Reply-To: "Tomcat Developers List" Delivered-To: mailing list tomcat-dev@jakarta.apache.org Received: (qmail 20753 invoked by uid 50); 28 Feb 2002 22:45:53 -0000 Date: 28 Feb 2002 22:45:53 -0000 Message-ID: <20020228224553.20752.qmail@nagoya.betaversion.org> From: bugzilla@apache.org To: tomcat-dev@jakarta.apache.org Cc: Subject: DO NOT REPLY [Bug 6772] New: - [Security] RequestDipatcher allows to bypass security manager sandboxing X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=6772 [Security] RequestDipatcher allows to bypass security manager sandboxing Summary: [Security] RequestDipatcher allows to bypass security manager sandboxing Product: Tomcat 4 Version: 4.0.2 Final Platform: All OS/Version: All Status: NEW Severity: Blocker Priority: Other Component: Catalina AssignedTo: tomcat-dev@jakarta.apache.org ReportedBy: remm@apache.org Using a request dipatcher with a relative URL (incuding '/../') allows a servlet or JSP to access files on the server filesystem, bypassing the protection the security manager provides. >From the original report: The problem is this: with a more-or-less default installation of Tomcat using the security manager, in a jsp:include you can access outside of your context using ../../../ . Note that in other forms of reading the files, the security manager correctly prohibits access (both in a jsp:include giving the real path, and in standard programmatic file opening with real and ../ paths). It's just in the case of the include with relative path that it allows access to others' files. Here's a sample line of a jsp that should generate an error, but doesn't. The contexts are foo1/ and foo2/, they are defined in separate context tags. This line is from a file in foo1/. -- To unsubscribe, e-mail: For additional commands, e-mail: