Hosts and ROOT folder
Hi all I'am new to Tomcat, so please do not kill me if the issue is simple or my english is bad. I'am running Tomcat 7.0.42 on WinServer 2012 R2. It is front end for a Digital Asset Management system. The Tomcat is installed as part of the DAM system and could be different from a plain vanilla install. My problem is Host and path to webapps. I basically only have one webapp witch is duplicated when I get a new customer. But when I deploy a new webapp and make a host element in conf\server.xml, I have to make a folder named ROOT in my webapp (webapps/customer/ROOT) and move all files to this folder to get things working. We also did that in a very old version (3 or 4), but haven't done that in several years. I can see the default webapp is also in a ROOT folder. When I put the files in the ROOT folder my application guy can't see the site in his administration tool for the DAM system. Where is it defined that files for my webapps goes in a ROOT folder? I tried to make a folder in conf/Catalina/ reflecting the name of the webapp, I can't get that to work either. My last try will be to define docbase in the host element in server.conf, but in the documentation this is not recommended. All help would be appreciated. If you need more info please tell me. Thanks Venlig hilsen / Best regards Michael Salmon IT-Chef t: +45 87 95 55 43 m: +45 24 86 40 08 [datagraf]http://www.datagraf.dk/ Jaegerg?rdsgade 122, DK-8000 Aarhus C * t: +45 87 95 55 55 * www.datagraf.dkhttp://www.datagraf.dk
Re: Hosts and ROOT folder
On 27/05/2014 09:32, Michael Salmon wrote: Hi all I'am new to Tomcat, so please do not kill me if the issue is simple or my english is bad. We won't kill you. We might point you towards some documentation though ;) And don't worry about your English. I am sure it is orders of magnitude better than most of us here could manage in your native language. I'am running Tomcat 7.0.42 on WinServer 2012 R2. It is front end for a Digital Asset Management system. The Tomcat is installed as part of the DAM system and could be different from a plain vanilla install. My problem is Host and path to webapps. I basically only have one webapp witch is duplicated when I get a new customer. But when I deploy a new webapp and make a host element in conf\server.xml, I have to make a folder named ROOT in my webapp (webapps/customer/ROOT) and move all files to this folder to get things working. We also did that in a very old version (3 or 4), but haven't done that in several years. I can see the default webapp is also in a ROOT folder. When I put the files in the ROOT folder my application guy can't see the site in his administration tool for the DAM system. Where is it defined that files for my webapps goes in a ROOT folder? I tried to make a folder in conf/Catalina/ reflecting the name of the webapp, I can't get that to work either. My last try will be to define docbase in the host element in server.conf, but in the documentation this is not recommended. All help would be appreciated. If you need more info please tell me. OK. The simplest thing will be to provide us with the following: 1) Your full server.xml. Please remove all comments and replace any sensitive information (e.g. passwords, customer names etc.) 2) The file structure under webapps. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Hosts and ROOT folder
Michael Salmon wrote: Hi all I'am new to Tomcat, so please do not kill me if the issue is simple or my english is bad. I'am running Tomcat 7.0.42 on WinServer 2012 R2. It is front end for a Digital Asset Management system. The Tomcat is installed as part of the DAM system and could be different from a plain vanilla install. My problem is Host and path to webapps. I basically only have one webapp witch is duplicated when I get a new customer. But when I deploy a new webapp and make a host element in conf\server.xml, I have to make a folder named ROOT in my webapp (webapps/customer/ROOT) and move all files to this folder to get things working. We also did that in a very old version (3 or 4), but haven't done that in several years. I can see the default webapp is also in a ROOT folder. When I put the files in the ROOT folder my application guy can't see the site in his administration tool for the DAM system. Where is it defined that files for my webapps goes in a ROOT folder? I tried to make a folder in conf/Catalina/ reflecting the name of the webapp, I can't get that to work either. My last try will be to define docbase in the host element in server.conf, but in the documentation this is not recommended. All help would be appreciated. If you need more info please tell me. Well, you're right, it's hard not to kill you, but we will try. This list would quickly get boring if we killed all the newcomers. And I personally welcome that kind of question anway, because it is one of the few kinds which I can answer, so I get bonus points. First, a note : whenever possible, you should try to avoid modifying conf/server.xml. That's mainly because if you make a change there, you have to restart Tomcat to make it notice. But in your case, if you create a new Host for each new customer, there is no other way, so keep doing it. Some data : each Host in server.xml has its own appBase, which is the top directory in which webapps (also named context) for that Host are located. By default, this is webapps, which is a relative location, which by default points to : (tomcat-installation-directory)/webapps/. But you can create another directory somewhere, and point the appBase of another Host to this new directory, and then this Host will look in that place for its own webapps. Normally, any given application (or webapp or context) is accessed by a URL of the form : http://hostname[:port]/webapp-name/ where webapp-name is the name of a sub-directory just below the appBase directory for that Host. So - if your application would be (imaginatively) named myWebApp - and your Host name would be (imaginatively) named customer1.customers.com - and the corresponding Host tage would be like Host name=customer1.customers.com appBase=C:/websites/customer1/webapps/ ... then - the place to put your application would be in C:/websites/customer1/webapps/myWebApp/ - and the customer would access it via a URL like : http://customer1.customers.com/myWebApp/...; Then, one more thing : If you want your application to be the default webapp, which the user could call up with a URL like : http://customer1.customers.com/ then you have to do the following : - create a directory C:/websites/customer1/webapps/ROOT/ - and place your application there (That name ROOT (in capitals, important) is interpreted by Tomcat in a special way, so that if Tomcat does not recognise the name of the application requested in the URL, it will default to looking there). (Kind of). Of course, for all of this to work (and for the users to be able to get to that webserver), the name customer1.customers.com would have to be registered in the DNS system, with the IP address of your Tomcat server. Hope this helps. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
SV: Hosts and ROOT folder
Learn something! Screendump is no-go. Here is the structure: C:\Program Files\Canto\Cumulus Web Solutions\apache-tomcat-7.0.42\webapps\coop\R OOTdir Volume in drive C has no label. Volume Serial Number is 3439-CAF5 Directory of C:\Program Files\Canto\Cumulus Web Solutions\apache-tomcat-7.0.42\ webapps\coop\ROOT 27-05-2014 07:10DIR . 27-05-2014 07:10DIR .. 27-05-2014 07:10 986 addtocollectionbasket.jspx 27-05-2014 07:10 4.639 advancedsearchcategoriesexistingvalues.jspx 27-05-2014 07:10 1.977 advancedsearchconditionadd.jspx 27-05-2014 07:10 872 advancedsearchconditioncheck.jspx 27-05-2014 07:10 825 advancedsearchconditiondelete.jspx 27-05-2014 07:10 1.839 advancedsearchconditionedit.jspx 27-05-2014 07:10 4.511 advancedsearchconditioneditor.jspx 27-05-2014 07:10 2.914 advancedsearchconditioneditorboolean.jspx 27-05-2014 07:10 3.007 advancedsearchconditioneditorcategories.jspx 27-05-2014 07:10 5.211 advancedsearchconditioneditordatasize.jspx 27-05-2014 07:10 5.219 advancedsearchconditioneditordatasizelong.js px 27-05-2014 07:1021.464 advancedsearchconditioneditordate.jspx 27-05-2014 07:1012.524 advancedsearchconditioneditordateonly.jspx 27-05-2014 07:10 5.197 advancedsearchconditioneditordouble.jspx 27-05-2014 07:10 5.341 advancedsearchconditioneditorinteger.jspx 27-05-2014 07:10 3.754 advancedsearchconditioneditorlabel.jspx 27-05-2014 07:10 5.239 advancedsearchconditioneditorlengthininch.js px 27-05-2014 07:10 5.299 advancedsearchconditioneditorlong.jspx 27-05-2014 07:10 4.044 advancedsearchconditioneditorrating.jspx 27-05-2014 07:10 5.225 advancedsearchconditioneditorresolution.jspx 27-05-2014 07:10 5.987 advancedsearchconditioneditorstring.jspx 27-05-2014 07:10 3.673 advancedsearchconditioneditorstringenum.jspx 27-05-2014 07:10 5.212 advancedsearchconditioneditortimeonly.jspx 27-05-2014 07:10 848 advancedsearchconditionsave.jspx 27-05-2014 07:10 8.994 advancedsearchcontainer.jspx 27-05-2014 07:10 1.913 advancedsearchfieldlistpopup.jspx 27-05-2014 07:10 3.284 advancedsearchstatistics.jspx 27-05-2014 07:10 1.651 applicationfooter.jspx 27-05-2014 07:10 781 boxcollapsestate.jspx 27-05-2014 07:10 9.420 breadcrumb.jspx 27-05-2014 07:10 782 cancelprocess.jspx 27-05-2014 07:10 9.111 categoryfilter.jspx 27-05-2014 07:10 1.144 changelanguage.jspx 27-05-2014 07:10 1.101 changepassword.jspx 27-05-2014 07:10 5.912 changepasswordconfiguration.jspx 27-05-2014 07:10 905 changepasswordrequest.jspx 27-05-2014 07:10 5.130 changepasswordrequestconfiguration.jspx 27-05-2014 07:10 3.347 changepasswordrequestsuccess.jspx 27-05-2014 07:10 1.899 changepasswordrequestwindow.jspx 27-05-2014 07:10 3.299 changepasswordrequestwindowconfiguration.jsp x 27-05-2014 07:10 2.863 changepasswordsuccess.jspx 27-05-2014 07:10 793 changerecordviewthumbnailsize.jspx 27-05-2014 07:10 1.095 changetheme.jspx 27-05-2014 07:10 664 changeviewsettings.jspx 27-05-2014 07:10 2.037 collectionbasketbulkfunctions.jspx 27-05-2014 07:10 1.822 collectionbasketbutton.jspx 27-05-2014 07:10 785 collectionbasketclear.jspx 27-05-2014 07:10 792 collectionbasketdelete.jspx 27-05-2014 07:10 787 collectionbasketrename.jspx 27-05-2014 07:10 811 collectionbasketreveal.jspx 27-05-2014 07:10 814 collectionbasketrevealdeletefilter.jspx 27-05-2014 07:10 875 collectionbasketsetcurrent.jspx 27-05-2014 07:1038.508 collectionbasketview.jspx 27-05-2014 07:10 995 communitydiscussionhandler.jspx 27-05-2014 07:10 4.489 contact.jspx 27-05-2014 07:10 3.354 contactview.jspx 27-05-2014 07:10 3.651 createaccount.jspx 27-05-2014 07:10 6.400 createaccountconfiguration.jspx 27-05-2014 07:10 2.444 createaccountwindow.jspx 27-05-2014 07:10 4.926 createaccountwindowconfiguration.jspx 27-05-2014 07:10 2.823 createpincollection.jspx 27-05-2014 07:1028.533 createpincollectionconfiguration.jspx 27-05-2014 07:10 2.816 createuploadcollection.jspx 27-05-2014 07:1029.322 createuploadcollectionconfiguration.jspx 06-05-2014 07:43DIR customizations 27-05-2014 07:10 799 deleteprocess.jspx 27-05-2014 07:10 1.226 directdownloadconfiguration.jspx 27-05-2014 07:10 1.214
Re: SV: Hosts and ROOT folder
On 27/05/2014 11:59, Michael Salmon wrote: Hi Here is my server.xml snip/ Host name=localhost appBase=webapps unpackWARs=true autoDeploy=true Valve className=org.apache.catalina.valves.AccessLogValve directory=logs prefix=localhost_access_log. suffix=.txt pattern=%h %l %u %t quot;%rquot; %s %b / /Host Host name=nilfisk-alto debug=0 appBase=webapps/nilfisk-alto unpackWARs=true Aliasnilfisk-alto.datagraf.dk/Alias Logger className=org.apache.catalina.logger.FileLogger directory=logs prefix=virtual_nilfisk-alto. suffix=.log timestamp=true/ /Host snip/ The problem is that you have overlapping appBase settings between virtual hosts. The simplest solution is to change the appBase for localhost to webapps/localhost and move any web applications in webapps into webapps/localhost. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
[SECURITY] CVE-2014-0075 Apache Tomcat denial of service
CVE-2014-0075 Denial of Service Severity: Important Vendor: The Apache Software Foundation Versions Affected: - Apache Tomcat 8.0.0-RC1 to 8.0.3 - Apache Tomcat 7.0.0 to 7.0.52 - Apache Tomcat 6.0.0 to 6.0.39 Description: It was possible to craft a malformed chunk size as part of a chucked request that enabled an unlimited amount of data to be streamed to the server, bypassing the various size limits enforced on a request. This enabled a denial of service attack. Mitigation: Users of affected versions should apply one of the following mitigations - Upgrade to Apache Tomcat 8.0.5 or later (8.0.4 contains the fix but was not released) - Upgrade to Apache Tomcat 7.0.53 or later - Upgrade to Apache Tomcat 6.0.41 or later (6.0.40 contains the fix but was not released) Credit: This issue was reported to the Tomcat security team by David Jorm of the Red Hat Security Response Team. References: [1] http://tomcat.apache.org/security-8.html [2] http://tomcat.apache.org/security-7.html [3] 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-2014-0095 Apache Tomcat denial of service
CVE-2014-0095 Denial of Service Severity: Important Vendor: The Apache Software Foundation Versions Affected: - Apache Tomcat 8.0.0-RC2 to 8.0.3 Description: A regression was introduced in revision 1519838 that caused AJP requests to hang if an explicit content length of zero was set on the request. The hanging request consumed a request processing thread which could lead to a denial of service. Mitigation: Users of affected versions should apply one of the following mitigations - Upgrade to Apache Tomcat 8.0.5 or later (8.0.4 contains the fix but was not released) Credit: This issue was reported as a possible bug via the Tomcat users mailing list and the security implications were identified by theTomcat security team. References: [1] 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-2014-0119 Apache Tomcat information disclosure
CVE-2014-0119 Information Disclosure Severity: Important Vendor: The Apache Software Foundation Versions Affected: - Apache Tomcat 8.0.0-RC1 to 8.0.5 - Apache Tomcat 7.0.0 to 7.0.53 - Apache Tomcat 6.0.0 to 6.0.39 Description: In limited circumstances it was possible for a malicious web application to replace the XML parsers used by Tomcat to process XSLTs for the default servlet, JSP documents, tag library descriptors (TLDs) and tag plugin configuration files. The injected XMl parser(s) could then bypass the limits imposed on XML external entities and/or have visibility of the XML files processed for other web applications deployed on the same Tomcat instance. Mitigation: Users of affected versions should apply one of the following mitigations - Upgrade to Apache Tomcat 8.0.8 or later (8.0.6 and 8.0.7 contain the fix but were not released) - Upgrade to Apache Tomcat 7.0.54 or later - Upgrade to Apache Tomcat 6.0.41 or later (6.0.40 contains the fix but was not released) Credit: This issue was identified by the Tomcat security team. References: [1] http://tomcat.apache.org/security-8.html [2] http://tomcat.apache.org/security-7.html [3] 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-2014-0096 Apache Tomcat information disclosure
CVE-2014-0096 Information Disclosure Severity: Important Vendor: The Apache Software Foundation Versions Affected: - Apache Tomcat 8.0.0-RC1 to 8.0.3 - Apache Tomcat 7.0.0 to 7.0.52 - Apache Tomcat 6.0.0 to 6.0.39 Description: The default servlet allows web applications to define (at multiple levels) an XSLT to be used to format a directory listing. When running under a security manager, the processing of these was not subject to the same constraints as the web application. This enabled a malicious web application to bypass the file access constraints imposed by the security manager via the use of external XML entities. Mitigation: Users of affected versions should apply one of the following mitigations - Upgrade to Apache Tomcat 8.0.5 or later (8.0.4 contains the fix but was not released) - Upgrade to Apache Tomcat 7.0.53 or later - Upgrade to Apache Tomcat 6.0.41 or later (6.0.40 contains the fix but was not released) Credit: This issue was identified by the Tomcat security team. References: [1] http://tomcat.apache.org/security-8.html [2] http://tomcat.apache.org/security-7.html [3] 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-2014-0097 Apache Tomcat information disclosure
CVE-2014-0097 Information Disclosure Severity: Important Vendor: The Apache Software Foundation Versions Affected: - Apache Tomcat 8.0.0-RC1 to 8.0.3 - Apache Tomcat 7.0.0 to 7.0.52 - Apache Tomcat 6.0.0 to 6.0.39 Description: The code used to parse the request content length header did not check for overflow in the result. This exposed a request smuggling vulnerability when Tomcat was located behind a reverse proxy that correctly processed the content length header. Mitigation: Users of affected versions should apply one of the following mitigations - Upgrade to Apache Tomcat 8.0.5 or later (8.0.4 contains the fix but was not released) - Upgrade to Apache Tomcat 7.0.53 or later - Upgrade to Apache Tomcat 6.0.41 or later (6.0.40 contains the fix but was not released) Credit: A test case that demonstrated the parsing bug was sent to the Tomcat security team but no context was provided. The security implications were identified by the Tomcat security team . References: [1] http://tomcat.apache.org/security-8.html [2] http://tomcat.apache.org/security-7.html [3] 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
Re: [SECURITY] CVE-2014-0097 Apache Tomcat information disclosure
Mark Thomas wrote: CVE-2014-0097 Information Disclosure ... Description: The code used to parse the request content length header did not check for overflow in the result. This exposed a request smuggling vulnerability when Tomcat was located behind a reverse proxy that correctly processed the content length header. I believe you, but I must admit that I don't really get what the problem is, here. If someone feels like explaining.. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: [SECURITY] CVE-2014-0099 Apache Tomcat information disclosure
CORRECTION: This is CVE-2014-0099 *NOT* -0097 Apologies for the typo On 27/05/2014 13:46, Mark Thomas wrote: CVE-2014-0099 Information Disclosure Severity: Important Vendor: The Apache Software Foundation Versions Affected: - Apache Tomcat 8.0.0-RC1 to 8.0.3 - Apache Tomcat 7.0.0 to 7.0.52 - Apache Tomcat 6.0.0 to 6.0.39 Description: The code used to parse the request content length header did not check for overflow in the result. This exposed a request smuggling vulnerability when Tomcat was located behind a reverse proxy that correctly processed the content length header. Mitigation: Users of affected versions should apply one of the following mitigations - Upgrade to Apache Tomcat 8.0.5 or later (8.0.4 contains the fix but was not released) - Upgrade to Apache Tomcat 7.0.53 or later - Upgrade to Apache Tomcat 6.0.41 or later (6.0.40 contains the fix but was not released) Credit: A test case that demonstrated the parsing bug was sent to the Tomcat security team but no context was provided. The security implications were identified by the Tomcat security team . References: [1] http://tomcat.apache.org/security-8.html [2] http://tomcat.apache.org/security-7.html [3] http://tomcat.apache.org/security-6.html - To unsubscribe, e-mail: security-unsubscr...@tomcat.apache.org For additional commands, e-mail: security-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-2014-0099 Apache Tomcat information disclosure
On 27/05/2014 14:05, André Warnier wrote: Mark Thomas wrote: CVE-2014-0099 Information Disclosure ... Description: The code used to parse the request content length header did not check for overflow in the result. This exposed a request smuggling vulnerability when Tomcat was located behind a reverse proxy that correctly processed the content length header. I believe you, but I must admit that I don't really get what the problem is, here. Sure. First of all exploiting this is not easy. The problem occurs when the content-length overflows during parsing. Tomcat ends up with a lower value for the content length than is really the case. Tomcat will, therefore, read the first part of the request (up to the length it thinks it is) and process it. Assuming keep-alive is being used, Tomcat will then process the remainder of the request as a new request and generate a response for that. Things get messy when there is a reverse proxy in the mix that correctly processes the content length. What ends up happening is this. User A sends request A to proxy. Proxy sends request A to Tomcat. Tomcat process the first part of request A and sends response A1 to the proxy. The proxy sends response A1 to user A. User B sends request B to proxy. Proxy sends request B to Tomcat (using the same connection as for request A) Tomcat processes the remainder of request A and sends response A2 to the proxy Proxy sends response A2 to user B. And you end up with all future responses on that connection going to the wrong user until (which will probably happen fairly soon) Tomcat or the proxy get to a point they realise something is wrong and close the connection. How much deliberate, targeted harm you can do depends a lot on the application. It is certainly easy to trigger response mix-up and - for example on a banking site - that would be bad even if that was all you could do. HTH, Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: [SECURITY] CVE-2014-0099 Apache Tomcat information disclosure
Mark Thomas wrote: On 27/05/2014 14:05, André Warnier wrote: Mark Thomas wrote: CVE-2014-0099 Information Disclosure ... Description: The code used to parse the request content length header did not check for overflow in the result. This exposed a request smuggling vulnerability when Tomcat was located behind a reverse proxy that correctly processed the content length header. I believe you, but I must admit that I don't really get what the problem is, here. Sure. First of all exploiting this is not easy. The problem occurs when the content-length overflows during parsing. Tomcat ends up with a lower value for the content length than is really the case. Tomcat will, therefore, read the first part of the request (up to the length it thinks it is) and process it. Assuming keep-alive is being used, Tomcat will then process the remainder of the request as a new request and generate a response for that. Things get messy when there is a reverse proxy in the mix that correctly processes the content length. What ends up happening is this. User A sends request A to proxy. Proxy sends request A to Tomcat. Tomcat process the first part of request A and sends response A1 to the proxy. The proxy sends response A1 to user A. User B sends request B to proxy. Proxy sends request B to Tomcat (using the same connection as for request A) Tomcat processes the remainder of request A and sends response A2 to the proxy Proxy sends response A2 to user B. And you end up with all future responses on that connection going to the wrong user until (which will probably happen fairly soon) Tomcat or the proxy get to a point they realise something is wrong and close the connection. How much deliberate, targeted harm you can do depends a lot on the application. It is certainly easy to trigger response mix-up and - for example on a banking site - that would be bad even if that was all you could do. Thank you for the limpid explanation. Yes, difficult to take advantage of, but certainly confusing for user B, to get something he didn't ask for.. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: [SECURITY] CVE-2014-0097 Apache Tomcat information disclosure
Hi André,
-Original Message-
From: André Warnier [mailto:a...@ice-sa.com]
Sent: Tuesday, May 27, 2014 3:06 PM
Mark Thomas wrote:
CVE-2014-0097 Information Disclosure
...
Description:
The code used to parse the request content length header did not check
for overflow in the result. This exposed a request smuggling
vulnerability when Tomcat was located behind a reverse proxy that
correctly processed the content length header.
I believe you, but I must admit that I don't really get what the problem is,
here.
If someone feels like explaining..
The fix for this issue also made me a bit curious (I don't know the background
of the issue).
The old code for parsing the Content-Length header looked like this:
long n = c - '0';
long m;
while (--len 0) {
if (!isDigit(c = b[off++])) {
throw new NumberFormatException();
}
m = n * 10 + c - '0';
if (m n) {
// Overflow
throw new NumberFormatException();
} else {
n = m;
}
}
Where b is a byte-array containing ASCII decimal chars.
The code parses a decimal number like 123 by multiplying the current number
(e.g. 12) by 10 (=120), then adding the next character (=123).
To check for an overflow, it checks if the new number is lower than the old
one. Usually, when making a simple addition with positive numbers where the
second one is low (0-9), this is enough as for an overflow, the first bit will
go to 1, so the number is negative. E.g., when using signed bytes (8 bits):
011b (127) + 3 = 1010b (-126)
However, the code above also does an multiplication by 10. For example, if the
current number (signed long) is 6148914691236517205 (binary:
101010101010101010101010101010101010101010101010101010101010101b) and the next
character is '3', the calculation would be:
101010101010101010101010101010101010101010101010101010101010101b
(6148914691236517205) * 1010b (10) =
101010101010101010101010101010101010101010101010101010101010010b
(6148914691236517202)
101010101010101010101010101010101010101010101010101010101010010b
(6148914691236517202) + 11b (3) =
101010101010101010101010101010101010101010101010101010101010101b
(6148914691236517205)
In this case, the new number would == the old number, so the code if (m n)
would not detect the overflow.
E.g., if you run following code:
long a = 6148914691236517205L;
long b = a * 10 + 3;
System.out.println(a == b);
it will print true.
However, I don't know if such example is really the one that causes issues, as
this number is pretty high (but I did not found how smaller numbers could cause
overflows not to be detected). Maybe someone could comment on that.
Thanks!
Regards,
Konstantin Preißer
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Re: [SECURITY] CVE-2014-0099 Apache Tomcat information disclosure
On 27/05/2014 15:12, Konstantin Preißer wrote:
Hi André,
-Original Message-
From: André Warnier [mailto:a...@ice-sa.com]
Sent: Tuesday, May 27, 2014 3:06 PM
Mark Thomas wrote:
CVE-2014-0099 Information Disclosure
...
Description:
The code used to parse the request content length header did not check
for overflow in the result. This exposed a request smuggling
vulnerability when Tomcat was located behind a reverse proxy that
correctly processed the content length header.
I believe you, but I must admit that I don't really get what the problem is,
here.
If someone feels like explaining..
The fix for this issue also made me a bit curious (I don't know the
background of the issue).
The old code for parsing the Content-Length header looked like this:
long n = c - '0';
long m;
while (--len 0) {
if (!isDigit(c = b[off++])) {
throw new NumberFormatException();
}
m = n * 10 + c - '0';
if (m n) {
// Overflow
throw new NumberFormatException();
} else {
n = m;
}
}
Where b is a byte-array containing ASCII decimal chars.
The code parses a decimal number like 123 by multiplying the current number
(e.g. 12) by 10 (=120), then adding the next character (=123).
To check for an overflow, it checks if the new number is lower than the old
one. Usually, when making a simple addition with positive numbers where the
second one is low (0-9), this is enough as for an overflow, the first bit
will go to 1, so the number is negative. E.g., when using signed bytes (8
bits):
011b (127) + 3 = 1010b (-126)
However, the code above also does an multiplication by 10. For example, if
the current number (signed long) is 6148914691236517205 (binary:
101010101010101010101010101010101010101010101010101010101010101b) and the
next character is '3', the calculation would be:
101010101010101010101010101010101010101010101010101010101010101b
(6148914691236517205) * 1010b (10) =
101010101010101010101010101010101010101010101010101010101010010b
(6148914691236517202)
101010101010101010101010101010101010101010101010101010101010010b
(6148914691236517202) + 11b (3) =
101010101010101010101010101010101010101010101010101010101010101b
(6148914691236517205)
In this case, the new number would == the old number, so the code if (m
n) would not detect the overflow.
E.g., if you run following code:
long a = 6148914691236517205L;
long b = a * 10 + 3;
System.out.println(a == b);
it will print true.
However, I don't know if such example is really the one that causes issues,
as this number is pretty high (but I did not found how smaller numbers could
cause overflows not to be detected). Maybe someone could comment on that.
Yes, you need to have a content-length above Long.MAX_VALUE for problems
to occur. That would be unusual to say the least for most (all?)
applications in normal usage but easy for a malicious user to set.
If the proxy handles the header correctly, the attacker is going to have
to send a *lot* of data to get this to work. Where things would get
interesting is if the proxy and Tomcat both had parsing issues but ended
up with different values. That would make request smuggling a lot easier.
Something else to consider. If an attacker can trigger this
request/response offset then any subsequent requests they make could
receive responses that contain data from other users. Even if they can't
control what that data is, that is still information disclosure.
Mark
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
RE: [SECURITY] CVE-2014-0099 Apache Tomcat information disclosure
Hi Mark, -Original Message- From: Mark Thomas [mailto:ma...@apache.org] Sent: Tuesday, May 27, 2014 4:33 PM snip Yes, you need to have a content-length above Long.MAX_VALUE for problems to occur. That would be unusual to say the least for most (all?) applications in normal usage but easy for a malicious user to set. If the proxy handles the header correctly, the attacker is going to have to send a *lot* of data to get this to work. Where things would get interesting is if the proxy and Tomcat both had parsing issues but ended up with different values. That would make request smuggling a lot easier. Something else to consider. If an attacker can trigger this request/response offset then any subsequent requests they make could receive responses that contain data from other users. Even if they can't control what that data is, that is still information disclosure. OK, thanks for the clarification! Regards, Konstantin Preißer - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: [SECURITY] CVE-2014-0099 Apache Tomcat information disclosure
Mark Thomas wrote:
On 27/05/2014 15:12, Konstantin Preißer wrote:
Hi André,
-Original Message-
From: André Warnier [mailto:a...@ice-sa.com]
Sent: Tuesday, May 27, 2014 3:06 PM
Mark Thomas wrote:
CVE-2014-0099 Information Disclosure
...
Description:
The code used to parse the request content length header did not check
for overflow in the result. This exposed a request smuggling
vulnerability when Tomcat was located behind a reverse proxy that
correctly processed the content length header.
I believe you, but I must admit that I don't really get what the problem is,
here.
If someone feels like explaining..
The fix for this issue also made me a bit curious (I don't know the background
of the issue).
The old code for parsing the Content-Length header looked like this:
long n = c - '0';
long m;
while (--len 0) {
if (!isDigit(c = b[off++])) {
throw new NumberFormatException();
}
m = n * 10 + c - '0';
if (m n) {
// Overflow
throw new NumberFormatException();
} else {
n = m;
}
}
Where b is a byte-array containing ASCII decimal chars.
The code parses a decimal number like 123 by multiplying the current number
(e.g. 12) by 10 (=120), then adding the next character (=123).
To check for an overflow, it checks if the new number is lower than the old
one. Usually, when making a simple addition with positive numbers where the second one is
low (0-9), this is enough as for an overflow, the first bit will go to 1, so the number
is negative. E.g., when using signed bytes (8 bits):
011b (127) + 3 = 1010b (-126)
However, the code above also does an multiplication by 10. For example, if the
current number (signed long) is 6148914691236517205 (binary:
101010101010101010101010101010101010101010101010101010101010101b) and the next
character is '3', the calculation would be:
101010101010101010101010101010101010101010101010101010101010101b (6148914691236517205) * 1010b (10) =
101010101010101010101010101010101010101010101010101010101010010b (6148914691236517202)
101010101010101010101010101010101010101010101010101010101010010b
(6148914691236517202) + 11b (3) =
101010101010101010101010101010101010101010101010101010101010101b
(6148914691236517205)
In this case, the new number would == the old number, so the code if (m n)
would not detect the overflow.
E.g., if you run following code:
long a = 6148914691236517205L;
long b = a * 10 + 3;
System.out.println(a == b);
it will print true.
However, I don't know if such example is really the one that causes issues, as
this number is pretty high (but I did not found how smaller numbers could cause
overflows not to be detected). Maybe someone could comment on that.
Yes, you need to have a content-length above Long.MAX_VALUE for problems
to occur. That would be unusual to say the least for most (all?)
applications in normal usage but easy for a malicious user to set.
If the proxy handles the header correctly, the attacker is going to have
to send a *lot* of data to get this to work. Where things would get
interesting is if the proxy and Tomcat both had parsing issues but ended
up with different values. That would make request smuggling a lot easier.
Something else to consider. If an attacker can trigger this
request/response offset then any subsequent requests they make could
receive responses that contain data from other users. Even if they can't
control what that data is, that is still information disclosure.
Just for the sake of it, I don't really see how that last scenario could come to pass
though. Let's say that user A sends such a malicious request to the front-end, and the
front-end interprets it correctly as one request, and passes it on to tomcat over a
connector connection. Then Tomcat misinterprets this as being several requests in a row,
and distributes them to several threads, to process and return responses, onto that same
connector connection. And then, the first Tomcat thread to be finished, would return a
response to the first part of that request. And then the front-end would think that this
is the response to the original request, return it to the first (malicious) user, and that
would be that for this request (for the front-end).
If in the meantime the front-end receives another request, and it could (at the end of the
first request) send this other request to Tomcat, using the same connection.
And then the front-end may receive the response to Tomcat's second request (which in
fact was a second part of the first), but it would think that it was the response to the
second request, and forward it to the wrong user.
So now the 2 systems are out of sync. Tomcat keeps on processing parts of the first
malicious request as being separate requests, and the responses to such requests are being
sent back as
Re: Tomcat 7 cannot get ciphers with SHA256 or SHA384
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Tim, On 5/26/14, 5:43 PM, Tim Whittington wrote: On 27/05/2014, at 6:09 am, Christopher Schultz ch...@christopherschultz.net wrote: snip If you run the code I referenced elsewhere in this thread, you'll see that some of the components are available, just not in the combinations you have above: $ java -showversion -classpath build/ SSLInfo | grep '\(256\|384\)' java version 1.7.0_55 Java(TM) SE Runtime Environment (build 1.7.0_55-b13) Java HotSpot(TM) 64-Bit Server VM (build 24.55-b03, mixed mode) Supported SSL Protocols: TLSv1 (SunJSSE) TLSv1.1 (SunJSSE) TLSv1.2 (SunJSSE) DefaultCipher Name * TLS_DHE_DSS_WITH_AES_128_CBC_SHA256 * TLS_DHE_RSA_WITH_AES_128_CBC_SHA256 TLS_DH_anon_WITH_AES_128_CBC_SHA256 * TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256 * TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 * TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA256 * TLS_ECDH_RSA_WITH_AES_128_CBC_SHA256 * TLS_RSA_WITH_AES_128_CBC_SHA256 TLS_RSA_WITH_NULL_SHA256 So, you can get ECDHE_(ECDSA|RSA)_AES, but not with a 256-bit cipher. You can get a 128-bit cipher and a 256-bit hash, but not higher-bit hash functions. Oracle Java 7 has no GCM support (AIX does I think, but from memory the cipher suite names are different), and some of the cipher-suites don’t exist (see below). GCM was originally targeted for JDK 7 (which is why the cipher suite names and AEAD APIs in the JCE are there) but the implementation didn’t show up until JDK 8. I find no ciphers with 384-bit hashes in Oracle Java 8, but there are 256-bit ones -- at least in the Mac OS X build: Do you have the unrestricted crypto policy files installed? I have never hacked my own Java installation, so likely no. Without those, 128 bit security ciphers (== 256 bit hashes) are suppressed. Hmm. I'll look into that. Yep, installing the updated policy files unlocks a bunch of additional ciphers. Thanks! Cipher suites with SHA384 are definitely available on both JDK 7 and JDK 8 on OS X. Yeah, I saw those listed on Sun's site, but figured that they were just lies or something :) That's why I always Trust But Verify. If the code won't do it, the documentation's assertion that it /will/ do it is kind of irrelevant. I’m using the interactive mode of https://github.com/timw/groktls to dump these. Cool. I was just using the SSLInfo class and grep, obviously :) I've been thinking that the way Tomcat does JSSE cipher suites is a bit ... verbose. It would be nice to roll something like what groktls/OpenSSL can do into Tomcat. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCAAGBQJThLGCAAoJEBzwKT+lPKRYEnEQAJUV4pgN8ozx6Sivbm0c+TEh fodo5X7NDQMoNDfdPQoPugibcEbnxDEtfcgj1LPTwEviOUFg47BoVbl8W0i4uvGS JBUW/9strJNZ9nqZ3goLjWwgxMn5NY5tJMziooRFRoLCXxFVp3+3E0uO0l7getzI TUAsBbaAyrYwMTFlHMaP8HcGTOJeixRqQpXwHqMp88UukylT9uu5/cb4khMgmea4 lFlQx2ZII2FAUR3fHgVLSl9C9PddhYC2Y5QvNi9YLBlXNlrXXk88yZzVXkmDdEF0 7MNrLKHaE3hZrhdJK/HXkZc6EnQ7VXezQ4ARSBidOvBZZnYcnZ6Z+7mSkyHQCpPo KmwaF6Szm6nxT2h0PNrlziFhKJ9JHdD7Gbhi/tabeM7ffn91GkU1Atsqq0NGE4JF bcqHHSa3+xW2B/dSCcYQc+Ec7ZRoJumkM//U3xd+iXTPis2L/vPVRveDDGtMavVu 1pU41Q3GlJhwu9pwJ1RnLWm9kMLEbLUFuzUBPK9rkzTt45fudLVXFGpdGH+izPgb X8E7v2X1z+kVaaR9HWMCgiHyZjEoVCXLnJaBfBYmMSNc3bJoEPCrMpXSyzPCH7cJ RclVEw4sOh5ZyK+UsdkPeYW1Ft01UJ3nvczpYM7OxgwDJhdpo/E3glv0BihAC7ax kbk5g4EG77rZ7c9s1CEf =xJ/g -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
SSL on one subdirectory only.
Tomcat 7.0.42, RHEL6, JDK1.7.0_25, Standalone TC configuration. IPTABLES route port 80 to 8080 I've got a subdirectory like 'www.mysite.com/admin' that I want to put under FORM based authentication. That's clear enough, and I've got the java keytool cert working well enough on my dev box until I get one from a CA. Couple of questions: 1. Anyone familiar with any problems routing 443 to 8443 on *nix boxes for TC SSL certs? It's preferable to not have my end users needing port numbers. The cert doesn't care about the port, IIRC. 2. With the SSL connector enabled, https://* is globally respected on the entire webapp. Do I need to manually check the URL/protocol to deny or redirect https to http outside of '/admin'? Is there any built in TC mechanism or suggested best practice to handle this? or should I not care? Best, John
Re: SSL on one subdirectory only.
On 27/05/2014 17:31, John Smith wrote: Tomcat 7.0.42, RHEL6, JDK1.7.0_25, Standalone TC configuration. IPTABLES route port 80 to 8080 I've got a subdirectory like 'www.mysite.com/admin' that I want to put under FORM based authentication. That's clear enough, and I've got the java keytool cert working well enough on my dev box until I get one from a CA. Couple of questions: 1. Anyone familiar with any problems routing 443 to 8443 on *nix boxes for TC SSL certs? It's preferable to not have my end users needing port numbers. The cert doesn't care about the port, IIRC. Should be fine. 2. With the SSL connector enabled, https://* is globally respected on the entire webapp. Do I need to manually check the URL/protocol to deny or redirect https to http outside of '/admin'? Is there any built in TC mechanism or suggested best practice to handle this? or should I not care? Nothing to automatically handle https - http. Unless it causes an issue, I'd just leave it. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: [SECURITY] CVE-2014-0099 Apache Tomcat information disclosure
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 André, On 5/27/14, 10:03 AM, André Warnier wrote: Mark Thomas wrote: On 27/05/2014 14:05, André Warnier wrote: Mark Thomas wrote: CVE-2014-0099 Information Disclosure ... Description: The code used to parse the request content length header did not check for overflow in the result. This exposed a request smuggling vulnerability when Tomcat was located behind a reverse proxy that correctly processed the content length header. I believe you, but I must admit that I don't really get what the problem is, here. Sure. First of all exploiting this is not easy. The problem occurs when the content-length overflows during parsing. Tomcat ends up with a lower value for the content length than is really the case. Tomcat will, therefore, read the first part of the request (up to the length it thinks it is) and process it. Assuming keep-alive is being used, Tomcat will then process the remainder of the request as a new request and generate a response for that. Things get messy when there is a reverse proxy in the mix that correctly processes the content length. What ends up happening is this. User A sends request A to proxy. Proxy sends request A to Tomcat. Tomcat process the first part of request A and sends response A1 to the proxy. The proxy sends response A1 to user A. User B sends request B to proxy. Proxy sends request B to Tomcat (using the same connection as for request A) Tomcat processes the remainder of request A and sends response A2 to the proxy Proxy sends response A2 to user B. And you end up with all future responses on that connection going to the wrong user until (which will probably happen fairly soon) Tomcat or the proxy get to a point they realise something is wrong and close the connection. How much deliberate, targeted harm you can do depends a lot on the application. It is certainly easy to trigger response mix-up and - for example on a banking site - that would be bad even if that was all you could do. Thank you for the limpid explanation. Yes, difficult to take advantage of, but certainly confusing for user B, to get something he didn't ask for.. Some of my best English vocabulary comes from Belgians. And waffles. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCAAGBQJThNhhAAoJEBzwKT+lPKRY7pgP/iXdPHcHbUfB33CcR3cwtXsQ d6poIuOtPWzNqPJrfGvu20A2L5TRtw9AHx8TQCL6tGY3BuDOgKSOxEbtWGr0E8Gq b1ipr8oc6ZrFvffiHfgew1QPLY4/FJC7rSjf/koV6iRsYLciGmN/DxRlmbsgqUj2 uYQtv6PhYTKOwijQ/rGxb3GjmqMP5yiXTz3YAkWb/2adHg3+luXNNxpr0Ar1snFY OZLipS6YTmyQQl5QFgATuK4KbWQ2XcgRmtM8ldbKMWO2DMbyEGWOq3zzC8pVIJ+x WdsOebnj2nGaXxewi5RtJ6M/HiJdE4mIv6vT5E9O0TJJFwgl+l5i30AkSSGyr3CM t5oZQ76Zu8TrHXev7WDOBrAAuxacngbafxVbKimBpJcXnoeh07yOThXug71TReAx oUncKGvCHYG7rGMYOJ2Cshs+IhhqJCTRiff6InzkFKSl1E+FKM+iVoZXGv0JP8KP zPe18lWjbKTMd68x24HFNrylyVPEbc2MyG4cUJQ5Dw+r9NCKxzha/K+yxh6gAPQl KAiHyXeJfkGmr7uD4bhyywcjWi05QKLZkyQlvhanQ1N3442luJSj+KLTkybPA0Nx FZBlGdYF9ZGWNiK1qkvvwZqH/TKFxNOzl0yaAF7It7rnEsCKJs8DDX/QK5QuaUAX SBZqArXqomy3tWJ29VnI =fZQ0 -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: SSL on one subdirectory only.
27.05.2014 19:31, John Smith пишет: 1. Anyone familiar with any problems routing 443 to 8443 on *nix boxes for TC SSL certs? It's preferable to not have my end users needing port numbers. The cert doesn't care about the port, IIRC. Try check trafic with ssldump http://www.rtfm.com/ssldump/ 2. With the SSL connector enabled, https://* is globally respected on the entire webapp. Do I need to manually check the URL/protocol to deny or redirect https to http outside of '/admin'? Is there any built in TC mechanism or suggested best practice to handle this? or should I not care? We use two-factor authentification with SSL - but I think in your case this can be helpful too - not a big difference. Try look at this: http://wiki.metawerx.net/wiki/ForcingSSLForSectionsOfYourWebsite Best, John Arseny. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: [SECURITY] CVE-2014-0099 Apache Tomcat information disclosure
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Mark,
On 5/27/14, 10:32 AM, Mark Thomas wrote:
On 27/05/2014 15:12, Konstantin Preißer wrote:
Hi André,
-Original Message- From: André Warnier
[mailto:a...@ice-sa.com] Sent: Tuesday, May 27, 2014 3:06 PM
Mark Thomas wrote:
CVE-2014-0099 Information Disclosure
...
Description: The code used to parse the request content
length header did not check for overflow in the result. This
exposed a request smuggling vulnerability when Tomcat was
located behind a reverse proxy that correctly processed the
content length header.
I believe you, but I must admit that I don't really get what
the problem is, here. If someone feels like explaining..
The fix for this issue also made me a bit curious (I don't know
the background of the issue).
The old code for parsing the Content-Length header looked like
this:
long n = c - '0'; long m;
while (--len 0) { if (!isDigit(c = b[off++])) { throw new
NumberFormatException(); } m = n * 10 + c - '0';
if (m n) { // Overflow throw new NumberFormatException(); }
else { n = m; } }
Where b is a byte-array containing ASCII decimal chars.
The code parses a decimal number like 123 by multiplying the
current number (e.g. 12) by 10 (=120), then adding the next
character (=123).
To check for an overflow, it checks if the new number is lower
than the old one. Usually, when making a simple addition with
positive numbers where the second one is low (0-9), this is
enough as for an overflow, the first bit will go to 1, so the
number is negative. E.g., when using signed bytes (8 bits):
011b (127) + 3 = 1010b (-126)
However, the code above also does an multiplication by 10. For
example, if the current number (signed long) is
6148914691236517205 (binary:
101010101010101010101010101010101010101010101010101010101010101b)
and the next character is '3', the calculation would be:
101010101010101010101010101010101010101010101010101010101010101b
(6148914691236517205) * 1010b (10) =
101010101010101010101010101010101010101010101010101010101010010b
(6148914691236517202)
101010101010101010101010101010101010101010101010101010101010010b
(6148914691236517202) + 11b (3) =
101010101010101010101010101010101010101010101010101010101010101b
(6148914691236517205)
In this case, the new number would == the old number, so the code
if (m n) would not detect the overflow.
E.g., if you run following code:
long a = 6148914691236517205L; long b = a * 10 + 3;
System.out.println(a == b);
it will print true.
However, I don't know if such example is really the one that
causes issues, as this number is pretty high (but I did not found
how smaller numbers could cause overflows not to be detected).
Maybe someone could comment on that.
Yes, you need to have a content-length above Long.MAX_VALUE for
problems to occur. That would be unusual to say the least for most
(all?) applications in normal usage but easy for a malicious user
to set.
If the proxy handles the header correctly, the attacker is going to
have to send a *lot* of data to get this to work. Where things
would get interesting is if the proxy and Tomcat both had parsing
issues but ended up with different values. That would make request
smuggling a lot easier.
Something else to consider. If an attacker can trigger this
request/response offset then any subsequent requests they make
could receive responses that contain data from other users. Even if
they can't control what that data is, that is still information
disclosure.
It's worth pointing out that one of the mitigations of this
vulnerability is to configure the proxy to reject very large values
for Content-Length.
For instance, we don't expect any file uploads, etc. larger than a few
MB. So for httpd, we could do something like this:
SetEnvIf Content-Type .{10,} no-jk=1
This will refuse to send any requests via mod_jk if they have
Content-Type headers whose values are 10 or more characters. We do the
same thing for Accept-Language for a bug that has been long-since
fixed I think.
It's probably worth publishing that mitigation since it's easier to do
than upgrading Tomcat if it's an emergency.
- -chris
-BEGIN PGP SIGNATURE-
Version: GnuPG v1
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQIcBAEBCAAGBQJThNtUAAoJEBzwKT+lPKRY75AP/iyC/mb1S+JgVkcWid/Xqsn5
RfSPLMmT5G+yVSBiWRa9P8Rp3Tg1FE63aQtr0ybLCwh/ds4RXapbkNQATyXeAwgf
viwLpE7iuzS4SQs18zSh60jaEdKJh9MrCrc2YL5gTq2crcJMz9s8PKOmtZQ/kY1e
T71BlvPef5GHkzjWMfVEodMubtOWnp346COeFtDdJpi8zzJ3/Zh9YBLBAXW+aqNh
8qxq0SEZchrgiFmfuP83A59JOzHm8xz3QOf2SjHEitYE5kOo3t+zyTIOZRAlh0Ka
poegWmpEKd94/GiyxkH5OfbqwDjFdg8tb/acm+4PX6aZiXyx5K3Ri4pIji64llEw
jJCx6RSNgAkgjt8206TGV09tkCrtym7sACyQ6afl8kQQlPWVPitzpk/4ITzwtoRR
WieZc4yAsp03sT85Ti3xwUstvhANcHXn0ltc6JNH3mvOHfLnTScKoJA7s6nLyDuN
Re: [SECURITY] CVE-2014-0097 Apache Tomcat information disclosure
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Konstantin,
On 5/27/14, 10:12 AM, Konstantin Preißer wrote:
Hi André,
-Original Message- From: André Warnier
[mailto:a...@ice-sa.com] Sent: Tuesday, May 27, 2014 3:06 PM
Mark Thomas wrote:
CVE-2014-0097 Information Disclosure
...
Description: The code used to parse the request content length
header did not check for overflow in the result. This exposed a
request smuggling vulnerability when Tomcat was located behind
a reverse proxy that correctly processed the content length
header.
I believe you, but I must admit that I don't really get what the
problem is, here. If someone feels like explaining..
The fix for this issue also made me a bit curious (I don't know the
background of the issue).
The old code for parsing the Content-Length header looked like
this:
long n = c - '0'; long m;
while (--len 0) { if (!isDigit(c = b[off++])) { throw new
NumberFormatException(); } m = n * 10 + c - '0';
if (m n) { // Overflow throw new NumberFormatException(); } else
{ n = m; } }
Where b is a byte-array containing ASCII decimal chars.
The code parses a decimal number like 123 by multiplying the
current number (e.g. 12) by 10 (=120), then adding the next
character (=123).
To check for an overflow, it checks if the new number is lower
than the old one. Usually, when making a simple addition with
positive numbers where the second one is low (0-9), this is enough
as for an overflow, the first bit will go to 1, so the number is
negative. E.g., when using signed bytes (8 bits): 011b (127) +
3 = 1010b (-126)
However, the code above also does an multiplication by 10. For
example, if the current number (signed long) is 6148914691236517205
(binary:
101010101010101010101010101010101010101010101010101010101010101b)
and the next character is '3', the calculation would be:
101010101010101010101010101010101010101010101010101010101010101b
(6148914691236517205) * 1010b (10) =
101010101010101010101010101010101010101010101010101010101010010b
(6148914691236517202)
Honestly, I was dumbfounded to see this in action. I've never studied
signed multiplication before. I'll have to read a lot more about this.
101010101010101010101010101010101010101010101010101010101010010b
(6148914691236517202) + 11b (3) =
101010101010101010101010101010101010101010101010101010101010101b
(6148914691236517205)
In this case, the new number would == the old number, so the code
if (m n) would not detect the overflow.
Crazy.
- -chris
-BEGIN PGP SIGNATURE-
Version: GnuPG v1
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQIcBAEBCAAGBQJThNvAAAoJEBzwKT+lPKRYr5gP/RBQRQ2ghYSjX7GIwOpRB20R
OGMfB7ACPfsXgp/V2syqLkNSiou0xKZvdffxkD4H90wmlTvWB9PZ7ZH6q87d6hZi
6Uq2CITabYVG9aMHeVcQ7ZUOIelGJkFCwRd9c1TtuYeuNeDZ+eGGSeU/ji9AVP/S
+f0/5+EnqsWgnAcdJ7FRzN1x6cBd80x9YqCY0hVkpgzeEjdTe++DaK10TWWVAPDb
Uk+cGKmdkAivsNiyqQmHvM7chR4UZwbefyH/gHDLdISbNThq2Gg64dPVPqjBydoS
2eEYv4DFbSwdBijQseWEEi014EO6m54kymYzV4wlnYwsdntMrZIPDMrkkrGqpn8Z
S8miQ0ezGV6HI1n/iMtlAX4uCG4BPxg2xdsDlrSl/riBBgwqhiqi3BFBM0qmDdFv
1hUSnoMJAiQfcldWqR/1BTj0t7GC7EmP+j1Pb2gA/8GhCj2AMx4eWgf2gz6voDB/
lTG8XmvEZJZHevT+LoKv+tTPqT20U0i5ltkI2VSUdO6u1TBZUh9ofkdheRLPVWeN
D00UAFBdPQfTa2JfC8QXNFY+vEyyFmQYcZRqnEZEZU2C3pPCzoGt/+MrndsZAwjS
nb9LjiJPflYO585pS8zE/Oymvtn7ZYALx1bAAf9fexwtYOUl3Rcy1n1lwIV4QWAW
Bhsbtz5rJNLoR6LOYnwy
=HxCV
-END PGP SIGNATURE-
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Re: [SECURITY] CVE-2014-0095 Apache Tomcat denial of service
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 All, On 5/27/14, 8:46 AM, Mark Thomas wrote: CVE-2014-0095 Denial of Service Severity: Important Vendor: The Apache Software Foundation Versions Affected: - Apache Tomcat 8.0.0-RC2 to 8.0.3 Description: A regression was introduced in revision 1519838 that caused AJP requests to hang if an explicit content length of zero was set on the request. The hanging request consumed a request processing thread which could lead to a denial of service. Mitigation: Users of affected versions should apply one of the following mitigations - Upgrade to Apache Tomcat 8.0.5 or later (8.0.4 contains the fix but was not released) Alternate mitigation: SetEnvIf Content-Length ^0$ no-jk=1 - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCAAGBQJThNxLAAoJEBzwKT+lPKRYUAQP/jG3mbXNsti249+OTkXldsiZ uRb9daxgArTH3HaOH9YuL/TPbq6cwOhDlHbIRDFzAEZFpyKySbGBkmpkBdeYUTLX qWWU4IZIGuK8uUysopZ9nohxzi3JghrkE3kSrrUcCGUjmqX1i+MMy/eCdqvOZzxE PlCvCIkQpyCdyodUlW8LmKiofc9/FUEn/820orm+BzMyMTJgZLbxyGtOKPcJkyQA ib/Lky2EmLcP1q/RjlI5ACeFubxNVmdu2Vy4KWkjZQLfVqc4AcBcbDy4INYK+RPs hA2iwctSBul5RXuHcKEJOHDD3FCQJ1u4vchMzmBFj3NnZicf9mbTmk3PXxpT3a3/ HnLxKcQOg0htWSuObMDo/FontTUoid9WJb7jV6Bia1TNEvSgpfjhahcRKIXhvBTw 7+kmQTtdJmL2o/qvlR3ju+zIDMFHCXIHznlhzkcsHQnRWFU4DAEyGQ4z48rXc46U BPVQAZwEkE0V8VzfpvwRG4hQ5bOHPvRX1dVFzZGnuoHMyvpqEolkeQYHWFmlxjMx MEi7oaRAz/cbHwyWmtUd8bjiCcJYy5jF0w2DhQFSi7digjuJc2++tk1vp8touKYA u3nArG5q37uDSk75DAR5tH/lrwtAgpOJe0C9elBygicvK4Al0vCnc3N5G4zFzUJm WjrJ3SUuRSPSChbHyvz0 =FF7n -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: [SECURITY] CVE-2014-0097 Apache Tomcat information disclosure
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
All,
On 5/27/14, 8:46 AM, Mark Thomas wrote:
CVE-2014-0097 Information Disclosure
Severity: Important
Vendor: The Apache Software Foundation
Versions Affected: - Apache Tomcat 8.0.0-RC1 to 8.0.3 - Apache
Tomcat 7.0.0 to 7.0.52 - Apache Tomcat 6.0.0 to 6.0.39
Description: The code used to parse the request content length
header did not check for overflow in the result. This exposed a
request smuggling vulnerability when Tomcat was located behind a
reverse proxy that correctly processed the content length header.
Mitigation: Users of affected versions should apply one of the
following mitigations - Upgrade to Apache Tomcat 8.0.5 or later
(8.0.4 contains the fix but was not released) - Upgrade to Apache
Tomcat 7.0.53 or later - Upgrade to Apache Tomcat 6.0.41 or later
(6.0.40 contains the fix but was not released)
Alternate mitigation (for httpd):
SetEnvIf Content-Length ,{10,} no-jk=1
You can use any reasonable number in place of 10. Note that a 1GiB
Content-Length would be 1073741824 which is 10 characters, so it
would be rejected.
- -chris
-BEGIN PGP SIGNATURE-
Version: GnuPG v1
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQIcBAEBCAAGBQJThN0pAAoJEBzwKT+lPKRYsp0QAMI6viexulYScNMfgExgxxmw
IU/2GzWBxkATN1OEtRXMObqG+ODC2QkCIDNP4Dsznvi8iwlkzr+q/DwqdbisB0xS
gF2JSuNCFdVPzR/KmmgFVzMNj3SmmmIwXp9hQHOBr1H6mTd/om+DcZ2w5sRozqeG
0bC/co5ZddZIV+ObY89qBHYNpt6zLL4PC2Bz7azrB+0X27G5pyh252cFi3IiGzq6
HujnoIMqf8ddz2MTthUz0VFNTVnnZRVTIB/0hX+2sKe/9TcjEfuPxIRnrTtmVoYE
aN62jdL+Ezt34GL8MwbZRDLBgBPNCS4V8pKGwiZpq7qtAlpWJNv/IpwkTzTyHkSm
oeAZSElvQYeVD1tqRYubPXMhvmscYnntbEjBSi1QdSwrvUr1ZIq1z6xuO4hDURx7
Td/B+axvPS3AVOXTk49gxLE/BG+//ly93svfTFRELDTcOsv5am4W4jGHjMRVcDhy
TmJwXUPIpvy8kqmmzZ5hH3hc26Zj47QQxwZeGyFIAjKMklHE0StBr3qtmasEr5tv
H+lWUrBIUXD0i87qzcPNSbRMSTsQvQ27CqPUEslF2o5N/QF/CVc0aQrmcsgil790
b67hpOJ6q3qwTzeCs927qj9+GAC435OHAu9YyjBYHoYReNdVurYP00uMKg+7zL5t
3XDkBXjrLm/FTWpmLBPV
=qbxd
-END PGP SIGNATURE-
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Re: [SECURITY] CVE-2014-0099 Apache Tomcat information disclosure
On 27/05/2014 19:24, Christopher Schultz wrote: André, On 5/27/14, 10:03 AM, André Warnier wrote: Mark Thomas wrote: On 27/05/2014 14:05, André Warnier wrote: Mark Thomas wrote: CVE-2014-0099 Information Disclosure ... Description: The code used to parse the request content length header did not check for overflow in the result. This exposed a request smuggling vulnerability when Tomcat was located behind a reverse proxy that correctly processed the content length header. I believe you, but I must admit that I don't really get what the problem is, here. Sure. First of all exploiting this is not easy. The problem occurs when the content-length overflows during parsing. Tomcat ends up with a lower value for the content length than is really the case. Tomcat will, therefore, read the first part of the request (up to the length it thinks it is) and process it. Assuming keep-alive is being used, Tomcat will then process the remainder of the request as a new request and generate a response for that. Things get messy when there is a reverse proxy in the mix that correctly processes the content length. What ends up happening is this. User A sends request A to proxy. Proxy sends request A to Tomcat. Tomcat process the first part of request A and sends response A1 to the proxy. The proxy sends response A1 to user A. User B sends request B to proxy. Proxy sends request B to Tomcat (using the same connection as for request A) Tomcat processes the remainder of request A and sends response A2 to the proxy Proxy sends response A2 to user B. And you end up with all future responses on that connection going to the wrong user until (which will probably happen fairly soon) Tomcat or the proxy get to a point they realise something is wrong and close the connection. How much deliberate, targeted harm you can do depends a lot on the application. It is certainly easy to trigger response mix-up and - for example on a banking site - that would be bad even if that was all you could do. Thank you for the limpid explanation. Yes, difficult to take advantage of, but certainly confusing for user B, to get something he didn't ask for.. Some of my best English vocabulary comes from Belgians. And waffles. You get English vocabulary from waffles? Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat is down or refused connection
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Mark, On 5/26/14, 4:00 PM, Mark Eggers wrote: Chris, On 5/26/2014 11:28 AM, Christopher Schultz wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Mark, On 5/26/14, 10:25 AM, Mark Eggers wrote: Please do not top post. On 5/26/2014 2:15 AM, Ballarpure, Akshay (EXT-Tata Consultancy Ser - IN/Hyderabad) wrote: Thanks for information.. Sorry i missed adding important information. I can see below message for only 1 or 2 second and it got recovered automatically. [Tue May 20 06:48:43 2014] [57070:140373099702016] [error] ajp_get_reply::jk_ajp_common.c (2126): (worker1) Tomcat is down or refused connection. No response has been sent to the client (yet) [Tue May 20 06:48:43 2014] [56884:140373020112640] [error] ajp_service::jk_ajp_common.c (2643): (worker1) connecting to tomcat failed. Let me know if you need any other information. With Regards, Akshay I gave you a long list of information that would help people on the list understand your system (by the way, we're all volunteers here, most with other jobs and duties). All of this information should be available for more than 1 or 2 seconds. I also find it difficult to believe that the logging information is only available for 1 or 2 seconds. It is probably stored somewhere. Fill out (answer) the 6 questions and their components. Without that, it's doubtful that even meaningful questions concerning what's going on can be asked. Yes, but it's a simple question, Mark. Sheesh: just tell him why his stuff don't work. Open Source means free tech support for unspecified problems, right? Chop chop! - -chris Ah, I can do quick (OK, sort of, kind of, maybe). Oh, geez. I was kidding, Mark. I hope you were, too. 1. If your Tomcat is down, restart it 2. If your network is down, fix it (this is not a network forum) 3. If your firewall drops connections a. tell it to not drop connections (this is not a firewall forum) b. send enough traffic so that connections aren't dropped If you want more (volunteer) help, then I think two things are in order: 1. Provide the information requested (as a start) 2. Be prepared to put in some effort The self-provided effort is the key. If you want more (paid) help, offer to hire someone. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCAAGBQJThOHmAAoJEBzwKT+lPKRYjzcP/27xW+yVk5SSxWr4sYxHgOQz ZSUl7mhi+zXKID9D+VtnH5lI/AMWCUJKQmUP78ov/AnAcDVduAXgxHfnVg8wdriI 9L8W/uChnnOati1HMOZvNT0agVkBogJZrJV3mzn8gG0zdus4dXhApCEcVHR8qcsA /g0QgcGySmexEXd00jErPl23+GctZwhLlmLLMTfYhdgGJrvvEDsO+MD+L33GXm22 5pFr1VjimFDStDZRzxDLioP8Hbjt7212ZNW8tbKvL7V3AHONpR71afziEWku+ZDJ 4CHj3LnQfH3Ur+htXTa1LyrCFofl/XqbTX7zkuaGRZYfAVMq/hNMNsuSFY5pdBOX rAUpgF9L9I2FLqm2TvJSW3kwhDO84oXFpoJMhg8Nv52hJPfTGFZPaLkh9OT9ac4P zeFpDEglNiekgS+Mn0v2DtSatyMQkRIYI6zxilN+2RuskW+O4+ptMT97mhovhfdI QXe7oE71Ub37eS50mzRbwQY0OHUffiWj1sTEqLz0xkGp8jyFZ8cj9EEFm8vbQXna BrNN+zsMt60uuonsaygtCF5MMXjAuoI1d0qKdGaIVWemaMOi6LkpuoRzT7rVI5zC iaCXOF2Jg4CqURmCjIKsSgoP9m5ZASDbu1d+5C+FIaG9Ww9z11DaZywi/kJX39fQ fhUINCxcWE3UM1lyGPT4 =QtmT -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: [SECURITY] CVE-2014-0099 Apache Tomcat information disclosure
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Mark, On 5/27/14, 3:04 PM, Mark Thomas wrote: On 27/05/2014 19:24, Christopher Schultz wrote: André, On 5/27/14, 10:03 AM, André Warnier wrote: Mark Thomas wrote: On 27/05/2014 14:05, André Warnier wrote: Mark Thomas wrote: CVE-2014-0099 Information Disclosure ... Description: The code used to parse the request content length header did not check for overflow in the result. This exposed a request smuggling vulnerability when Tomcat was located behind a reverse proxy that correctly processed the content length header. I believe you, but I must admit that I don't really get what the problem is, here. Sure. First of all exploiting this is not easy. The problem occurs when the content-length overflows during parsing. Tomcat ends up with a lower value for the content length than is really the case. Tomcat will, therefore, read the first part of the request (up to the length it thinks it is) and process it. Assuming keep-alive is being used, Tomcat will then process the remainder of the request as a new request and generate a response for that. Things get messy when there is a reverse proxy in the mix that correctly processes the content length. What ends up happening is this. User A sends request A to proxy. Proxy sends request A to Tomcat. Tomcat process the first part of request A and sends response A1 to the proxy. The proxy sends response A1 to user A. User B sends request B to proxy. Proxy sends request B to Tomcat (using the same connection as for request A) Tomcat processes the remainder of request A and sends response A2 to the proxy Proxy sends response A2 to user B. And you end up with all future responses on that connection going to the wrong user until (which will probably happen fairly soon) Tomcat or the proxy get to a point they realise something is wrong and close the connection. How much deliberate, targeted harm you can do depends a lot on the application. It is certainly easy to trigger response mix-up and - for example on a banking site - that would be bad even if that was all you could do. Thank you for the limpid explanation. Yes, difficult to take advantage of, but certainly confusing for user B, to get something he didn't ask for.. Some of my best English vocabulary comes from Belgians. And waffles. You get English vocabulary from waffles? Of course. Don't you? ;) - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCAAGBQJThOIPAAoJEBzwKT+lPKRY56QQAL23kz7aDppUQQhuToKO/6vR +fYTG8Zr6tqAgeCW/e85BFGlskMol9MH6RU0m7OFiuX7r2Sphj6f4Y/N1/gcS7ho 0qAElXmfHMlb97zSufLUu4nrF3+dApcAgln/EpT29yWyPU2iaEf8mq7Tq9ZUOrcj X0fLRRPJY9pByRqW7Mt7+K8MZYowaHDMbHJvkYvb5p29pQh6ofwZ9sOtJ2SW6Rzg LxuFjwCxeIHfmlp4KZUkXP7jYSUEdv2MUpQxpuXR6oes2U0upZMzA9+utc2HsWEG nCm3qpBXWWheWmf8/rz5qm3enOL+bkWKanRTKi5as+QnQxlTDqGPsxlLMruIWF2F xBEnRI3EiSGNEccGzO+bhCvJsBXN6wr/lhuuGCZVaKN86Oyn5lkQVF6OKfonuyqi Tuz/nIZ+U4bgq6KpPkdUWXwECYKg9HXsoC5GsQkT1kpGCEl/t2qT05YnVVY9bJ/O qW9m6xIHXpqBQy+sieKSkBGprxXcKnRllCEdUuqTU+1mw8RYeKvcxw9XizrrcJW0 KCSwtkwZzlVeLbYXjbRuG2NFvC88LdD3pZHGkOfEo5TnycaC2sJrVUNbenrZ6+aQ t1E7xZJV5I7Pc2aom1j7O3g8xnKVsYd46eGMgym2ZKzKE99T1Y4fK6UXFGJLdY83 fjJd8rLzlKwBBUTaDAvL =9HjU -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: NoClassDefFoundError: org/apache/tomcat/util/descriptor/LocalResolver Error while building project after Tomcat upgrade to 7.0.53 from 7.0.41 !
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Dave, On 5/16/14, 3:05 AM, Utkarsh Dave wrote: I am trying to upgrade my Tomcat from 7.0.41 to the latest release 7.0.53 available and the project build failed with below error. java.lang.NoClassDefFoundError: org/apache/tomcat/util/descriptor/LocalResolver at org.apache.jasper.xmlparser.ParserUtils.init(ParserUtils.java:69) at org.apache.jasper.compiler.JspConfig.processWebDotXml(JspConfig.java:94) at org.apache.jasper.compiler.JspConfig.init(JspConfig.java:243) And same error from multiple places also. Is this a known issue? There are no issues known to the Tomcat team regarding your project build. Are you building Tomcat itself? - From what I see above, I would expect that there is a version mismatch with some library. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCAAGBQJThOU/AAoJEBzwKT+lPKRYto0P/iO+WFAt1CIqwvBAgPkEkCMS DvKTDFtnY71CyTuPYwawkDL/aKndIrDLcCqumftz5XXptibyXYKA0wKmP8xb7Kxm i3SUJqkAcqM11T7PbNshVNiVinJU26SrtDZ8M/M/LoHgAfwgOUFHN4qT1ug4X+IO Zm3vvkUBcGkGNQHBa7mjrG/P3Fd/JSLhQKimD70mqWvSTdeyNY++S2uULEevzNj4 aUo/TCeFZFeOk8w1qhCXT+Zn5K/nq0/5KKtW3ar2n93l9EIES7SNVCD4qeirVjU9 czIHdXmEZdYgwlI2Z7n5/H5LuJ2wn7Zbb+2RH1hi1CiX1QhtALu8qfsa9STpOhts vZf3HTJyishELdh8YQD6A35zKGoKA3Gt646kBFLEeK/6yDkDAPBkHMbOPScziJwg Ura7BsPC6QeFxOw/5i6hUrDhl3fLSmhZ0crRehjINFvJu2XLJyip2LoKSP4UHv4F WDlyjST1pyRlB38p3zHJdqTnaPiI/9sbNfodcLbcmDWfFNHqiH3aVNBT8fPTXvja kyaWAmKUtGQS4xW8nOCh1W9TSGx19R6CYSUzuj10AFE/7U6008hvMWhxJrWiqrEQ cR1RNnIbu5JNCjZhAqF938cpjGQ3MnUBIUgti/abS0WrxkAjaRg4k85cPhU5b1zy 9wzwS7nCwCREx7vRCBqM =XDtm -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: [OT] [SECURITY] CVE-2014-0099 Apache Tomcat information disclosure
Mark Thomas wrote: On 27/05/2014 19:24, Christopher Schultz wrote: André, On 5/27/14, 10:03 AM, André Warnier wrote: Mark Thomas wrote: On 27/05/2014 14:05, André Warnier wrote: Mark Thomas wrote: CVE-2014-0099 Information Disclosure ... Description: The code used to parse the request content length header did not check for overflow in the result. This exposed a request smuggling vulnerability when Tomcat was located behind a reverse proxy that correctly processed the content length header. I believe you, but I must admit that I don't really get what the problem is, here. Sure. First of all exploiting this is not easy. The problem occurs when the content-length overflows during parsing. Tomcat ends up with a lower value for the content length than is really the case. Tomcat will, therefore, read the first part of the request (up to the length it thinks it is) and process it. Assuming keep-alive is being used, Tomcat will then process the remainder of the request as a new request and generate a response for that. Things get messy when there is a reverse proxy in the mix that correctly processes the content length. What ends up happening is this. User A sends request A to proxy. Proxy sends request A to Tomcat. Tomcat process the first part of request A and sends response A1 to the proxy. The proxy sends response A1 to user A. User B sends request B to proxy. Proxy sends request B to Tomcat (using the same connection as for request A) Tomcat processes the remainder of request A and sends response A2 to the proxy Proxy sends response A2 to user B. And you end up with all future responses on that connection going to the wrong user until (which will probably happen fairly soon) Tomcat or the proxy get to a point they realise something is wrong and close the connection. How much deliberate, targeted harm you can do depends a lot on the application. It is certainly easy to trigger response mix-up and - for example on a banking site - that would be bad even if that was all you could do. Thank you for the limpid explanation. Yes, difficult to take advantage of, but certainly confusing for user B, to get something he didn't ask for.. Some of my best English vocabulary comes from Belgians. And waffles. You get English vocabulary from waffles? Only from Belgian waffles though. Example : delicious dɪˈlɪʃəs/ adjective highly pleasant to the taste. delicious Belgian waffles (*) synonyms: mouth-watering, appetizing, tasty, flavoursome, flavourful, delectable, toothsome, inviting, very enjoyable, very palatable; succulent, luscious, rich, sweet; savoury, piquant; informalscrumptious, delish, scrummy, yummy, yum-yum; informalmoreish; informalfinger-licking, nummy; literaryambrosial; rareambrosian, nectareous, nectarean, flavorous, sapid synonyms: delightful, exquisite, delectable, lovely, pleasurable, extremely pleasant/enjoyable; informalglorious, heavenly, divine (*) an obviously tautological expression, since Belgian waffles are delicious by definition - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat is down or refused connection
Chris, On 5/27/2014 12:05 PM, Christopher Schultz wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Mark, On 5/26/14, 4:00 PM, Mark Eggers wrote: Chris, On 5/26/2014 11:28 AM, Christopher Schultz wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Mark, On 5/26/14, 10:25 AM, Mark Eggers wrote: Please do not top post. On 5/26/2014 2:15 AM, Ballarpure, Akshay (EXT-Tata Consultancy Ser - IN/Hyderabad) wrote: Thanks for information.. Sorry i missed adding important information. I can see below message for only 1 or 2 second and it got recovered automatically. [Tue May 20 06:48:43 2014] [57070:140373099702016] [error] ajp_get_reply::jk_ajp_common.c (2126): (worker1) Tomcat is down or refused connection. No response has been sent to the client (yet) [Tue May 20 06:48:43 2014] [56884:140373020112640] [error] ajp_service::jk_ajp_common.c (2643): (worker1) connecting to tomcat failed. Let me know if you need any other information. With Regards, Akshay I gave you a long list of information that would help people on the list understand your system (by the way, we're all volunteers here, most with other jobs and duties). All of this information should be available for more than 1 or 2 seconds. I also find it difficult to believe that the logging information is only available for 1 or 2 seconds. It is probably stored somewhere. Fill out (answer) the 6 questions and their components. Without that, it's doubtful that even meaningful questions concerning what's going on can be asked. Yes, but it's a simple question, Mark. Sheesh: just tell him why his stuff don't work. Open Source means free tech support for unspecified problems, right? Chop chop! - -chris Ah, I can do quick (OK, sort of, kind of, maybe). Oh, geez. I was kidding, Mark. I hope you were, too. Yep, especially since I made a comment about 'short' answers. I think I'm the James Fenimore Cooper of the Tomcat mailing list. I need to study Hemingway a bit. 1. If your Tomcat is down, restart it 2. If your network is down, fix it (this is not a network forum) 3. If your firewall drops connections a. tell it to not drop connections (this is not a firewall forum) b. send enough traffic so that connections aren't dropped If you want more (volunteer) help, then I think two things are in order: 1. Provide the information requested (as a start) 2. Be prepared to put in some effort The self-provided effort is the key. Yep - couldn't figure out a way to say this politely. If you want more (paid) help, offer to hire someone. - -chris . . . just my two cents. /mde/ - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: Tomcat is down or refused connection
-Original Message- From: Mark Eggers [mailto:its_toas...@yahoo.com] Sent: Friday, May 23, 2014 7:53 PM To: users@tomcat.apache.org Subject: Re: Tomcat is down or refused connection On 5/23/2014 5:34 PM, Terence M. Bandoian wrote: On 5/23/2014 1:22 AM, Ballarpure, Akshay (EXT-Tata Consultancy Ser - IN/Hyderabad) wrote: Hello, Soap request is failing with below message in our application. 2014/05/20 06:48:43 [ERROR] (browse_csl) failed to reach startSearch service, soapRC 502 2014/05/20 06:48:43 [ERROR] (soap)Error 502 fault: SOAP-ENV:Server [no subcode] I am seeing below messages in Apache's Mod JK log file. [Tue May 20 06:48:43 2014] [57070:140373099702016] [error] ajp_get_reply::jk_ajp_common.c (2126): (worker1) Tomcat is down or refused connection. No response has been sent to the client (yet) [Tue May 20 06:48:43 2014] [56884:140373020112640] [error] ajp_service::jk_ajp_common.c (2643): (worker1) connecting to tomcat failed. Could you please check and let me know the reason for the above ? Thanks, Akshay Sounds like Tomcat is down. -Terence Bandoian Sounds like your application is broken, or Tomcat is down, or someone unplugged a network cable, or someone changed firewall rules, or . . . Seriously, you have given us no information. And by no, I mean all of this is missing: 1. architecture a. Apache HTTPD (I'm guessing yes) b. mod_jk versus mod_proxy_ajp c. intervening firewalls d. number of Tomcats being supported e. load balancing or not f. using Tomcat native or not 2. versions - of anything a. Apache HTTPD (or whatever else you're using here) b. Tomcat version - exact, please c. Java version - exact, please d. OS and version - exact please 3. Tomcat settings - primarily JVM settings 4. Configurations a. server.xml b. workers.properties - if that's what you're using c. Apache HTTPD configuration - if that's what you're using 5. Log files - more than what you've provided a. catalina logs (Tomcat logs around the time of the event) b. application logs (around the time of the event) 6. What is this application supposed to be doing?? There is more, but this is a good start. A 502 normally means that servers can't talk to each other. This could mean that Tomcat is down, it could mean that an intervening firewall has dropped connections, it could mean many, many things. Don't know without lots more information. . . . . it's Friday, welcome to more than my 2 cents /mde/ Mark - Most importantly, he failed to provide the remote access information for the servers involved and their admin account names and passwords so that we could get in there and look around until we figured out what the problem was. Jeff - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat is down or refused connection
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Mark, On 5/27/14, 3:57 PM, Mark Eggers wrote: Chris, On 5/27/2014 12:05 PM, Christopher Schultz wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Mark, On 5/26/14, 4:00 PM, Mark Eggers wrote: Chris, On 5/26/2014 11:28 AM, Christopher Schultz wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Mark, On 5/26/14, 10:25 AM, Mark Eggers wrote: Please do not top post. On 5/26/2014 2:15 AM, Ballarpure, Akshay (EXT-Tata Consultancy Ser - IN/Hyderabad) wrote: Thanks for information.. Sorry i missed adding important information. I can see below message for only 1 or 2 second and it got recovered automatically. [Tue May 20 06:48:43 2014] [57070:140373099702016] [error] ajp_get_reply::jk_ajp_common.c (2126): (worker1) Tomcat is down or refused connection. No response has been sent to the client (yet) [Tue May 20 06:48:43 2014] [56884:140373020112640] [error] ajp_service::jk_ajp_common.c (2643): (worker1) connecting to tomcat failed. Let me know if you need any other information. With Regards, Akshay I gave you a long list of information that would help people on the list understand your system (by the way, we're all volunteers here, most with other jobs and duties). All of this information should be available for more than 1 or 2 seconds. I also find it difficult to believe that the logging information is only available for 1 or 2 seconds. It is probably stored somewhere. Fill out (answer) the 6 questions and their components. Without that, it's doubtful that even meaningful questions concerning what's going on can be asked. Yes, but it's a simple question, Mark. Sheesh: just tell him why his stuff don't work. Open Source means free tech support for unspecified problems, right? Chop chop! - -chris Ah, I can do quick (OK, sort of, kind of, maybe). Oh, geez. I was kidding, Mark. I hope you were, too. Yep, especially since I made a comment about 'short' answers. I think I'm the James Fenimore Cooper of the Tomcat mailing list. I need to study Hemingway a bit. You and André are in a dead heat, I think. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCAAGBQJThPlUAAoJEBzwKT+lPKRYXf4QAK7Uc4dF7MUWleHgm+Na81Wy 7NXERpS7mEB0SYeS1ythz25gIvDcMVjXsBX8mc0YcIs/y1gtim+9qQYuCnKurNx1 J4ATdWQzQt5HPmwdAI4dP3+x5hMHTX1oRDyJv/6UzqUEVTCouVkYwVx/QAHiOYhd D8j92cxrlMQgE8Oj79vRR7tYFcXM8rejFuMCUXuVOVrpST/hnLY1rqrEAtPjkmp6 S9Q7uDQDe0o41JfAzsBC/VkduH851sfF6zEk7JBwxZ6TZoVFsookB45DDAcqYOVc mlQEjQcsf/PJrJAx7iOyBQ+vLAUWBDJ7YQVa6rjW8fMZmx7KWI3qumFe9oe0PSp4 3BLro+qQxpjuY0pr4DPf1xFkHD0IIPAmfscCYird8TAci3+ggnyn+yq0WVxaeLsh sEU7iuM1V8RxZZ7rbf/gUb4iGrQQ44S+mukQ2artUe3AtTvcfzFSGl1eWMMmU5A4 4pyz9AmLzGYppP9+XUR8Ur+Lel+R6Wc9mUi4tcqPaU08YBfATw1IoLMIlFViI2L5 o3hhqllMYswrkr+cq0Vklqzs/Jfq+KvuW5dVBl4LFDZWDCCrDKyT6TVQRBqYIrtM SNE+XpyMQuftls6vpYGOLfbV1TpHDnJJfKLCBPQANyXgKeeObGrNHuhNcZBH8ULD LWNUh8PpEwIDHyNPCgQv =IGSQ -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat is down or refused connection
Christopher Schultz wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Mark, On 5/27/14, 3:57 PM, Mark Eggers wrote: Chris, On 5/27/2014 12:05 PM, Christopher Schultz wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Mark, On 5/26/14, 4:00 PM, Mark Eggers wrote: Chris, On 5/26/2014 11:28 AM, Christopher Schultz wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Mark, On 5/26/14, 10:25 AM, Mark Eggers wrote: Please do not top post. On 5/26/2014 2:15 AM, Ballarpure, Akshay (EXT-Tata Consultancy Ser - IN/Hyderabad) wrote: Thanks for information.. Sorry i missed adding important information. I can see below message for only 1 or 2 second and it got recovered automatically. [Tue May 20 06:48:43 2014] [57070:140373099702016] [error] ajp_get_reply::jk_ajp_common.c (2126): (worker1) Tomcat is down or refused connection. No response has been sent to the client (yet) [Tue May 20 06:48:43 2014] [56884:140373020112640] [error] ajp_service::jk_ajp_common.c (2643): (worker1) connecting to tomcat failed. Let me know if you need any other information. With Regards, Akshay I gave you a long list of information that would help people on the list understand your system (by the way, we're all volunteers here, most with other jobs and duties). All of this information should be available for more than 1 or 2 seconds. I also find it difficult to believe that the logging information is only available for 1 or 2 seconds. It is probably stored somewhere. Fill out (answer) the 6 questions and their components. Without that, it's doubtful that even meaningful questions concerning what's going on can be asked. Yes, but it's a simple question, Mark. Sheesh: just tell him why his stuff don't work. Open Source means free tech support for unspecified problems, right? Chop chop! - -chris Ah, I can do quick (OK, sort of, kind of, maybe). Oh, geez. I was kidding, Mark. I hope you were, too. Yep, especially since I made a comment about 'short' answers. I think I'm the James Fenimore Cooper of the Tomcat mailing list. I need to study Hemingway a bit. You and André are in a dead heat, I think. I was going to stake my claim, but you beat me to it. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
