RE: Warning "AJP13 protocol: Reuse is set to false" written logs every second of every day. Please help.

2020-06-18 Thread Alfred Bakia
Hi Chris,

A follow-up. I found the following discussion, which goes back to October 19, 
2011:

http://tomcat.10.x6.nabble.com/Reuse-mod-ajp-proxy-connections-td2096715.html

I think it is relevant to this issue. Back then, one Dimitar said:

>> "My understanding of the *reuse* flag in AJP13_END_RESPONSE
>> structure is that this flag is hard coded and cannot be controlled
>> by configuration settings. I couldn't find any in Tomcat AJP
>> connector configuration that could do that."

You responded with:

>> "I'm no expert, but seeing keepalives disabled for a proxy connection
>> would sure make me think that maybe that setting is disabling, ya
>> know, the keepalive-style connection that AJP is supposed to maintain.
>>... I'd try NOT disabling keepalives and see if that helps."

In our set-up, the settings for socket_keepalive is false by default. So, we're 
now going to add the line

worker.workerName.socket_keepalive=true

to the workers.properties file and see what happens.

Kind regards,

Alfred



-Oorspronkelijk bericht-
Van: Alfred Bakia  
Verzonden: 17 June 2020 19:08
Aan: Tomcat Users List 
Onderwerp: RE: Warning "AJP13 protocol: Reuse is set to false" written logs 
every second of every day. Please help.

Hi Chris,

Thanks for your reply. Thanks also for your warning against interfering with 
the setting allowedRequestAttributesPattern ('Setting the value to ".*" is a 
violation of sane security policy'). I guessed as much, and am grateful for 
your confirmation.

On the subject of mod_jk, we are apparently talking about the same thing. In 
our set-up the mod_jk log is called isapi_redirect.log.
The code that generates the error is indeed /native/common/jk_ajp_common.c. The 
part where the error is generated is:

case JK_AJP13_END_RESPONSE:
ae->reuse = (int)jk_b_get_byte(msg);
if (!ae->reuse) {
/*
 * AJP13 protocol reuse flag set to false.
 * Tomcat will close its side of the connection.
 */
jk_log(l, JK_LOG_WARNING, "(%s) AJP13 protocol: Reuse is set to false",
   ae->worker->name);
}

This code snippet says that reuse is determined - at the end of a response - 
from a byte obtained from some message. Which raises two questions:

1) The response to the "ping" REST request has status code 204 ("No Content"). 
If, as you say, a 204 response is OK, then where would the reuse byte come from?
2) Do you know a way to set the "AJP13 protocol reuse flag" to true? As far as 
we know, the only "reuse" settings at our disposal are the current worker 
settings, worker.workerName.connection_pool_size=500
and worker. workerName.max_reuse_connections=250.

Kind regards,

Alfred


-Oorspronkelijk bericht-
Van: Christopher Schultz 
Verzonden: 16 June 2020 19:55
Aan: Tomcat Users List 
Onderwerp: Re: Warning "AJP13 protocol: Reuse is set to false" written logs 
every second of every day. Please help.

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Alfred,

On 6/15/20 09:45, Alfred Bakia wrote:
> Thanks, Chris. To respond to your remarks:
>
> 1) The warnings, "AJP13 protocol: Reuse is set to false", are being
logged by Tomcat (in the Tomcat AJP connector logs).

Weird. I can't find that string anywhere in code or other files in Tomcat, but 
its right there in mod_jk:

./native/common/jk_ajp_common.c:jk_log(l, JK_LOG_WARNING,
"(%s) AJP13 protocol: Reuse is set to false",

Are you sure you are looking at the right log file?

> 2) As I mentioned earlier, the versions and settings of the servers 
> (and their respective IIS web servers) are the same.
>
> In any case I have discovered "how" the warning occurs. It is indeed 
> triggered by the REST API.
>
> The culprit is a REST request in the form:
>
> http://www.ourdomain.com/api/srv2/exercises/93/1431/26346/ping
>
> It is a POST request and "ping" is a custom REST method. It is just a 
> ping, so the status code of the response is 204 ("No Content").

A 204 response should not cause any problem.

> I can confirm that every ping request results in the warning
> "AJP13 protocol: Reuse is set to false" being written to Tomcat's 
> connector logs.
>
> Researching this on the web, I found the suggestion to add 
> allowedRequestAttributesPattern=".*" to the AJP connector in 
> server.xml.
>
> Is this a viable solution?

This has nothing to do with your REST API. This is a change made to recent 
versions of Tomcat that may require you to allow certain non-standard variables 
to be passed-over from your web server to Tomcat via AJP.

If your "ping" REST API is requiring some information to be passed from the web 
server to Tomcat and you are seeing errors on the Tomcat side, then you may 
have to fiddle with the allowedRequestAttributesPattern. Setting the value to 
".*" is a violation of sane security policy.

But I see no evidence that your "Reuse is set to false" error is related (yet) 
to the allowedRequestAttributesPattern. If you see errors in the Tomcat log, 
please post them and we'll see.

The 

Version migration problems

2020-06-18 Thread Niranjan Rao

Greetings,


I am trying to migrate from 7.0.73 to 9.0.36 and facing challenges.


Java version and operating system version remains same in both cases.


I have carefully reviewed the configurations and everything looks ok. 
Version 9 does not report any problems when starting the application 
either in catalina.out file or in the application log file.



Applications has bunch of JSP pages which sit under WEB-INF/jsp/pages 
directory and some of these pages include fragments from 
WEB-INF/jsp/fragments directory. In the older version V7 this works 
correctly, but in V9 I get error about include not not found. Page do 
get resolved correctly, but includes do not.



Given only change is tomcat version as it's same WAR file deployed on 
same operating system and same java version, I am thinking I am missing 
some basic change in tomcat JSP lookup for version 9.



Can anyone please point me what I can be doing wrong or what I need to 
do so that same WAR file works in both versions



Regards,

Niranjan


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



Re: Cryptominer malware and Tomcat

2020-06-18 Thread Olaf Kock
Hi Pete,

On 17.06.20 23:44, Pete Helgren wrote:
> I am going to guess that it is one of these two known vulnerabilities:
>
> CST-7111: RCE via JSON deserialization (LPS-88051/LPE-165981)
> The JSONDeserializer of Flexjson allows the instantiation of arbitrary
> classes and the invocation of arbitrary setter methods.
>
> CST-7205: Unauthenticated Remote code execution via JSONWS
> (LPS-97029/CVE-2020-7961)
> The JSONWebServiceActionParametersMap of Liferay Portal allows the
> instantiation of arbitrary classes and invocation of arbitrary setter
> methods.
>
> Found the signature in the logs and it's pretty clear that that is
> what we are up against.  However, if something else comes to mind,
> feel free to post back.  I  did come across a couple of other posts
> where the OP said there was nothing but Tomcat and they also ended up
> with the miner.
>
> I have some updating to do
>
Correct analysis.

What you need is this update
https://liferay.dev/blogs/-/blogs/security-patches-for-liferay-portal-6-2-7-0-and-7-1

And while you're at it: There has been another patch published this
month
https://liferay.dev/blogs/-/blogs/june-2020-security-patches-for-liferay-portal-7-1-and-7-2

Best,

Olaf


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