CVE-2013-2071 Request mix-up if AsyncListener method throws RuntimeException

2013-05-10 Thread Mark Thomas
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

CVE-2013-2071 Request mix-up if AsyncListener method throws
  RuntimeException

Severity: Moderate

Vendor: The Apache Software Foundation

Versions Affected:
- - Tomcat 7.0.0 to 7.0.39

Description:
Bug 54178 described a scenario where elements of a previous request may
be exposed to a current request. This was very difficult to exploit
deliberately but fairly likely to happen unexpectedly if an application
used AsyncListeners that threw RuntimeExceptions. The issue was fixed by
catching the RuntimeExceptions.

Mitigation:
Users of affected versions should apply the following mitigation:
- - Tomcat 7.0.x users should upgrade to 7.0.40 or later

Credit:
The security implications of this issue were identified by the Apache
Tomcat Security Team.

References:
http://tomcat.apache.org/security.html
http://tomcat.apache.org/security-7.html
https://issues.apache.org/bugzilla/show_bug.cgi?id=54178
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBAgAGBQJRjLHMAAoJEBDAHFovYFnnOIAP/A9HXwQgnJKYl+gXwqFkjXaq
blo70uMMUpKPJ61l/keEguxZ/iGdQC4H2osjQiG7lhoOPvrMKtewCMXDAk/j9Skd
HXuQVSge22Na16M6GUNXARziyDk/44k8RHy3cibrPZPhUNVD743N50toPK8Q6UKR
PmAANa/kB9vvD589PCQLx/i6oiS5jaAwjoSdbwshtJytXrxoHgUrRLl3P5/sPBiq
57H/pAELR4aorfSj+tJL63ySX9v4NRiB55u3hNDgZOnPz3D9sjMsmq5vSzhfyiHh
NnkYGa7+ZfnBL6DJ4eiV5z7lbMFIBa7ZzcyYEhVFCIsbnSwTL2l0a3NSkuQ0xiXS
0jQDenOuCujL1Zw5YYHhRDy2rGbFG8q/Z+ZSQ3NP0vnmQCpCfsY3mBIFCWzhmK+h
TnFKdtxA+Ev/HSGPlSK1hADiYwL/iLb6YMoyintgj2mDIxrdHhcfMq8h6GYD1rbF
vlbWSpmgN81xdU8JxEbnq6PC60OeZH5x08Sj9B3YQlB8E4Pq9B/EaEFYF9oZdYcP
+DQWcd78SBNevg+fgKdKK8CjU5JQhMWetxv6HUomS7j3LgoJQPwVrNcg0yjV1v/g
qgddQ1DOamD+KuQxh08NHfMZP08g5a+CrQ6qpe3/pr/OI0PlTN23aCXvCEGl2KlZ
Cn4w/1eoL4agb5oREL2U
=vQbB
-END PGP SIGNATURE-

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org



[ANN] Apache Tomcat 7.0.40 released

2013-05-10 Thread Mark Thomas
The Apache Tomcat team announces the immediate availability of Apache
Tomcat 7.0.40.

Apache Tomcat is an open source software implementation of the Java
Servlet, JavaServer Pages and Java Expression Language technologies.

This release contains a security fix and a number of bug fixes
and improvements compared to version 7.0.39. The notable changes include:
- A fix for CVE-2013-2071 (bug bug54178/bug) an informatio
  disclosure issue.
- Various fixes to stop Tomcat attempting to parse text that looks like
  an EL expression in a JSP document as an EL expression when EL
  expressions are either not permitted or not enabled.
- Improved handling and reporting if a ConcurrentModificationException
  occurs while checking for memory leaks when a web application is
   being stopped.

Please refer to the change log for the complete list of changes:
http://tomcat.apache.org/tomcat-7.0-doc/changelog.html

Note: This version has 4 zip binaries: a generic one and three
  bundled with Tomcat native binaries for Windows operating systems
  running on different CPU architectures.

Note: If you use the APR/native AJP or HTTP connector you *must* upgrade
  to version 1.1.24 or later of the AJP/native library and it is
  recommended that you upgrade to 1.1.27

Downloads:
http://tomcat.apache.org/download-70.cgi

Migration guides from Apache Tomcat 5.5.x and 6.0.x:
http://tomcat.apache.org/migration.html

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org



[SECURITY] CVE-2013-2067 Session fixation with FORM authenticator

2013-05-10 Thread Mark Thomas
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

CVE-2013-2067 Session fixation with FORM authenticator

Severity: Important

Vendor: The Apache Software Foundation

Versions Affected:
- - Tomcat 7.0.0 to 7.0.32
- - Tomcat 6.0.21 to 6.0.36

Description:
FORM authentication associates the most recent request requiring
authentication with the current session. By repeatedly sending a request
for an authenticated resource while the victim is completing the login
form, an attacker could inject a request that would be executed using
the victim's credentials. This attack has been prevented by changing the
session ID prior to displaying the login page as well as after the user
has successfully authenticated.


Mitigation:
Users of affected versions should apply one of the following mitigations:
- - Tomcat 7.0.x users should upgrade to 7.0.33 or later
- - Tomcat 6.0.x users should upgrade to 6.0.37 or later

Credit:
This issue was identified by the Apache Tomcat Security Team.

References:
http://tomcat.apache.org/security.html
http://tomcat.apache.org/security-7.html
http://tomcat.apache.org/security-6.html
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBAgAGBQJRjLHUAAoJEBDAHFovYFnnUnEP/0R3q0uPTHRXem+Jlx6DLLfs
jL3TD1idxqHcUDJhX/mnePwTxIle5lAbPZn6hBknFPdD77kjyflq4TB3ZPUipsip
s2bKzGGlDDZwzRIY46ZqBRcVXuemCu73BjFNLBP6CvjQwm1/wFGuOS+oRRKKigwQ
Ew1Mau3c6Sb0VIED4yrgvhPwJwdi1+rA1TO87p/8rxQIS9CTcUy6J/MICPdvIQiI
zIfr7pIRSNDk9JeC6Ybr/SC5lYqAox6eqOYYNoQ+5zQ1BcCw/eQgWpm4WYM2IDV3
2eNbjS/dylz5zBQEDbzz9VtReBTncQLF6Do2KDhWxkaUaX2oaOTPKlLiyL0gwA4e
IDpHDl9D5mLmBaJi4Lz14cwey5wNgs28ZqX9JCUaLz7qc03J9Au7PrplOr3Xth/Z
rQqeKVxFZKaIKQOm2NKs7v7bZAhzp/mKt/u9ndnk0uKk2Tf3i6QJ1GtICTY22eB6
Eh4s/o2BJDgGop0P7cTmrAv1uKu6/72eoUJBMyyGCIN67URzVZRwMQnmW6TqZoBt
tASvlTVD53HV3aPdhDHDjP9x/6V6cODD29fzn5op59BWhMVuzf+1lhqphJT0hlQQ
lnuf4H9UWG8I8/OzN7XNabIbVuYyhjYWnt8HI/8N/4cAHfA67fXkcbDqleKOd6qo
Pcp0qDLiZqVFSotSkVFl
=hWpv
-END PGP SIGNATURE-

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org



[SECURITY] CVE-2012-3544 Chunked transfer encoding extension size is not limited

2013-05-10 Thread Mark Thomas
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

CVE-2012-3544 Chunked transfer encoding extension size is not limited

Severity: Important

Vendor: The Apache Software Foundation

Versions Affected:
- - Tomcat 7.0.0 to 7.0.29
- - Tomcat 6.0.0 to 6.0.36

Description:
When processing a request submitted using the chunked transfer encoding,
Tomcat ignored but did not limit any extensions that were included. This
allows a client to perform a limited DOS by streaming an unlimited
amount of data to the server.

Mitigation:
Users of affected versions should apply one of the following mitigations:
- - Tomcat 7.0.x users should upgrade to 7.0.30 or later
- - Tomcat 6.0.x users should upgrade to 6.0.37 or later

Credit:
This issue was identified by Steve Jones.

References:
http://tomcat.apache.org/security.html
http://tomcat.apache.org/security-7.html
http://tomcat.apache.org/security-6.html
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBAgAGBQJRjLHYAAoJEBDAHFovYFnnNacQAKZ8VVSZkh1Tz1hkenVQH9ic
rZGNE3dzfdum8sbL18iObOyt7b7iJMDwSv96sD6Ig+6EgiqRJGcj65a9DOIoyNlD
dmYT8qj4wK2OUsefUpfX0RQHgAZcZMRHX6UcgBETgVDTVcWoZ3lDWEBCYap9CTLf
2MX34mMawDp+WEXloDIvxtSC5q5u2nW/O4UJHH+jaPnnmYmghHqb2yh9Tkjj3fkG
HUtJlK0WuL9TM7IlQySPUHw98BN46illVu8go6xVslE3CLzXIOOOelOnyDH9IFoF
D4SbhKb0nSwSi9aUJsjLNAmgx9Cj5shYyWQSP+CCNXfpOaBz11R3lxSmRvbRBDTf
lW8SPgKiCIjXSbbKtZzhl9cu21i4yZFwaKm22wKSRoEWghHs5mCNcVwt+qNE34Zx
v2eliMYymkc/EDy/aCTz4DwWhGP9XLi8hOtPkSFB46jLLbUOJcAcy3jPnPa9X8Gq
FX07EAncpG8uC9wpSd1Vtr8SPJlbRbkwY2NJ9MaRuEtetbC/Gpq8I5fT7MuBM7X9
8r+GoEcjTMYGWb7T+vGzg5HpcnOVY07wvG1Kvdp/cLxxAjGONsAwvZQ1D6VAjkJx
bgDOGWqTDm1c7U3MIY+CdrGKpKaRCoCI6UX5vlD/+H3NYjMKadUwpDrFNCwSMF4T
7QzwCUk2DGUI/n7o7S5n
=vhss
-END PGP SIGNATURE-

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org



Re: Print parameters in Tomcat JDBC Pool's SlowQueryReport

2013-05-10 Thread Michael-O

Am 2013-05-08 19:42, schrieb Christopher Schultz:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Michael,

On 5/8/13 1:14 PM, Michael-O wrote:

Christopher,

Am 2013-05-08 13:54, schrieb Christopher Schultz:

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256

Michael,

On 5/8/13 3:01 AM, Michael-O wrote:

I recently have started using the SlowQueryReport to tackle
performance issues. The log message, unfortunately, does not
contain the parameters passed to the prepared statements.
Though AbstractQueryReport receives this information in

protected String report*Query(String query, Object[] args,
final String name, long start, long delta)

but ignores this information. The report would highly benefit
from. E.g., Commons DBUtils prints out the query and the
parameters in the case of an exception. The sole query isn't
really helpful.

Can we add this?


Sure.


Should I file a ticket?


Yes. A BZ issue with a patch is likely to get done a whole lot
faster than one without a patch (plus you get credit for your
contribution).


What file should I patch, AbstractQueryReport or QueryReport? I'd
exclude JMX for now.


Your choice: whatever seems to make more sense. If a committer reads
and patch and thinks it goes somewhere else, you can re-write it. Or,
you can open the BZ issue, then post to the dev list asking for
suggestions for where to start.


Thanks,

give me a couple of days. I won't have access to an appropriate env 
before Monday.


Michael


-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org



DRIVER ERROR

2013-05-10 Thread Jeny V
Hi ,

I'm having some real issues , running programs in Tomcat on my machine. I just 
copied a jakarta folder named jakarta-tomcat-3.3.1a on to my D: drive (Path : 
D:\Program Files\jakarta-tomcat-3.3.1a) . The folder includes the following 
SUBFOLDERS : bin,conf,doc,lib,logs,modules,native,webapps,work . I can run 
simple jsp programs with no database connection. But whenever I try to execute 
programs with database connections, following error encounters:

Error: 500

Internal Servlet Error:

javax.servlet.ServletException: [Microsoft][ODBC Driver Manager] The specified 
DSN contains an architecture mismatch between the Driver and Application at 
org.apache.jasper.runtime.PageContextImpl.handlePageException(PageContextImpl.java:460)
 at students.ques9.patients_1._jspService(patients_1.java:97) at 
org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:119) at 
javax.servlet.http.HttpServlet.service(HttpServlet.java) at 
org.apache.tomcat.facade.ServletHandler.doService(ServletHandler.java:574) at 
org.apache.tomcat.core.Handler.invoke(Handler.java:322) at 
org.apache.tomcat.core.Handler.service(Handler.java:235) at 
org.apache.tomcat.facade.ServletHandler.service(ServletHandler.java:485) at 
org.apache.tomcat.core.ContextManager.internalService(ContextManager.java:917) 
at org.apache.tomcat.core.ContextManager.service(ContextManager.java:833) at 
org.apache.tomcat.modules.server.Http10Interceptor.processConnection(Http10Interceptor.java:176)
 at
 org.apache.tomcat.util.net.TcpWorkerThread.runIt(PoolTcpEndpoint.java:494) at 
org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:516)
 at java.lang.Thread.run(Thread.java:722) Root cause: java.sql.SQLException: 
[Microsoft][ODBC Driver Manager] The specified DSN contains an architecture 
mismatch between the Driver and Application at 
sun.jdbc.odbc.JdbcOdbc.createSQLException(JdbcOdbc.java:6956) at 
sun.jdbc.odbc.JdbcOdbc.standardError(JdbcOdbc.java:7113) at 
sun.jdbc.odbc.JdbcOdbc.SQLDriverConnect(JdbcOdbc.java:3072) at 
sun.jdbc.odbc.JdbcOdbcConnection.initialize(JdbcOdbcConnection.java:323) at 
sun.jdbc.odbc.JdbcOdbcDriver.connect(JdbcOdbcDriver.java:174) at 
java.sql.DriverManager.getConnection(DriverManager.java:579) at 
java.sql.DriverManager.getConnection(DriverManager.java:243) at 
students.ques9.patients_1._jspService(patients_1.java:64) at 
org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:119) at
 javax.servlet.http.HttpServlet.service(HttpServlet.java) at 
org.apache.tomcat.facade.ServletHandler.doService(ServletHandler.java:574) at 
org.apache.tomcat.core.Handler.invoke(Handler.java:322) at 
org.apache.tomcat.core.Handler.service(Handler.java:235) at 
org.apache.tomcat.facade.ServletHandler.service(ServletHandler.java:485) at 
org.apache.tomcat.core.ContextManager.internalService(ContextManager.java:917) 
at org.apache.tomcat.core.ContextManager.service(ContextManager.java:833) at 
org.apache.tomcat.modules.server.Http10Interceptor.processConnection(Http10Interceptor.java:176)
 at org.apache.tomcat.util.net.TcpWorkerThread.runIt(PoolTcpEndpoint.java:494) 
at 
org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:516)
 at java.lang.Thread.run(Thread.java:722)
Please do reply or help me with this problem as I tried so many times to fix 
the problem by trying various solutions.

My Laptop details :


Windows Edition : Windows 7
System Type : 64-bit Operating System

JDK version : jdk1.7.0_07
Jakarta Version : 3.3.1a

Looking forward for your early response.


Thanks in advance
Jeny

RE: DRIVER ERROR

2013-05-10 Thread Caldarale, Charles R
From: Jeny V [mailto:v_je...@yahoo.in] 
Subject: DRIVER ERROR

I just copied a jakarta folder named jakarta-tomcat-3.3.1a

Stop right there.  That version of Tomcat is over ten years old and has not 
been supported for more than half that time.  It is absolutely unconscionable 
to attempt to use it for any purpose whatsoever.  Get a current version of 
Tomcat and use that.

 - Chuck


THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY 
MATERIAL and is thus for use only by the intended recipient. If you received 
this in error, please contact the sender and delete the e-mail and its 
attachments from all computers.


-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org



[OT] Querstion about Class.forName() re. ClassLoaders

2013-05-10 Thread Konstantin Preißer
Hi all,

I apologize for being completely off-topic (this question has nothing to do 
with Tomcat), but I thought there may be some guys here that are experts in 
class loading and are able to answer my question.


You probably know the method java.lang.Class.forName(String name) which returns 
a class object from the given name. The JavaDoc (Java 7) of this method says:

  Returns the Class object associated with the class or interface with the 
given string name. Invoking this method is equivalent to:
  Class.forName(className, true, currentLoader) 
  where currentLoader denotes the defining class loader of the current 
class.

While this description may be a bit ambiguous about what current class means 
here, the JavaDoc of Class.forName(String name, boolean initialize, ClassLoader 
loader) makes it clearer by stating:

  For example, in an instance method the expression:
  Class.forName(Foo) 
  is equivalent to:
  Class.forName(Foo, true, this.getClass().getClassLoader())


So, shouldn't this mean that I get the same result/behavior when writing this 
code:

public void doSomething() throws ClassNotFoundException {
Class? clazz = Class.forName(foo.Bar);
// do something...
}

Instead of this one:

public void doSomething() throws ClassNotFoundException {
Class? clazz = Class.forName(foo.Bar, true, 
this.getClass().getClassLoader());
// do something...
}

or did I misunderstand something?

Thanks!


Regards,
Konstantin Preißer


-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org



maxIdleTime + Tomcat 6.0.23

2013-05-10 Thread Jose María Zaragoza
Hello:


I'm using Tomcat 6.0.23 and I'm looking info about threads created by
Tomcat HTTP Connector for processing requests.

I've seen that

- I cannot define a minSpareThread in Connector , in server.xml . And
default value is 0
I have to create a Executor to be able to define a minSpareThread

am I right ? why ?

- There isn't a property like maxIdleTime in Connector , so idle threads
remain forever
Why isn's there a default value ?

Again , I have to create a Executor to be able to define a maxIdleTime

am I right ? why ?


Thanks and regars


Re: maxIdleTime + Tomcat 6.0.23

2013-05-10 Thread Mark Thomas
On 10/05/2013 20:13, Jose María Zaragoza wrote:
 Hello:
 
 
 I'm using Tomcat 6.0.23 and I'm looking info about threads created by
 Tomcat HTTP Connector for processing requests.
 
 I've seen that
 
 - I cannot define a minSpareThread in Connector , in server.xml . And
 default value is 0
 I have to create a Executor to be able to define a minSpareThread
 
 am I right ?

Yes.

 why ?

Generally, leaving threads idle isn't very expensive. Creating and
destroying threads is expensive. Also, not using an executor allows for
simpler, faster code.

Because the general case by its very nature won't be perfect for
everybody, there are advanced options but that requires an Executor to
implement the more complex thread management that most users don't need.

 - There isn't a property like maxIdleTime in Connector , so idle threads
 remain forever
 Why isn's there a default value ?

There is no property so there can't be a default value.

 Again , I have to create a Executor to be able to define a maxIdleTime
 
 am I right ?

Yes.

 why ?

See above.

Mark


-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org



Re: [OT] Querstion about Class.forName() re. ClassLoaders

2013-05-10 Thread Konstantin Kolinko
2013/5/10 Konstantin Preißer verlag.preis...@t-online.de:
 Hi all,

 I apologize for being completely off-topic (this question has nothing to do 
 with Tomcat), but I thought there may be some guys here that are experts in 
 class loading and are able to answer my question.


 You probably know the method java.lang.Class.forName(String name) which 
 returns a class object from the given name. The JavaDoc (Java 7) of this 
 method says:

   Returns the Class object associated with the class or interface with 
 the given string name. Invoking this method is equivalent to:
   Class.forName(className, true, currentLoader)
   where currentLoader denotes the defining class loader of the current 
 class.

 While this description may be a bit ambiguous about what current class 
 means here, the JavaDoc of Class.forName(String name, boolean initialize, 
 ClassLoader loader) makes it clearer by stating:

   For example, in an instance method the expression:
   Class.forName(Foo)
   is equivalent to:
   Class.forName(Foo, true, this.getClass().getClassLoader())


 So, shouldn't this mean that I get the same result/behavior when writing this 
 code:

 public void doSomething() throws ClassNotFoundException {
 Class? clazz = Class.forName(foo.Bar);
 // do something...
 }

 Instead of this one:

 public void doSomething() throws ClassNotFoundException {
 Class? clazz = Class.forName(foo.Bar, true, 
 this.getClass().getClassLoader());
 // do something...
 }

 or did I misunderstand something?


Yes, the same.

BTW, Oracle JDKs come with source code for their public classes,
On Windows that is %JAVA_HOME%/src.zip. Do you have such file?


Best regards,
Konstantin Kolinko

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org



RE: [OT] Querstion about Class.forName() re. ClassLoaders

2013-05-10 Thread Konstantin Preißer
Hi Konstantin,

 -Original Message-
 From: Konstantin Kolinko [mailto:knst.koli...@gmail.com]
 Sent: Friday, May 10, 2013 11:46 PM
 
 Yes, the same.
 
 BTW, Oracle JDKs come with source code for their public classes, On
 Windows that is %JAVA_HOME%/src.zip. Do you have such file?

Thank you for your answer. Yes, I have that file and I looked there, but that 
Class.forName(String) method calls a native method for which I couldn't find 
the source.

I asked this question because the above is not what is implemented by 
Sun/Oracles JRE (I tested with Windows 32-bit versions of JRE 1.7.0_21, Java 8 
EA (b88) and Java 5).

It seems that in Oracles Java, Class.forName(String) uses the ClassLoader of 
the class which implements the method that makes the call to Class.forName(), 
not the ClassLoader of the class on whose instance the method is called (which 
is the one used when calling getClass().getClassLoader()). This can make a 
difference e.g. if the Class with that method has a subclass and you call the 
method on an instance of the subclass (which is what I experienced with a 
Eclipse RCP app which uses a ClassLoader hierarchy for plugins).

However, since the bug exists in current Java 1.7.0_21 (from 2013) and even in 
Java 1.5.0 (2004), I wondered if nobody else noticed this discrepancy between 
the JavaDoc and the actual implementation or maybe if Sun/Oracle just doesn't 
fix such bugs. (I already submitted a bug report on December 1, 2012, but did 
not yet receive a response - so I wanted to make sure my understanding was 
correct).

Thanks!


Regards,
Konstantin Preißer 




-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org