You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by "BARRON, HAROLD H CTR DISA EE" <ha...@disa.mil> on 2011/09/21 20:32:23 UTC
Apache Tomcat 5.5.34 Question (UNCLASSIFIED)
Classification: UNCLASSIFIED
Caveats: NONE
Team,
Since Tomcat 5.5.34 has not been made available for the current
Apache Tomcat Injection Vulnerability=20
(IAVA 2011-B-0114), is there a workaround for this problem until the
patch is out. This software is being used on a Windows 2003 Server and
the current problem is stated below:
Executive Summary:=20
Apache Software Foundation has addressed a vulnerability affecting
various versions of Apache Tomcat. Apache Tomcat is an open source
software implementation of the Java Servlet and JavaServer Pages
technologies. To exploit this vulnerability, a remote attacker would
create and send a malicious request to an affected system. If
successfully exploited, this vulnerability would allow a remote attacker
to bypass security restrictions and obtain access to sensitive
information.
Technical Overview:
Apache Tomcat AJP Protocol Security Bypass and Information Disclosure
Vulnerability - (CVE-2011-3190):
Apache Tomcat supports the AJP protocol which is used with reverse
proxies to pass requests and associated data about the request from the
reverse proxy to Tomcat. The AJP protocol is designed so that when a
request includes a request body, an unsolicited AJP message is sent to
Tomcat that includes the first part (or possibly all) of the request
body. In certain circumstances, Tomcat did not process this message as a
request body but as a new request. This permitted an attacker to have
full control over the AJP message permitting authentication bypass and
information disclosure.=20
Again, is there a workaround or a temporary mitigation process
that anyone knows of that can be implemented until that patch is made
available for download. Thanks
Harold Barron
Classification: UNCLASSIFIED=20
Caveats: NONE
Classification: UNCLASSIFIED
Caveats: NONE
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Apache Tomcat 5.5.34 Question (UNCLASSIFIED)
Posted by "Mark H. Wood" <mw...@IUPUI.Edu>.
Consider something like:
$ openssl rand -base64 32
DJaLgg+fcT8ygQVCd1uKcpLAuxGPmEWhv7j+aorobVs=
if you want help coming up with reasonably hard-to-guess secrets.
--
Mark H. Wood, Lead System Programmer mwood@IUPUI.Edu
Asking whether markets are efficient is like asking whether people are smart.
Re: Apache Tomcat 5.5.34 Question (UNCLASSIFIED)
Posted by André Warnier <aw...@ice-sa.com>.
Christopher Schultz wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> André,
>
> On 9/29/2011 5:59 PM, André Warnier wrote:
>> Addendum : And then we're gonna make sure that the configuration
>> files of Tomcat are given appropriate permissions so that only
>> Tomcat and authorized users can browse said secret. End of
>> addendum.
>
> While that's a good idea in general,
That is how it was meant.
It just seemed to fit well with the general gist of this conversation.
it doesn't help prevent this
> attack unless there is a trusted insider.
>
> Setting the shared secret means that nobody entirely outside your
> environment can inject an AJP message into Tomcat. Read the bug report
> if you haven't already done so... it's quite a brilliant attack.
I'll do that then.
Trusted insider ? sounds intriguing.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Apache Tomcat 5.5.34 Question (UNCLASSIFIED)
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
André,
On 9/29/2011 5:59 PM, André Warnier wrote:
> Addendum : And then we're gonna make sure that the configuration
> files of Tomcat are given appropriate permissions so that only
> Tomcat and authorized users can browse said secret. End of
> addendum.
While that's a good idea in general, it doesn't help prevent this
attack unless there is a trusted insider.
Setting the shared secret means that nobody entirely outside your
environment can inject an AJP message into Tomcat. Read the bug report
if you haven't already done so... it's quite a brilliant attack.
- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAk6F/94ACgkQ9CaO5/Lv0PCozwCcCu6BnHUq6EChu3VINrbONppg
SYEAn1mPwXnmOsi52zSsMN+XPH9lvB0/
=LVAr
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Apache Tomcat 5.5.34 Question (UNCLASSIFIED)
Posted by André Warnier <aw...@ice-sa.com>.
Christopher Schultz wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Harold,
>
> On 9/22/2011 11:51 AM, BARRON, HAROLD H CTR DISA EE wrote:
>> Classification: UNCLASSIFIED
>
> Thank god none of this is classified.
>
>> I might have to write a plan of action to temporarily mitigate
>> this issue until the update is posted. I just want to be able to
>> present it in a way that my users that my users will not have a
>> problem understanding when I do.
>
> Here's your plan:
>
> "We're gonna set a pre-shared secret on both our web servers and our
> application servers and bounce everything.
Addendum :
And then we're gonna make sure that the configuration files of Tomcat are given
appropriate permissions so that only Tomcat and authorized users can browse said secret.
End of addendum.
Then the chances of this
> attack being carried-out are reduced to the key space of the secret.
> So, make-up a big long string of random characters and set:
>
> workers.properties:
> worker.myWorker.secret=[super secret string]
>
> server.xml:
> <Connector request.secret="[super secret string]" ...
> "
>
> mod_jk has a 8192-character limit on each configuration line of
> workers.properties. The form of the directive is:
>
> worker.[workerName].secret=[here goes the secret]
>
> That means that you have (8192 - 15 - strlen(workerName)) characters
> for your shared secret. That's a big space to search.
>
> This is not a terribly arduous technique to mitigate this attack.
>
> - -chris
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.10 (MingW32)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>
> iEYEARECAAYFAk6E4yEACgkQ9CaO5/Lv0PDKkQCgjJoCQkxYOuodTu1/CAHYdGtD
> 3vkAoJ3k/mgmruwYSvVKPBBHzduEwmgI
> =Su3s
> -----END PGP SIGNATURE-----
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Apache Tomcat 5.5.34 Question (UNCLASSIFIED)
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Harold,
On 9/22/2011 11:51 AM, BARRON, HAROLD H CTR DISA EE wrote:
> Classification: UNCLASSIFIED
Thank god none of this is classified.
> I might have to write a plan of action to temporarily mitigate
> this issue until the update is posted. I just want to be able to
> present it in a way that my users that my users will not have a
> problem understanding when I do.
Here's your plan:
"We're gonna set a pre-shared secret on both our web servers and our
application servers and bounce everything. Then the chances of this
attack being carried-out are reduced to the key space of the secret.
So, make-up a big long string of random characters and set:
workers.properties:
worker.myWorker.secret=[super secret string]
server.xml:
<Connector request.secret="[super secret string]" ...
"
mod_jk has a 8192-character limit on each configuration line of
workers.properties. The form of the directive is:
worker.[workerName].secret=[here goes the secret]
That means that you have (8192 - 15 - strlen(workerName)) characters
for your shared secret. That's a big space to search.
This is not a terribly arduous technique to mitigate this attack.
- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAk6E4yEACgkQ9CaO5/Lv0PDKkQCgjJoCQkxYOuodTu1/CAHYdGtD
3vkAoJ3k/mgmruwYSvVKPBBHzduEwmgI
=Su3s
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
RE: Apache Tomcat 5.5.34 Question (UNCLASSIFIED)
Posted by "BARRON, HAROLD H CTR DISA EE" <ha...@disa.mil>.
Classification: UNCLASSIFIED
Caveats: NONE
I might have to write a plan of action to temporarily mitigate this issue until the update is posted. I just want to be able to present it in a way that my users that my users will not have a problem understanding when I do.
-----Original Message-----
From: Pid * [mailto:pid@pidster.com]
Sent: Thursday, September 22, 2011 11:47 AM
To: Tomcat Users List
Subject: Re: Apache Tomcat 5.5.34 Question (UNCLASSIFIED)
On 22 Sep 2011, at 14:21, "BARRON, HAROLD H CTR DISA EE"
<ha...@disa.mil> wrote:
> Classification: UNCLASSIFIED
> Caveats: NONE
>
> Thanks....it's kind of hard to understand how to implement this workaround but I will look into it.
Do you use HTTPD with mod_jk or mod_proxy_ajp in front if Tomcat?
What is hard to understand, maybe we can help... ?
p
> Appreciate the response.
>
> -----Original Message-----
> From: Konstantin Kolinko [mailto:knst.kolinko@gmail.com]
> Sent: Wednesday, September 21, 2011 7:02 PM
> To: Tomcat Users List
> Subject: Re: Apache Tomcat 5.5.34 Question (UNCLASSIFIED)
>
> 2011/9/21 BARRON, HAROLD H CTR DISA EE <ha...@disa.mil>:
>>
>> Apache Tomcat AJP Protocol Security Bypass and Information Disclosure
>> Vulnerability - (CVE-2011-3190):
>>
>
> 1. Mitigation options are listed here:
> http://tomcat.apache.org/security-5.html
> http://tomcat.apache.org/security-6.html
>
> Both 5.5 and 6.0 have a connector implementation that is not
> vulnerable to this issue
>
> 2. 5.5.34 binaries are already available for testing and have good
> chances to be officially released in the following days. 6.0.34
> release plans have not been discussed (with 6.0.33 being released not
> so long ago).
>
> Best regards,
> Konstantin Kolinko
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
> Classification: UNCLASSIFIED
> Caveats: NONE
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Classification: UNCLASSIFIED
Caveats: NONE
Re: Apache Tomcat 5.5.34 Question (UNCLASSIFIED)
Posted by Pid * <pi...@pidster.com>.
On 22 Sep 2011, at 14:21, "BARRON, HAROLD H CTR DISA EE"
<ha...@disa.mil> wrote:
> Classification: UNCLASSIFIED
> Caveats: NONE
>
> Thanks....it's kind of hard to understand how to implement this workaround but I will look into it.
Do you use HTTPD with mod_jk or mod_proxy_ajp in front if Tomcat?
What is hard to understand, maybe we can help... ?
p
> Appreciate the response.
>
> -----Original Message-----
> From: Konstantin Kolinko [mailto:knst.kolinko@gmail.com]
> Sent: Wednesday, September 21, 2011 7:02 PM
> To: Tomcat Users List
> Subject: Re: Apache Tomcat 5.5.34 Question (UNCLASSIFIED)
>
> 2011/9/21 BARRON, HAROLD H CTR DISA EE <ha...@disa.mil>:
>>
>> Apache Tomcat AJP Protocol Security Bypass and Information Disclosure
>> Vulnerability - (CVE-2011-3190):
>>
>
> 1. Mitigation options are listed here:
> http://tomcat.apache.org/security-5.html
> http://tomcat.apache.org/security-6.html
>
> Both 5.5 and 6.0 have a connector implementation that is not
> vulnerable to this issue
>
> 2. 5.5.34 binaries are already available for testing and have good
> chances to be officially released in the following days. 6.0.34
> release plans have not been discussed (with 6.0.33 being released not
> so long ago).
>
> Best regards,
> Konstantin Kolinko
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
> Classification: UNCLASSIFIED
> Caveats: NONE
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
RE: Apache Tomcat 5.5.34 Question (UNCLASSIFIED)
Posted by "BARRON, HAROLD H CTR DISA EE" <ha...@disa.mil>.
Classification: UNCLASSIFIED
Caveats: NONE
Thanks....it's kind of hard to understand how to implement this workaround but I will look into it.
Appreciate the response.
-----Original Message-----
From: Konstantin Kolinko [mailto:knst.kolinko@gmail.com]
Sent: Wednesday, September 21, 2011 7:02 PM
To: Tomcat Users List
Subject: Re: Apache Tomcat 5.5.34 Question (UNCLASSIFIED)
2011/9/21 BARRON, HAROLD H CTR DISA EE <ha...@disa.mil>:
>
> Apache Tomcat AJP Protocol Security Bypass and Information Disclosure
> Vulnerability - (CVE-2011-3190):
>
1. Mitigation options are listed here:
http://tomcat.apache.org/security-5.html
http://tomcat.apache.org/security-6.html
Both 5.5 and 6.0 have a connector implementation that is not
vulnerable to this issue
2. 5.5.34 binaries are already available for testing and have good
chances to be officially released in the following days. 6.0.34
release plans have not been discussed (with 6.0.33 being released not
so long ago).
Best regards,
Konstantin Kolinko
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Classification: UNCLASSIFIED
Caveats: NONE
Re: Apache Tomcat 5.5.34 Question (UNCLASSIFIED)
Posted by Konstantin Kolinko <kn...@gmail.com>.
2011/9/21 BARRON, HAROLD H CTR DISA EE <ha...@disa.mil>:
>
> Apache Tomcat AJP Protocol Security Bypass and Information Disclosure
> Vulnerability - (CVE-2011-3190):
>
1. Mitigation options are listed here:
http://tomcat.apache.org/security-5.html
http://tomcat.apache.org/security-6.html
Both 5.5 and 6.0 have a connector implementation that is not
vulnerable to this issue
2. 5.5.34 binaries are already available for testing and have good
chances to be officially released in the following days. 6.0.34
release plans have not been discussed (with 6.0.33 being released not
so long ago).
Best regards,
Konstantin Kolinko
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org