--
From: Stian Myhre [EMAIL PROTECTED]
Reply-To: Stian Myhre [EMAIL PROTECTED]
Date: Mon, 2 Apr 2001 11:54:52 +0200
To: [EMAIL PROTECTED]
Subject: Re: CHINANSL Security Advisory(CSA-200108)
Hi all.
It is possible not only to get the listing
but also the files.
If you use replace
1:04 PM
To: tomcat-dev
Subject: FW: CHINANSL Security Advisory(CSA-200108)
--
From: Stian Myhre [EMAIL PROTECTED]
Reply-To: Stian Myhre [EMAIL PROTECTED]
Date: Mon, 2 Apr 2001 11:54:52 +0200
To: [EMAIL PROTECTED]
Subject: Re: CHINANSL Security Advisory(CSA-200108)
Hi all
Grensstraat 1b - B-3010 Leuven - Belgium
*E-security rule #1: ignorance is never a defense*
Original Message
From: [EMAIL PROTECTED] (Jon Stevens)
Subject: Re: CHINANSL Security Advisory(CSA-200108)
Newsgroups: lists.bugtraq
on 3/30/01 11:26 PM, "lovehacker" [EMAIL
As you've seen from bug reports to [EMAIL PROTECTED], the Beta 2
release of Tomcat 4.0 has a security vulnerability that can expose JSP
file source code. A partial fix to this problem was implemented prior to
shipping beta 2, but it did not deal with all possible causes.
The actual bug (URL
Jon Stevens wrote:
on 4/2/01 2:20 PM, "Craig R. McClanahan" [EMAIL PROTECTED] wrote:
I suggest that we create a revised version of beta 2, clearly labelled so
that people will know whether they have the corrected version or not --
and we should do this immediately (like today) to
- Original Message -
From: "Glenn Nielsen" [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Tuesday, April 03, 2001 12:39 AM
Subject: Re: Tomcat 4.0-beta-2 Security Vulnerability
Jon Stevens wrote:
on 4/2/01 2:20 PM, "Craig R. McClanahan" [EMAIL PROTECTED] w
e can produce. :-) I believe that a new
beta number is justified by any significant bug fix or
fixes and a security hole is definitely significant,
even if the code change may be tiny.
By labeling it 'beta-3' it is CLEARLY the latest build
and CLEARLY newer than beta-2.
fwiw
r being told there were limits to the number
of betas one can produce. :-) I believe that a new
beta number is justified by any significant bug fix or
fixes and a security hole is definitely significant,
even if the code change may be tiny.
By labeling it 'beta-3' it is CLEARLY the latest
And I think it is also good to state in the mail-announcement and in the
jakarta website that the b2 have such security vulnerability when b3 is
rolled out.
Punky
- Original Message -
From: "Craig R. McClanahan" [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Tuesday, April
On Tue, 3 Apr 2001, Punky Tse wrote:
And I think it is also good to state in the mail-announcement and in the
jakarta website that the b2 have such security vulnerability when b3 is
rolled out.
It will. The beta-2 release is also going to get pulled so that no one
will download
fyi.
-jon
--
From: lovehacker [EMAIL PROTECTED]
Reply-To: [EMAIL PROTECTED]
Date: Mon, 2 Apr 2001 03:56:51 -
To: [EMAIL PROTECTED]
Subject: Re: CHINANSL Security Advisory(CSA-200109)
HI Sverre:
Thanks your reply.
your website is very nice.
Today,I download Tomcat 4.0-b2
--
From: lovehacker [EMAIL PROTECTED]
Reply-To: [EMAIL PROTECTED]
Date: Mon, 2 Apr 2001 03:49:00 -
To: [EMAIL PROTECTED]
Subject: CHINANSL Security Advisory(CSA-200110)
Topic:Tomcat 4.0-b2 for winnt/2000 show ".jsp"
source Vulnerability.
vulnerable:
winnt/2000(maybe
Hello,
The current servlet specification describes an implementation of FORM based
authentication that simulates HTTP digest authentication. I'm designing an
application using Tomcat, and I'd really like to use the container managed
security, but I'd also like a more traditional user
I'd like to propose that we create and publish a Tomcat 4.0 beta 2 release
tonight, based on the current CVS code base. The primary reason for the
expedited schedule is that this code will include a fix for the "Tomcat
may reveal script source code by URL trickery" security vul
I'd like to propose that we create and publish a Tomcat 4.0 beta 2 release
tonight, based on the current CVS code base. The primary reason for the
expedited schedule is that this code will include a fix for the "Tomcat
may reveal script source code by URL trickery" security vul
- Original Message -
From: "Craig R. McClanahan" [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Friday, March 30, 2001 11:36 AM
Subject: [VOTE] Tomcat 4.0 Beta 2 Release Tonight (Fixed Security
Vulnerability)
I'd like to propose that we create and publish a Tomcat 4.0 beta
rce code by URL trickery" security vulnerability, as
well as lots of other bug fixes.
Comments? Votes?
Craig McClanahan
+1
--
Glenn Nielsen [EMAIL PROTECTED] | /* Spelin donut madder|
MOREne
code by URL trickery" security vulnerability, as
well as lots of other bug fixes.
Comments? Votes?
Craig McClanahan
Dear "lovehacker",
Tomcat 3.0 is an old version and has several known security holes. That is
why we recommend that people run the latest released version which is
currently 3.1.1 or 3.2.1 (depending on the branch you are interested).
Also, Tomcat 3.2.2b2 is also available on our web
I'm just recently getting more intimate with Tomcat's architecture and I'm
wondering what provisions and plans are in place for security in the
protocols btw http servers and the servlet engine. What are the
vulnerabilities now and how are people using Tomcat in production
protecting themselves
I'm just recently getting more intimate with Tomcat's
architecture and I'm
wondering what provisions and plans are in place for security in the
protocols btw http servers and the servlet engine. What are the
vulnerabilities now and how are people using Tomcat in production
protecting themselves
craigmcc01/03/26 12:50:48
Modified:webapps/examples/jsp/security/protected index.jsp
Log:
Explicitly identify the destination of the form submit, so that this page
works correctly when used in a form-based login environment.
Revision ChangesPath
1.2 +1 -1
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
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,
Gle
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
a
Hi -
Other than NTBUGTRAQ or BUGTRAQ, is there a Tomcat specific email list
for security related issues?
Thanks,
-Bart
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
d 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
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 go
, 2001 5:59 PM
To: [EMAIL PROTECTED]; [EMAIL PROTECTED]
Subject: [Security Issue] Sessions are visible across multiple clients
Hi all,
one session can be visible on multiple clients!!
THIS IS A BIG SECURITY PROBLEM!
Someone opens his webbrowser and has the session of somebody else.
So critical
Henri" [EMAIL PROTECTED]
To: [EMAIL PROTECTED]; [EMAIL PROTECTED]
Sent: Wednesday, February 28, 2001 8:59 AM
Subject: RE: [Security Issue] Sessions are visible across multiple clients
Probably partially resolved by the patch I forward previously.
From M. Frey
La prise de conscienc
Hi all,
one session can be visible on multiple clients!!
THIS IS A BIG SECURITY PROBLEM!
Someone opens his webbrowser and has the session of somebody else.
So critical data could be viewed without permission.
Somebody can act as somebody else.
What's wrong with tomcat's session-handling?
I
Hello,
when using Tomcat with IIS, we have
a"security hole".
We installed Tomcat as described at the documentation.
The following scenariomay show our problem:
We have a folder reachable as http://ourserver/secretfolder/ with NT Security permissions set for user "foo
The new behavior is as following:
When defining a security constraint for "/foo/*",
matchesresource "/foo" and"/foo/whatever" but not"/foo.jsp"
Cheers,
Dimitris Dinodimos
Index: AccessInterceptor.java
The new behavior is as following:
When defining a security constraint for "/foo/*",
matches resource "/foo" and "/foo/whatever" but not
"/foo.jsp"
Cheers,
Dimitris Dinodimos
__
Get personalized ema
Oops. This is the correct patch file.
--- Dimitris Dinodimos [EMAIL PROTECTED] wrote:
The new behavior is as following:
When defining a security constraint for "/foo/*",
matches resource "/foo" and "/foo/whatever" but not
"/foo.j
ntrol over the
resources that a particular web application can access. In addition, the
security manager can be used to constrain an application from accessing Tomcat
internals (for example, by trying to cast the HttpServletRequest it receives
back to the Tomcat internal implementa
Craig R. McClanahan typed the following on 10:09 PM 1/19/2001 -0800
How about if we create a branch of 4.0, and I check in these changes on that
branch? If things work out well, we can merge back to the main branch --
otherwise, wel'll have learned what needs to be done to add this functionality
HI to all,
i have found some problem in configuring security on site (Sparc Solaris
5.7) with Tomcat 3.2 (in virtual host).
Everything goes Ok, but when I tried to configure Basic Realm on a
particular Servlet class or sub dir of WEB-INF i didn't found any solution.
Is it possible to keep
. In addition, the
security manager can be used to constrain an application from accessing Tomcat
internals (for example, by trying to cast the HttpServletRequest it receives
back to the Tomcat internal implementation class).
This feature has long been on the wish list for 4.0, and recently Glenn
Quoting "Craig R. McClanahan" [EMAIL PROTECTED]:
org.apache.catalina.facade.XFacade
Nice package name. I wonder where you got it :)
* Pass the internal object to the constructor (the facade
will be a wrapper around it).
* Implement the appropriate servlet API interface (so the
facade
the corresponding method on the underlying
internal Catalina object.
Sounds cool. If the application doesn't use the security manager,
will the object simply continue "raw" without being wrapped by
the facade to avoid the added overhead? e.g:
// Raw session
Session mySession
On Fri, 19 Jan 2001, Remy Maucherat wrote:
Since it's the API changes day, may I then suggest that we just merge back all
the changes done so far in 4.1, which deal with replacing the resources package
with JNDI context. It works, and it's solid. I don't feel like we should leave
a whole
Kurt Schrader wrote:
On Fri, 19 Jan 2001, Remy Maucherat wrote:
Since it's the API changes day, may I then suggest that we just merge back all
the changes done so far in 4.1, which deal with replacing the resources package
with JNDI context. It works, and it's solid. I don't feel like we
to accept
the fact that it will increase the time before a 4.0 production quality
release is
ready.
Given the delay caused by the security manager support inclusion and the Valve
modifications, it won't probably cause any additional delay.
The 4.1 branch was originally created because of a "
Remy Maucherat wrote:
Quoting "Craig R. McClanahan" [EMAIL PROTECTED]:
org.apache.catalina.facade.XFacade
Nice package name. I wonder where you got it :)
:)
Unless I understand wrong, isn't a "facade" already a well known feature
that allows Tomcat 3.x to use more than one
Tomcat 4 Java SecurityManager Proposal (rev 2)
Use of the Java SecurityManager will be optional. The default
will be to start Tomcat with security to keep the folks at
bugtraq happy. Use without security at your own risk.
Currently the policy file is named catalina.policy
le1"
password="tomcat" roles="role1" />
user name="both"
password="tomcat" roles="tomcat,role1" />
user name="OID.0.9.2342.19200300.100.1.1=mvittel,
CN=michel vittel, O=frec.bull.fr" password="tomcat" roles="to
to the servlets to different groups of users. How do I set this up?
Can someone please send me a sample of "security-constraint" section (is
this where it gets done?) of a web.xml file?
Jim Urban
Project Manager
Netsteps Inc.
Suite 505E
1 Pierce Pl.
Itasca, IL 60143
Voice: (630) 250-3045
Sorry for the repost guys but I think this is serious enough for at
least one reply!
In short, Tomcat is sending me a jsp file... that is to say, it's
sending me the "unprocessed" version of the JSP file, with code and
everything. The JSP file seems to get stuck in the OutputStream buffer
of
glenn 00/12/28 13:59:19
Added: src/doc/uguide Tag: tomcat_32 tomcat-security-unix.html
Log:
SecurityManager under unix
Revision ChangesPath
No revision
No revision
1.1.2.1 +197 -0jakarta-tomcat/src/doc/uguide
PROTECTED]]
Enviado el: miércoles 20 de diciembre de 2000 8:07
Para: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]
Asunto: [PATCH] SECURITY FIX (Re: Tomcat 3.2.1 JSP Source Disclosure)
This patch fixes Tomcat 3.2.1 security problem that Yoshiyuki Karezaki
(cf. BugRat Report #513
This patch fixes Tomcat 3.2.1 security problem that Yoshiyuki Karezaki
(cf. BugRat Report #513) and Robert Ellis (cf. "Tomcat 3.2.1 JSP
Source Disclosure") reported.
At the same time, this patch fixes the bug Mark Brouwer reported
(cf. "[BUG] getProtocol() method on ServletReques
: [SECURITY] Security Vulnerabilities in Tomcat 3.1 and 3.2
on 12/11/2000 5:59 PM, "Craig R. McClanahan" [EMAIL PROTECTED]
wrote:
I'm certainly game to remove 3.1 once we know that 3.1.1 doesn't introduce
any
nasty
problems, but just removing 3.1 doesn't help all the thousands of people
who
* This release fixes ***only*** the identified security
vulnerabilities.
It does not address any of the other bugs, or feature
requests, related
to Tomcat 3.2 final. These issues will be dealt with in future
maintenance releases of Tomcat 3.2 as appropriate.
Not totally true since
There's a bug in tomcat.sh when you specify -security after the start
and run targets. Basically you have to do another shift to get rid of
-security before passing the rest of the args to Tomcat.
Here's the diff:
124a125
shift
141a143
shift
Edwin Park
Dear All,
I'm not sure where to post this but I'd like someone to take a look at
the following code and consider it for inclusion as
a fix to a problem with security-roles in tomcat 3.2.
The problem:
According to the 2.2 spec. A servlet defintion may define aliases for
security-roles (called
GOMEZ Henri wrote:
* This release fixes ***only*** the identified security
vulnerabilities.
It does not address any of the other bugs, or feature
requests, related
to Tomcat 3.2 final. These issues will be dealt with in future
maintenance releases of Tomcat 3.2 as appropriate
Gomez Henri wrote:
I've asked some days ago about the 'Attic ?'...
Sorry, I thought that got answered.
The "attic" is CVS's way of dealing with files that are on one branch of a
repository, but not another -- or cases where you deleted a file, but you might
want to go back to a previously
d in Tomcat 3.2.1.
* You can download this security maintenance release at:
http://jakarta.apache.org/builds/tomcat/release/v3.2.1/bin/
* You are ***strongly*** encouraged to download and install this
update as quickly as possible.
* This release fixes ***only*** the identif
Proposal #1: Release a Tomcat 3.1.1 that fixes *only* the security
problems
+1
I'll still be for security updates but release a 3.1.1 could make
some users thinking the 3.1 tree is still alive. Could be disturbing
some days after 3.2 release.
Proposal #2: Release a Tomcat 3.2.1
"Craig R. McClanahan" wrote:
Over the last three days, a review of published and soon-to-be-published reports
of security vulnerabilities in Tomcat has uncovered a series of problems in the
3.1 final release, and a couple of less serious (but still significant) problems
in 3.2. P
: Re: [SECURITY] Security Vulnerabilities in Tomcat 3.1 and 3.2
From: Jon Stevens [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
X-Spam-Rating: locus.apache.org 1.6.2 0/1000/N
on 12/11/2000 5:59 PM, "Craig R. McClanahan" [EMAIL PROTECTED]
wrote:
I'm certainly game to remove 3.1 on
I have to agree with Arieh on this one. Coming from an organization that
has a very rigerous change management process I know that it can take
upwards of 4 months to release a piece of software, let alone a server
upgrade that is not just a security fix. If it adds features above and
beyond
[EMAIL PROTECTED] 12/11/00 06:19PM
Over the last three days, a review of published and
soon-to-be-published reportsof security vulnerabilities in Tomcat has
uncovered a series of problems in the3.1 final release, and a couple of
less serious (but still significant) problemsin 3.2. Please
Tomcat 3.2 final has the following security vulnerabilities that have
subsequently been fixed in the CVS repository:
* A URL like "http://localhost:8080/examples//WEB-INF/web.xml" can
expose sensitive information (note the double slash after "examples").
Has there been a definitive list of these security problems with
TC 3.1 or TC 3.2?
What are the "appropriate contents" of the $TOMCAT_HOME directory
that I need to replace for both TC 3.1 and TC 3.2?
Aron Kramlik.
-Original Message-
From: Craig R. McClanahan [mailto:[EMAIL
Aron Kramlik wrote:
Has there been a definitive list of these security problems with
TC 3.1 or TC 3.2?
The definitive lists of what vulnerabilities were fixed are in the release notes
document for each version (file "doc/readme" in the download).
Subscribers to TOMCAT-DEV also s
Recent investigations and reports have revealed security vulnerabilities in both
Tomcat 3.1 and Tomcat 3.2 final releases. To deal with these problems, the
Tomcat team has developed maintenance releases, and recommended actions, for
each major version. (Tomcat 4.0 milestone 4 shares one
Over the last three days, a review of published and soon-to-be-published reports
of security vulnerabilities in Tomcat has uncovered a series of problems in the
3.1 final release, and a couple of less serious (but still significant) problems
in 3.2. Please vote (quickly) on the following two
Proposal #1: Release a Tomcat 3.1.1 that fixes *only* the security
problems
+1.
Proposal #2: Release a Tomcat 3.2.1 that fixes the following security
problems
plus the patches committed to date.
+1.
Remy
"Craig R. McClanahan" wrote:
[...]
Proposal #1: Release a Tomcat 3.1.1 that fixes *only* the security problems
+0. Is removing TC 3.1 from the download pages an alternative? There shouldn't
be any reason for anyone to use TC 3.1 now when 3.2 is released. Upgrading to
3
Hans Bergsten wrote:
"Craig R. McClanahan" wrote:
[...]
Proposal #1: Release a Tomcat 3.1.1 that fixes *only* the security problems
+0. Is removing TC 3.1 from the download pages an alternative? There shouldn't
be any reason for anyone to use TC 3.1 now when 3.2 is released.
on 12/11/2000 5:19 PM, "Craig R. McClanahan" [EMAIL PROTECTED]
wrote:
Over the last three days, a review of published and soon-to-be-published
reports
of security vulnerabilities in Tomcat has uncovered a series of problems in
the
3.1 final release, and a couple of less serious
on 12/11/2000 5:59 PM, "Craig R. McClanahan" [EMAIL PROTECTED]
wrote:
I'm certainly game to remove 3.1 once we know that 3.1.1 doesn't introduce any
nasty
problems, but just removing 3.1 doesn't help all the thousands of people who
have
apps running on 3.1 and who cannot, for various
Proposal #1: Release a Tomcat 3.1.1 that fixes *only* the security
problems
+1
Proposal #2: Release a Tomcat 3.2.1 that fixes the following security
problems
plus the patches committed to date.
+ 1
Larry
On Mon, 11 Dec 2000, Craig R. McClanahan wrote:
Tomcat 3.2 final has the following security vulnerabilities that have
subsequently been fixed in the CVS repository:
* A URL like "http://localhost:8080/examples//WEB-INF/web.xml" can
expose sensitive information (note the do
, such
as
Windows. This represents a change from Tomcat 3.1, where URL's were case
insensitive on case insensitive OS's. This was done for a number of
reasons,
security and portability among them.
Petr
-Original Message-
From: Greg Wilkins [mailto:[EMAIL PROTECTED]]
Sent: Thursday, November
All,
I'm working on documenting ajp13, and I'm noticing that there doesn't seem to be any
authentication step between the web server and the servlet container (in contrast to
ajp11 and ajp12, both of which I believe had some sort of shared secret-based
authenication step when opening up a TCP
don't know if JspServlet has been updated in 3.2 (???) but
most servlets are not under the control of tomcat.
Furthermore, it has been pointed out that case may not
be involved, as NT does 8.3 rewriting.
A security constraint at
/loongdirectoryname/*
will be bypassed with a request like
/loongd
Hola A todos:
Lately I'm trying to figure out a way to bypass the basic/digest
security handling done by ISS, and so let it be done by tomcat, as it's
a pain under IIS as it requires to have the users created at OS level, (
at least i unable to found a way to do that ), but apart from MS
blues
, 19 Nov 2000, Nacho wrote:
Hola A todos:
Lately I'm trying to figure out a way to bypass the basic/digest
security handling done by ISS, and so let it be done by tomcat, as it's
a pain under IIS as it requires to have the users created at OS level, (
at least i unable to found a way to do
() methods of all configured request
interceptors. This means (among other things) that security
constraints, if you are using container managed security, will be called
on the original request *and* on the forwarded-to or included servlet.
This behavior wasn't really specfied in s
Hello everybody,
It seems to me that there's no Policy Base Security support via a
SecurityManager implementation in Tomcat. Am I wrong?
I have some code that calls getProtectionDomain() from the Class class.
When it is used from Tomcat 3.1, the method returns NULL and when it's used
from
501 - 583 of 583 matches
Mail list logo
