Re: Invoke methods in EL?

[Tim Watts]

Thanks Mark.  That does help.

On Mon, 2017-04-10 at 23:24 +0100, Mark Thomas wrote:
> On 10/04/17 16:35, Tim Watts wrote:
> > Environment: Tomcat 7.0.59; JRE 1.8.0_72
> > 
> > I suspect the answer to my problem is "You can't do that" but here goes:
> > 
> > A simple JSP that tries to get a Calendar instance and outputs the year:
> > 
> > <%@ page language="java" 
> > contentType="text/html; 
> > charset=UTF-8" pageEncoding="UTF-8"%>
> > <%@ taglib prefix="c" uri="http://java.sun.com/jsp/jstl/core; %>
> > 
> > 
> > 
> > 
> > 
> > The year is ${ Y }
> > 
> > 
> > 
> > This presents a page that just says "The year is" but no year value.  Is
> > there some syntactical mojo I'm missing or is my best alternative to
> > resort to a scriptlet?  
> > 
> > (And for context, I actually want to do something along these lines in a
> > tag file.)
> 
> You can do something like that but...
> 
> You'll need EL 3.0 which means Tomcat 8 minimum. I recommend 8.5.x in
> preference to 8.0.x.
> 
> EL doesn't let you specify the package in the expression. You have to
> explicitly import. With Tomcat, if you import the class into the JSP
> page that automatically imports it into the EL expression. (Whether
> Tomcat should do this or not is an open question with the EL Expert Group.)
> 
> Then factor in that EL only lets you reference static methods and fields
> on concrete classes (which means you can't use Calendar since it is
> abstract) and you get:
> 
> 
> <%@ page language="java"
> import="java.util.Calendar,java.util.GregorianCalendar"
> contentType="text/html;charset=UTF-8"
> pageEncoding="UTF-8"%>
> <%@ taglib prefix="c" uri="http://java.sun.com/jsp/jstl/core; %>
> 
> 
> 
> 
> 
> The year is ${ Y }
> 
> 
> 
> 
> Drop the above test into a JSP page in the examples web application in
> Tomcat 8 onwards and you'll get the output you are looking for.
> 
> Note I tested this with 9.0.x but 8.x should behave the same way.
> 
> HTH,
> 
> Mark
> 
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
> 



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

Re: Invoke methods in EL?

[Mark Thomas]

On 10/04/17 16:35, Tim Watts wrote:
> Environment: Tomcat 7.0.59; JRE 1.8.0_72
> 
> I suspect the answer to my problem is "You can't do that" but here goes:
> 
> A simple JSP that tries to get a Calendar instance and outputs the year:
> 
> <%@ page language="java" 
> contentType="text/html; 
> charset=UTF-8" pageEncoding="UTF-8"%>
> <%@ taglib prefix="c" uri="http://java.sun.com/jsp/jstl/core; %>
> 
> 
> 
>   
>   
>   The year is ${ Y }
> 
> 
> 
> This presents a page that just says "The year is" but no year value.  Is
> there some syntactical mojo I'm missing or is my best alternative to
> resort to a scriptlet?  
> 
> (And for context, I actually want to do something along these lines in a
> tag file.)

You can do something like that but...

You'll need EL 3.0 which means Tomcat 8 minimum. I recommend 8.5.x in
preference to 8.0.x.

EL doesn't let you specify the package in the expression. You have to
explicitly import. With Tomcat, if you import the class into the JSP
page that automatically imports it into the EL expression. (Whether
Tomcat should do this or not is an open question with the EL Expert Group.)

Then factor in that EL only lets you reference static methods and fields
on concrete classes (which means you can't use Calendar since it is
abstract) and you get:


<%@ page language="java"
import="java.util.Calendar,java.util.GregorianCalendar"
contentType="text/html;charset=UTF-8"
pageEncoding="UTF-8"%>
<%@ taglib prefix="c" uri="http://java.sun.com/jsp/jstl/core; %>





The year is ${ Y }




Drop the above test into a JSP page in the examples web application in
Tomcat 8 onwards and you'll get the output you are looking for.

Note I tested this with 9.0.x but 8.x should behave the same way.

HTH,

Mark

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

Re: [SECURITY] CVE-2017-5647 Apache Tomcat Information Disclosure

[Mark Thomas]

On 10/04/17 20:41, Stefan Mayr wrote:
> Hi,
> 
> Am 10.04.2017 um 21:14 schrieb Mark Thomas:
>> CVE-2017-5647 Apache Tomcat Information Disclosure
>>
>> Severity: Important
>>
>> Vendor: The Apache Software Foundation
>>
>> Versions Affected:
>> Apache Tomcat 9.0.0.M1 to 9.0.0.M18
>> Apache Tomcat 8.5.0 to 8.5.12
>> Apache Tomcat 8.0.0.RC1 to 8.0.42
>> Apache Tomcat 7.0.0 to 7.0.76
>> Apache Tomcat 6.0.0 to 6.0.52
>>
>> Description
>> A bug in the handling of the pipelined requests when send file was used
>> resulted in the pipelined request being lost when send file processing
>> of the previous request completed. This could result in responses
>> appearing to be sent for the wrong request. For example, a user agent
>> that sent requests A, B and C could see the correct response for request
>> A, the response for request C for request B and no response for request C.
> 
> How about the pipelining: this reuses a TCP connection for a single
> user. Is it possible for two different users (TCP connections) to see a
> response for the other user?

Not with this vulnerability. The problem occurs within a single
connection. If a reverse-proxy used pipe-lining and pipelined requests
for multiple users onto a single connection (I think this is extremely
unlikely) then that would be different.

>> Mitigation:
>> Users of the affected versions should apply one of the following
>> mitigations:
>> - Switch to the BIO HTTP where available
>> - Disable send file
>> - Upgrade to Apache Tomcat 9.0.0.M19 or later
>> - Upgrade to Apache Tomcat 8.5.13 or later
>> - Upgrade to Apache Tomcat 8.0.43 or later
>> - Upgrade to Apache Tomcat 7.0.77 or later
>> - Upgrade to Apache Tomcat 6.0.53 or later
> 
> Does this also affect requests to the AJP connector (Apache httpd +
> mod_jk in front of Tomcat)?

The AJP protocol does not support sendfile.

Mark


> 
>> Credit:
>> This issue was identified by the Tomcat security team.
>>
>> History:
>> 2017-04-10 Original advisory
>>
>> References:
>> [1] http://tomcat.apache.org/security-9.html
>> [2] http://tomcat.apache.org/security-8.html
>> [3] http://tomcat.apache.org/security-7.html
>> [4] http://tomcat.apache.org/security-6.html
>>
>>
>> -
>> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
>> For additional commands, e-mail: users-h...@tomcat.apache.org
>>
> 
> Thanks,
> 
>Stefan
> 
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
> 


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

Re: [SECURITY] CVE-2017-5647 Apache Tomcat Information Disclosure

[Stefan Mayr]

Hi,

Am 10.04.2017 um 21:14 schrieb Mark Thomas:
> CVE-2017-5647 Apache Tomcat Information Disclosure
> 
> Severity: Important
> 
> Vendor: The Apache Software Foundation
> 
> Versions Affected:
> Apache Tomcat 9.0.0.M1 to 9.0.0.M18
> Apache Tomcat 8.5.0 to 8.5.12
> Apache Tomcat 8.0.0.RC1 to 8.0.42
> Apache Tomcat 7.0.0 to 7.0.76
> Apache Tomcat 6.0.0 to 6.0.52
> 
> Description
> A bug in the handling of the pipelined requests when send file was used
> resulted in the pipelined request being lost when send file processing
> of the previous request completed. This could result in responses
> appearing to be sent for the wrong request. For example, a user agent
> that sent requests A, B and C could see the correct response for request
> A, the response for request C for request B and no response for request C.

How about the pipelining: this reuses a TCP connection for a single
user. Is it possible for two different users (TCP connections) to see a
response for the other user?

> Mitigation:
> Users of the affected versions should apply one of the following
> mitigations:
> - Switch to the BIO HTTP where available
> - Disable send file
> - Upgrade to Apache Tomcat 9.0.0.M19 or later
> - Upgrade to Apache Tomcat 8.5.13 or later
> - Upgrade to Apache Tomcat 8.0.43 or later
> - Upgrade to Apache Tomcat 7.0.77 or later
> - Upgrade to Apache Tomcat 6.0.53 or later

Does this also affect requests to the AJP connector (Apache httpd +
mod_jk in front of Tomcat)?

> Credit:
> This issue was identified by the Tomcat security team.
> 
> History:
> 2017-04-10 Original advisory
> 
> References:
> [1] http://tomcat.apache.org/security-9.html
> [2] http://tomcat.apache.org/security-8.html
> [3] http://tomcat.apache.org/security-7.html
> [4] http://tomcat.apache.org/security-6.html
> 
> 
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
> 

Thanks,

   Stefan

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

Using Log4J2 2.8 (via the 1.2 API Bridge) for Tomcat8 Internal Logging - RollingFileAppender does not (cannot?) create new Log File

[Ankit Agarwal]

Hi,

I’m using Log4J2 (2.8) via the 1.2 API Bridge for Tomcat 8 internal logging.

I followed the instructions here: 
https://tomcat.apache.org/tomcat-8.0-doc/logging.html#Using_Log4j 

- With the exception that I also copied the Bridge JAR into the Tomcat8 lib 
directory

I have configured Log4J2 with this XML file



 
  ${sys:catalina.base}/logs
  CMS
  Tomcat
  ${env:PUBLIC_IP_ADDRESS}
  
  %d{DATE} "%d{ISO8601}" "${systemName}" 
"${componentName}" "%X{clientIpAddress}" "%X{clientTcpPort}" "%X{username}" 
"%X{sessionId}" "%X{sessionAuthenticationId}" "%X{sessionAuthenticationToken}" 
"${serverIpAddress}" "%T" "%t" "%X{apiName}" "%X{apiSystemActionType}" 
"%X{apiSystemItemType}" "%x" "%l" "%p" "%m"%n%n
 
 
  
   
  
  
   
   

   
   
  
  
   
   

   
   
  
  
   
   

   
   
  
  
   
   

   
   
  
 
 
  
   
  
  
   
  
  
   
  
  
   
  
 



All 4 RollingFile Appenders are configured identically (except for the log 
filename).

The problem I’m running into is that when the SizeBasedTriggeringPolicy is 
executed, the current log file is zipped. However, a new log file is not 
created.

As a result, the Tomcat8 stops logging.

If I restart Tomcat8, then a new file is created and the Tomcat8 functions 
normally, but only until this new log file reaches its limit and is zipped up. 
Then once again, the problem repeats itself.

Does the 1.2 API Bridge / Tomcat 8 not support the SizeBasedTriggeringPolicy?

Do I have any options other than restarting the Tomcat8? Will the 
TimeBasedTriggeringPolicy work and is that my only option?

Since the Log4J2 being used in Tomcat8 has no problem creating the required 
files on restart, I don’t think its a permissions issue.

I’d appreciate any thoughts and pointers.

Thanks,
Ankit

[SECURITY] CVE-2017-5648 Apache Tomcat Information Disclosure

[Mark Thomas]

CVE-2017-5648 Apache Tomcat Information Disclosure

Severity: Low

Vendor: The Apache Software Foundation

Versions Affected:
Apache Tomcat 9.0.0.M1 to 9.0.0.M17
Apache Tomcat 8.5.0 to 8.5.11
Apache Tomcat 8.0.0.RC1 to 8.0.41
Apache Tomcat 7.0.0 to 7.0.75
Apache Tomcat 6.0.x is not affected

Description
While investigating bug 60718, it was noticed that some calls to
application listeners did not use the appropriate facade object. When
running an untrusted application under a SecurityManager, it was
therefore possible for that untrusted application to retain a reference
to the request or response object and thereby access and/or modify
information associated with another web application.

Mitigation:
Users of the affected versions should apply one of the following
mitigations:
- Upgrade to Apache Tomcat 9.0.0.M18 or later
- Upgrade to Apache Tomcat 8.5.12 or later
- Upgrade to Apache Tomcat 8.0.42 or later
- Upgrade to Apache Tomcat 7.0.76 or later

Credit:
This issue was identified by the Tomcat security team.

History:
2017-04-10 Original advisory

References:
[1] https://bz.apache.org/bugzilla/show_bug.cgi?id=60718
[2] http://tomcat.apache.org/security-9.html
[3] http://tomcat.apache.org/security-8.html
[4] http://tomcat.apache.org/security-7.html


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

[SECURITY] CVE-2017-5647 Apache Tomcat Information Disclosure

[Mark Thomas]

CVE-2017-5647 Apache Tomcat Information Disclosure

Severity: Important

Vendor: The Apache Software Foundation

Versions Affected:
Apache Tomcat 9.0.0.M1 to 9.0.0.M18
Apache Tomcat 8.5.0 to 8.5.12
Apache Tomcat 8.0.0.RC1 to 8.0.42
Apache Tomcat 7.0.0 to 7.0.76
Apache Tomcat 6.0.0 to 6.0.52

Description
A bug in the handling of the pipelined requests when send file was used
resulted in the pipelined request being lost when send file processing
of the previous request completed. This could result in responses
appearing to be sent for the wrong request. For example, a user agent
that sent requests A, B and C could see the correct response for request
A, the response for request C for request B and no response for request C.

Mitigation:
Users of the affected versions should apply one of the following
mitigations:
- Switch to the BIO HTTP where available
- Disable send file
- Upgrade to Apache Tomcat 9.0.0.M19 or later
- Upgrade to Apache Tomcat 8.5.13 or later
- Upgrade to Apache Tomcat 8.0.43 or later
- Upgrade to Apache Tomcat 7.0.77 or later
- Upgrade to Apache Tomcat 6.0.53 or later

Credit:
This issue was identified by the Tomcat security team.

History:
2017-04-10 Original advisory

References:
[1] http://tomcat.apache.org/security-9.html
[2] http://tomcat.apache.org/security-8.html
[3] http://tomcat.apache.org/security-7.html
[4] http://tomcat.apache.org/security-6.html


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

[SECURITY] CVE-2017-5650 Apache Tomcat Denial of Service

[Mark Thomas]

CVE-2017-5650 Apache Tomcat Denial of Service

Severity: Important

Vendor: The Apache Software Foundation

Versions Affected:
Apache Tomcat 9.0.0.M1 to 9.0.0.M18
Apache Tomcat 8.5.0 to 8.5.12
Apache Tomcat 8.0.x and earlier are not affected

Description
The handling of an HTTP/2 GOAWAY frame for a connection did not close
streams associated with that connection that were currently waiting for
a WINDOW_UPDATE before allowing the application to write more data.
These waiting streams each consumed a thread. A malicious client could
therefore construct a series of HTTP/2 requests that would consume all
available processing threads.

Mitigation:
Users of the affected versions should apply one of the following
mitigations:
- Upgrade to Apache Tomcat 9.0.0.M19 or later
- Upgrade to Apache Tomcat 8.5.13 or later

Credit:
This issue was identified by Chun Han Hsiao and reported responsibly to
the Tomcat security team.

History:
2017-04-10 Original advisory

References:
[1] http://tomcat.apache.org/security-9.html
[2] http://tomcat.apache.org/security-8.html


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

[SECURITY] CVE-2017-5651 Apache Tomcat Information Disclosure

[Mark Thomas]

CVE-2017-5651 Apache Tomcat Information Disclosure

Severity: Important

Vendor: The Apache Software Foundation

Versions Affected:
Apache Tomcat 9.0.0.M1 to 9.0.0.M18
Apache Tomcat 8.5.0 to 8.5.12
Apache Tomcat 8.0.x and earlier are not affected

Description:
The refactoring of the HTTP connectors for 8.5.x onwards, introduced a
regression in the send file processing. If the send file processing
completed quickly, it was possible for the Processor to be added to the
processor cache twice. This could result in the same Processor being
used for multiple requests which in turn could lead to unexpected errors
and/or response mix-up.

Mitigation:
Users of the affected versions should apply one of the following
mitigations:
- Upgrade to Apache Tomcat 9.0.0.M19 or later
- Upgrade to Apache Tomcat 8.5.13 or later

Credit:
This issue was reported publicly as Bug 60918 [1] and the security
implications identified by the Tomcat security team.

History:
2017-04-10 Original advisory

References:
[1] https://bz.apache.org/bugzilla/show_bug.cgi?id=60918
[2] http://tomcat.apache.org/security-9.html
[3] http://tomcat.apache.org/security-8.html


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

Invoke methods in EL?

[Tim Watts]

Environment: Tomcat 7.0.59; JRE 1.8.0_72

I suspect the answer to my problem is "You can't do that" but here goes:

A simple JSP that tries to get a Calendar instance and outputs the year:

<%@ page language="java" 
contentType="text/html; 
charset=UTF-8" pageEncoding="UTF-8"%>
<%@ taglib prefix="c" uri="http://java.sun.com/jsp/jstl/core; %>





The year is ${ Y }



This presents a page that just says "The year is" but no year value.  Is
there some syntactical mojo I'm missing or is my best alternative to
resort to a scriptlet?  

(And for context, I actually want to do something along these lines in a
tag file.)



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