DO NOT REPLY [Bug 42490] - Tomcat Crashes Sometimes When Using Cgywin

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=42490





--- Additional Comments From [EMAIL PROTECTED]  2007-06-05 02:18 ---

You have to unset your DISPLAY -var before starting tomcat remotely!
Otherwise the awt-toolkit will try to use your your remote x-server.



-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 42409] - Extra response headers not sent when using custom error page

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=42409





--- Additional Comments From [EMAIL PROTECTED]  2007-06-05 02:58 ---

When you need to pass information from the controller to a page, you normally 
use
request attributes, not response attributes.
You can can do the same in your case.

I hope that helps.
R


-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 42409] - Extra response headers not sent when using custom error page

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=42409





--- Additional Comments From [EMAIL PROTECTED]  2007-06-05 07:20 ---
As hinted in Comment #16, I tried this:

1) In "TestServlet.java" (see
http://issues.apache.org/bugzilla/attachment.cgi?id=20297) modified the doGet()
method as below:
//response.setHeader("X-BUG", "Value1");
request.setAttribute("X-BUG", "Value1");
response.sendError(HttpServletResponse.SC_BAD_REQUEST);

2) Updated "400.jsp" as below:


Custom 400 error page
<% String value = (String) request.getAttribute("X-BUG");
if(value != null && value.length() > 0) {
response.setHeader("X-BUG", value);
} %>



Does this solve your problem?

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Tagging 5.5.24

[Filip Hanik - Dev Lists]

On Thursday, evening in europe, morning in US

Filip

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 41430] - JkOptions +ForwardDirectories with Apache's DirectoryIndex

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=41430





--- Additional Comments From [EMAIL PROTECTED]  2007-06-05 10:52 ---
I used DirectoryIndex to allow Apache to send directory requests to my Struts
/index.do.  This worked well.  You don't appear to be able to use anything but a
file in welcome-file-list, so I'm not seeing a simple way of fixing this to work
in mod_jk 1.2.20+ - I'd prefer to avoid rewrite rules, files that redirect to my
welcome action, etc. 

Please let me know if I'm missing something obvious.


-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 42593] New: - Win32 Apache/jk/tomcat configuration causes 100% cpu usage

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=42593

   Summary: Win32 Apache/jk/tomcat configuration causes 100% cpu
usage
   Product: Tomcat 5
   Version: 5.5.23
  Platform: Other
OS/Version: Windows XP
Status: NEW
  Severity: critical
  Priority: P2
 Component: Native:JK
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


This has to be a major problem, mod-jk appears severely-broken on win32.

I installed apache 2.2, configured modjk, setup AJP13 to forward to
tomcat5.5.23/20 to say the /docs app on tomcat, so http://myhost/docs goes to
tomcat.

Ideally, the content would server and the cpu usage would drop to zero-ish. 
What I noticed is that the content serves up ok but then the TOMCAT process
sails up to 100%.  Kill the apache process and tomcat returns to normal. 
Restart apache and repeat with same results.

I found this on the 5.5.23 release, and verified on 5.5.20.  I tried to fiddle
with modjk but couldn't figure out how to load the modules in dll form.

Anyhow, I loaded up Tomcat6 and lo, the bug is gone.

This has taken me half a day to figure out, hopefully there is enough for y'all
to go on!

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

jk/native/common/jk_uri_worker_map.c Efficiency in map_uri_to_worker()?

[Webster, Chris]

The code change was brought to my attention by sans.org (for
vulnerability CVE 2007-0774).  No offense intended but the fix seems a
little inefficient.

It shows the fix coded as:

for (i = 0; i < strlen(uri); i++) {
if (i == JK_MAX_URI_LEN) {
jk_log(l, JK_LOG_WARNING,
   "Uri %s is invalid. Uri must be smaller then %d
chars",
   uri, JK_MAX_URI_LEN);
JK_TRACE_EXIT(l);
return NULL;
}
if (uri[i] == ';')
break;
else
url[i] = uri[i];
}

Wouldn't it be better to be coded as something like this?

int uriLen = strlen( uri );
if ( uriLen >= JK_MAX_URI_LEN) {
   jk_log(l, JK_LOG_WARNING,
 "Uri %s is invalid. Uri must be smaller then %d chars",
  uri, JK_MAX_URI_LEN);
 JK_TRACE_EXIT(l);
 return NULL;
}
 
for (i = 0; i < uriLen; i++) {
if (uri[i] == ';')
break;
else
url[i] = uri[i];
}

The check would then only be done once instead of for each character.
Not sure about logging the whole thing either but I'm just an observer.

Sorry but I'm not ready to dive in and make the change myself at this
time.

...chris.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

svn commit: r544697 - /tomcat/container/branches/tc5.0.x/catalina/src/share/org/apache/coyote/tomcat5/CoyoteRequest.java

[markt]

Author: markt
Date: Tue Jun  5 17:51:12 2007
New Revision: 544697

URL: http://svn.apache.org/viewvc?view=rev&rev=544697
Log:
Port fix for CVE-2007-1358 to TC5.0.x

Modified:

tomcat/container/branches/tc5.0.x/catalina/src/share/org/apache/coyote/tomcat5/CoyoteRequest.java

Modified: 
tomcat/container/branches/tc5.0.x/catalina/src/share/org/apache/coyote/tomcat5/CoyoteRequest.java
URL: 
http://svn.apache.org/viewvc/tomcat/container/branches/tc5.0.x/catalina/src/share/org/apache/coyote/tomcat5/CoyoteRequest.java?view=diff&rev=544697&r1=544696&r2=544697
==
--- 
tomcat/container/branches/tc5.0.x/catalina/src/share/org/apache/coyote/tomcat5/CoyoteRequest.java
 (original)
+++ 
tomcat/container/branches/tc5.0.x/catalina/src/share/org/apache/coyote/tomcat5/CoyoteRequest.java
 Tue Jun  5 17:51:12 2007
@@ -2539,6 +2539,9 @@
 variant = "";
 }
 }
+if (!isAlpha(language) || !isAlpha(country) || !isAlpha(variant)) {
+continue;
+}
 
 // Add a new Locale to the list of Locales for this quality level
 Locale locale = new Locale(language, country, variant);
@@ -2602,6 +2605,16 @@
 throwable.printStackTrace(System.out);
 }
 
+}
+
+protected static final boolean isAlpha(String value) {
+for (int i = 0; i < value.length(); i++) {
+char c = value.charAt(i);
+if (!((c >= 'a' && c <= 'z') || (c >= 'A' && c <= 'Z'))) {
+return false;
+}
+}
+return true;
 }
 
 }



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

svn commit: r544698 - in /tomcat/site/trunk/xdocs: security-5.xml security-6.xml

[markt]

Author: markt
Date: Tue Jun  5 17:54:15 2007
New Revision: 544698

URL: http://svn.apache.org/viewvc?view=rev&rev=544698
Log:
Add details for CVE-2007-1358 to TC5 and TC6.

Modified:
tomcat/site/trunk/xdocs/security-5.xml
tomcat/site/trunk/xdocs/security-6.xml

Modified: tomcat/site/trunk/xdocs/security-5.xml
URL: 
http://svn.apache.org/viewvc/tomcat/site/trunk/xdocs/security-5.xml?view=diff&rev=544698&r1=544697&r2=544698
==
--- tomcat/site/trunk/xdocs/security-5.xml (original)
+++ tomcat/site/trunk/xdocs/security-5.xml Tue Jun  5 17:54:15 2007
@@ -94,6 +94,23 @@
 Affects: 5.0.0-5.0.30, 5.5.0-5.5.21
   
 
+  
+low: Cross-site scripting
+   http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-1358";>
+   CVE-2007-1358
+
+Web pages that display the Accept-Language header value sent by the
+   client are susceptible to a cross-site scripting attack if they assume
+   the Accept-Language header value conforms to RFC 2616. Under normal
+   circumstances this would not be possible to exploit, however older
+   versions of Flash player were known to allow carefully crafted malicious
+   Flash files to make requests with such custom headers. Tomcat now 
ignores
+   invalid values for Accept-Language headers that do not conform to RFC
+   2616.
+
+Affects: 5.0.0-5.0.30, 5.5.0-5.5.20
+  
+
   
 moderate: Cross-site scripting
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-7195";>

Modified: tomcat/site/trunk/xdocs/security-6.xml
URL: 
http://svn.apache.org/viewvc/tomcat/site/trunk/xdocs/security-6.xml?view=diff&rev=544698&r1=544697&r2=544698
==
--- tomcat/site/trunk/xdocs/security-6.xml (original)
+++ tomcat/site/trunk/xdocs/security-6.xml Tue Jun  5 17:54:15 2007
@@ -89,6 +89,23 @@
 Affects: 6.0.0-6.0.9
   
 
+  
+low: Cross-site scripting
+   http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-1358";>
+   CVE-2007-1358
+
+Web pages that display the Accept-Language header value sent by the
+   client are susceptible to a cross-site scripting attack if they assume
+   the Accept-Language header value conforms to RFC 2616. Under normal
+   circumstances this would not be possible to exploit, however older
+   versions of Flash player were known to allow carefully crafted malicious
+   Flash files to make requests with such custom headers. Tomcat now 
ignores
+   invalid values for Accept-Language headers that do not conform to RFC
+   2616.
+
+Affects: 6.0.0-6.0.5
+  
+
 
 
 



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

svn commit: r544699 - in /tomcat/site/trunk/docs: security-5.html security-6.html

[markt]

Author: markt
Date: Tue Jun  5 17:55:54 2007
New Revision: 544699

URL: http://svn.apache.org/viewvc?view=rev&rev=544699
Log:
Remember to update the html as well...

Modified:
tomcat/site/trunk/docs/security-5.html
tomcat/site/trunk/docs/security-6.html

Modified: tomcat/site/trunk/docs/security-5.html
URL: 
http://svn.apache.org/viewvc/tomcat/site/trunk/docs/security-5.html?view=diff&rev=544699&r1=544698&r2=544699
==
--- tomcat/site/trunk/docs/security-5.html (original)
+++ tomcat/site/trunk/docs/security-5.html Tue Jun  5 17:55:54 2007
@@ -350,6 +350,46 @@
 
 
 
+
+Fixed in Apache Tomcat 5.5.21, 5.0.HEAD
+
+
+
+
+
+
+
+
+
+low: Cross-site scripting
+   http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-1358";>
+   CVE-2007-1358
+
+
+Web pages that display the Accept-Language header value sent by the
+   client are susceptible to a cross-site scripting attack if they assume
+   the Accept-Language header value conforms to RFC 2616. Under normal
+   circumstances this would not be possible to exploit, however older
+   versions of Flash player were known to allow carefully crafted malicious
+   Flash files to make requests with such custom headers. Tomcat now 
ignores
+   invalid values for Accept-Language headers that do not conform to RFC
+   2616.
+
+Affects: 5.0.0-5.0.30, 5.5.0-5.5.20
+  
+
+
+
+
+
+
+
+
+
+
+
+
+
 
 Fixed in Apache Tomcat 5.5.18, 5.0.HEAD
 

Modified: tomcat/site/trunk/docs/security-6.html
URL: 
http://svn.apache.org/viewvc/tomcat/site/trunk/docs/security-6.html?view=diff&rev=544699&r1=544698&r2=544699
==
--- tomcat/site/trunk/docs/security-6.html (original)
+++ tomcat/site/trunk/docs/security-6.html Tue Jun  5 17:55:54 2007
@@ -341,6 +341,46 @@
 
 
 
+
+
+
+
+
+Fixed in Apache Tomcat 6.0.6
+
+
+
+
+
+
+
+
+
+low: Cross-site scripting
+   http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-1358";>
+   CVE-2007-1358
+
+
+Web pages that display the Accept-Language header value sent by the
+   client are susceptible to a cross-site scripting attack if they assume
+   the Accept-Language header value conforms to RFC 2616. Under normal
+   circumstances this would not be possible to exploit, however older
+   versions of Flash player were known to allow carefully crafted malicious
+   Flash files to make requests with such custom headers. Tomcat now 
ignores
+   invalid values for Accept-Language headers that do not conform to RFC
+   2616.
+
+Affects: 6.0.0-6.0.5
+  
+
+
+
+
+
+
+
+
+
 
 
 



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

svn commit: r544700 - /tomcat/tc6.0.x/trunk/bin/service.bat

[markt]

Author: markt
Date: Tue Jun  5 18:08:53 2007
New Revision: 544700

URL: http://svn.apache.org/viewvc?view=rev&rev=544700
Log:
Fix old reference to Jakarta.

Modified:
tomcat/tc6.0.x/trunk/bin/service.bat

Modified: tomcat/tc6.0.x/trunk/bin/service.bat
URL: 
http://svn.apache.org/viewvc/tomcat/tc6.0.x/trunk/bin/service.bat?view=diff&rev=544700&r1=544699&r2=544700
==
--- tomcat/tc6.0.x/trunk/bin/service.bat (original)
+++ tomcat/tc6.0.x/trunk/bin/service.bat Tue Jun  5 18:08:53 2007
@@ -74,7 +74,7 @@
 rem Use the environment variables as an example
 rem Each command line option is prefixed with PR_
 
-set PR_DESCRIPTION=Apache Tomcat Server - http://jakarta.apache.org/tomcat
+set PR_DESCRIPTION=Apache Tomcat Server - http://tomcat.apache.org/
 set PR_INSTALL=%EXECUTABLE%
 set PR_LOGPATH=%CATALINA_BASE%\logs
 set PR_CLASSPATH=%CATALINA_HOME%\bin\bootstrap.jar



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: svn commit: r544137 - /tomcat/connectors/trunk/jk/native/common/jk_uri_worker_map.c

[Mark Thomas]

Mladen Turk wrote:
> William A. Rowe, Jr. wrote:
>> [EMAIL PROTECTED] wrote:
>>> Add simple URI normalizer that can deal with things like %252e%252e.
>>> This is mostly copy/paste from the IIS module
>>
>> You have me way confused ;-)
>>
> 
> How it works:
> Imagine you have two applications on Tomcat appA and appB, and
> you wish *only* to expose the appA via
> JkMount /appA/* worker
> 
> Request:
> http://host/appA/%252e%252e/appB/
This request, assuming appA is a valid context, is for a directory
listing for:
/%2e%2e/appB/

This is a perfectly valid request that should be honoured if the
directory exists and listing is enabled or a 404 returned if it does
not. It should not matter if httpd + mod_jk + tomcat is used or just
tomcat.

> mod_jk 1.2.22 (with default passing r->uri) will serve /appB/
Obviously bad from a security perspective.

> mod_jk 1.2.23 (with default passing r->unparsed_uri) will return 404
> from Tomcat becasue it will pass the original uri, not the one Httpd
> already unfolded)
This is correct and provides consistent behaviour for direct to Tomcat
 access and access via mod_jk.

> mod_jk 1.2.24 will return 404 from Httpd because there is no JkMount
> /appB/*
This double decoding prevents legitimate access to perfectly valid
files that contain the % character in their name.

>> This has some very ugly side
>> effects for legitimately escaped paths,
+1

>> and if it is a security precaution,
>> don't you just leave yet-a-new-hole for triply-folded uris?
I haven't tested this but probably not. If I understand the patch
correctly, httpd will undo one level, mod_jk will undo a second and
test the mappings and Tomcat will be passed the url httpd unfolded so
it will still be double-folded at this point. Tomcat will unfold once
more and fail to map the url.

> Again, no. It doesn't touch the original uri.
> Request for http://host/appA/%252e%252e/appB/ will be unfolded by
> httpd to http://host/appA/%2e%2e/appB/ before it hits mod_jk.
> Inside map_uri_to_worker it will be unescped (locally) to
> /appA/../appB/ and the normalized to /appB/ and then it looks for
> mounted path. In case one have JkMount /* or JkMount /appB/*, the
> original uri host/appA/%2e%2e/appB/ will be passed to Tomcat.
But this is wrong. The url should only be decoded once in the
processing chain.

I can see how this would provide a safe alternative for users that the
1.2.23 fix caused problems for but I do not believe it should be the
default.

I would suggest:
- keep the 1.2.23 behaviour (+ForwardURICompatUnparsed) as the default
- modify the ForwardURICompat option to include this additional check

This approach:
- maintains the security of 1.2.23
- ensures the url is decoded only once by default
- provides a safe option for users that want/need/expect double decoding

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: svn commit: r544137 - /tomcat/connectors/trunk/jk/native/common/jk_uri_worker_map.c

[Mladen Turk]

Mark Thomas wrote:
>> mod_jk 1.2.23 (with default passing r->unparsed_uri) will return 404
>> from Tomcat becasue it will pass the original uri, not the one Httpd
>> already unfolded)
> This is correct and provides consistent behaviour for direct to Tomcat
>  access and access via mod_jk.
>

It is not correct behavior, because we are stripping down the
entire Httpd filter chain.

>> mod_jk 1.2.24 will return 404 from Httpd because there is no JkMount
>> /appB/*
> This double decoding prevents legitimate access to perfectly valid
> files that contain the % character in their name.
>

How many times I have to repeat. The uri is *not* decoded twice.
It is decoded *only once* by the Apache Httpd.

And please test the patch before making comments like that,
because it will not allow nor disallow anything except
back mappings (the one that were not specified by JkMount).


Again, no. It doesn't touch the original uri.

But this is wrong. The url should only be decoded once in the
processing chain.



Did I mention that uri is *not* decoded twice?


I can see how this would provide a safe alternative for users that the
1.2.23 fix caused problems for but I do not believe it should be the
default.

I would suggest:
- keep the 1.2.23 behaviour (+ForwardURICompatUnparsed) as the default
- modify the ForwardURICompat option to include this additional check



mod_jk is present for years, and now suddenly changing the
default behavior makes users surprised with mod_rewrite not
working any more. This change was accepted and made only as
a temporary solution to CVE 2007-0774, and as such must be resolved,
rather then hidden inside.



This approach:
- maintains the security of 1.2.23
- ensures the url is decoded only once by default
- provides a safe option for users that want/need/expect double decoding



Did I mention that uri is *not* decoded twice?

Regards,
Mladen.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]