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

[Jean-Frederic]

On Tue, 2007-06-05 at 17:15 -0500, Webster, Chris wrote:
> 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.

You fix is bad Because we only need the url: part of the uri before
the ';' so you will prevent valid url to work with this correction.

Cheers

Jean-Frederic

> 
> 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]
> 


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

svn commit: r544807 - in /tomcat/site/trunk: docs/security-6.html xdocs/security-6.xml

[markt]

Author: markt
Date: Wed Jun  6 04:21:17 2007
New Revision: 544807

URL: http://svn.apache.org/viewvc?view=rev&rev=544807
Log:
Correct fixed in version for CVE-2005-2090

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

Modified: tomcat/site/trunk/docs/security-6.html
URL: 
http://svn.apache.org/viewvc/tomcat/site/trunk/docs/security-6.html?view=diff&rev=544807&r1=544806&r2=544807
==
--- tomcat/site/trunk/docs/security-6.html (original)
+++ tomcat/site/trunk/docs/security-6.html Wed Jun  6 04:21:17 2007
@@ -233,30 +233,7 @@
simplified not to use any user provided data in the output.
 
 Affects: 6.0.0-6.0.10
-  
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Fixed in Apache Tomcat 6.0.13
-
-
-
-
-
-
-
-
+
 
 important: Information disclosure
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-2090";>

Modified: tomcat/site/trunk/xdocs/security-6.xml
URL: 
http://svn.apache.org/viewvc/tomcat/site/trunk/xdocs/security-6.xml?view=diff&rev=544807&r1=544806&r2=544807
==
--- tomcat/site/trunk/xdocs/security-6.xml (original)
+++ tomcat/site/trunk/xdocs/security-6.xml Wed Jun  6 04:21:17 2007
@@ -35,9 +35,7 @@
simplified not to use any user provided data in the output.
 
 Affects: 6.0.0-6.0.10
-  
 
-  
 important: Information disclosure
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-2090";>
CVE-2005-2090



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

DO NOT REPLY [Bug 42488] - in HP-UX the getter and setter for a property is not recognized.

[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=42488


[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED




--- Additional Comments From [EMAIL PROTECTED]  2007-06-06 04:48 ---
I changed the indexed getter setter name for it to work in all environments. So 
that there is no overloading of getters setters.

-- 
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]

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

[Mark Thomas]

Mladen Turk wrote:
> 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.

This bit I understand. I now see how the fix for CVE-2007-1860 causes
problems.

>>> 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.

Yes it is decoded only once by httpd, but it is decoded again by
Tomcat. This is what I meant by decoded twice.

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

You did and I still don't agree. The root cause of CVE-2007-1860 was a
double decoding. Once in httpd/mod_jk and once in Tomcat.

> 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.

Agreed. Ideally, we need a solution that:
- doesn't open up a security hole
- doesn't break existing configurations
- correctly maps http://host/appA/%252e%252e/appB/ to the directory
%2e%2e/appB/ within appA

My current understanding is:
1. httpd takes original uri
2. httpd decodes uri (I might not have this at quite the correct point)
3. httpd may modify this (mod_rewrite etc)
4. httpd passes the uri to mod_jk
5. mod_jk maps the uri to a worker
6. mod_jk passes the uri to tomcat
7. tomcat decodes the uri (again)
8. tomcat maps the request and processes it

As I understand it, the fix for CVE-2007-1860 caused mod_jk map the
original uri to Tomcat, bypassing both httpd's decoding (good) and any
httpd modifications (bad).

As I see it, we have two options:
a) Prevent Tomcat from decoding the uri a second time at step 7 above
b) Re-encode the uri in mod_jk between steps 5 and 6

The problem with b) is that we can't easily tell what characters were
previously encoded and need to be re-encoded. b) is also inefficient.

Doesn't this mean a) is really the only option?

Mark

-
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:



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


You did and I still don't agree. The root cause of CVE-2007-1860 was a
double decoding. Once in httpd/mod_jk and once in Tomcat.



Why do you don't agree?
Please provide a use case and confirm your statements are
legitimate.

Regards,
Mladen.

-
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

[Remy Maucherat]

Mark Thomas wrote:

As I see it, we have two options:
a) Prevent Tomcat from decoding the uri a second time at step 7 above
b) Re-encode the uri in mod_jk between steps 5 and 6

The problem with b) is that we can't easily tell what characters were
previously encoded and need to be re-encoded. b) is also inefficient.

Doesn't this mean a) is really the only option?


I think:
- it's the proxy which should have options for adapting to what the 
proxied server does
- mod_jk is supposed to be a transparent proxy (and as such give Tomcat 
a non decoded uri); despite what it could break in httpd, decoding the 
uri at all is evil, since the character encoding used could be different 
from the one used in Tomcat


So I am not in favor of a).

Rémy

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

Developing Tomcat in NB

[Daria]

Dear Tomcat developers,

I would like to let you now that we have recently ported Tomcat 6.0.13
environment into NetBeans IDE.
You may wish to check it out:
http://wiki.netbeans.org/wiki/view/NetbeansedTomcat

If you are new to NB please go to netbeans.org for all information,
tutorials and fun stuff.

Now you can completely build, debug, profile Tomcat inside NB IDE and have
access to all nifty features NB IDE provides to make developer's more
productive and happy.
You productivity may get a serious boost and you will learn a new stuff as
well :-)

I would greatly appreciate any feedback you may have about my project and
any ideas on how to make it more useful for Tomcat community.

Daria Titova
NB Engineer.
-- 
View this message in context: 
http://www.nabble.com/Developing-Tomcat-in-NB-tf3878243.html#a10989703
Sent from the Tomcat - Dev mailing list archive at Nabble.com.


-
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]

Remy Maucherat wrote:

Mark Thomas wrote:

As I see it, we have two options:
a) Prevent Tomcat from decoding the uri a second time at step 7 above
b) Re-encode the uri in mod_jk between steps 5 and 6



I think:
- it's the proxy which should have options for adapting to what the 
proxied server does
- mod_jk is supposed to be a transparent proxy (and as such give Tomcat 
a non decoded uri); despite what it could break in httpd, decoding the 
uri at all is evil, since the character encoding used could be different 
from the one used in Tomcat


So I am not in favor of a).



Agreed.

I mean the sole purpose of having a proxy in front of Tomcat
is that this proxy actually *does* something, weather its a
static content delivery, uri rewriting, load balancing, security,
its irrelevant. The uri as well as the entire request thus might
end up completely different then the one client originally issued.
It might have a different uri, different headers, etc.

However options a) and b) that Mark gave have nothing to do
with what we actually need and what was the actual problem.
The sole problem was how to prevent unwanted mappings,
and 1.2.23 solved that by passing the original client
uri thus skipping the entire httpd filter chain.
This is very bad and doesn't solve the problem, because if the
user needs thing like mod_rewrite he will need to re-enable
the original 'JkOptions ForwardURICompat' making him again
vulnerable to the CVE-2007-1860.

My patch (again does *not* double encode the uri) on the other
hand simply has a smarter JkMount detection and prevents the
requests to the Tomcat that were not explicitly defined.
The uri passed is the same one that was passed as default for
so many years.

Regards,
Mladen.

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

MD5 checksums when building Tomcat from source

[Mark Claassen]

I am trying to build Tomcat from source and I am curious about something.
On the Tomcat download page it say the following:
> "You must verify the integrity of the downloaded files."

Yet, the Tomcat build blindly downloads all kinds of sources that are not
verified in any way.  ANT can do MD5 checksums.  Shouldn't the Tomcat
properties file contain the checksums for the files it uses so they can be
verified after they are downloaded?  

It seems to me that if file integrity is a concern, then all the files
should be check.

Here is a sample target:
---











And here would be how you call it:
-





Thanks,
Mark
 


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

DO NOT REPLY [Bug 42608] New: - Invalid Content-Length error for the binary file size greater than 2.1GB

[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=42608

   Summary: Invalid Content-Length error for the binary file size
greater than 2.1GB
   Product: Tomcat 5
   Version: 5.5.6
  Platform: Other
OS/Version: Solaris
Status: NEW
  Severity: normal
  Priority: P2
 Component: Connector:AJP
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


Apache-tomcat-5.5.16 version.
Every time when I send 2GB binary data the apache-tomcat-5.5.16 is working fine.
But when I tried to send 3GB binary data following error below: I did traced to
the error code in HandlerRequest.decodeHeaders method called msg.getInt() this
method is a problem because this method is returning an int instead of long. ant
Integer is only handle 2.1GB limit but I am sending more than 3GB. Is there a
way that you can fix this MessageBytes.getLong() instead of getInt()?

I am looking for a solution to send more than 3GB data to apache-tomcat

Many thanks in advance..

Here is an error below.

[TP-Processor3] ERROR common.HandlerRequest  - Error decoding request
java.lang.NumberFormatException
at org.apache.tomcat.util.buf.Ascii.parseInt(Ascii.java:145)
at org.apache.tomcat.util.buf.ByteChunk.getInt(ByteChunk.java:521)
at org.apache.tomcat.util.buf.MessageBytes.getInt(MessageBytes.java:688)
at 
org.apache.jk.common.HandlerRequest.decodeHeaders(HandlerRequest.java:57
9)
at 
org.apache.jk.common.HandlerRequest.decodeRequest(HandlerRequest.java:39
7)
at org.apache.jk.common.HandlerRequest.invoke(HandlerRequest.java:260)
at org.apache.jk.common.ChannelSocket.invoke(ChannelSocket.java:754)
at 
org.apache.jk.common.ChannelSocket.processConnection(ChannelSocket.java:
684)
at 
org.apache.jk.common.ChannelSocket$SocketConnection.runIt(ChannelSocket.
java:876)
at 
org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool
.java:684)
at java.lang.Thread.run(Thread.java:619)


thanks

--Daniel

-- 
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]

commons-collections is downloaded but never used

[Mark Claassen]

The tomcat build downloads commons-collections but never uses it.  It seems
this could be removed from the build scripts

-Original Message-
From: Mark Claassen [mailto:[EMAIL PROTECTED] 
Sent: Wednesday, June 06, 2007 1:24 PM
To: dev@tomcat.apache.org
Subject: MD5 checksums when building Tomcat from source

I am trying to build Tomcat from source and I am curious about something.
On the Tomcat download page it say the following:
> "You must verify the integrity of the downloaded files."

Yet, the Tomcat build blindly downloads all kinds of sources that are not
verified in any way.  ANT can do MD5 checksums.  Shouldn't the Tomcat
properties file contain the checksums for the files it uses so they can be
verified after they are downloaded?  

It seems to me that if file integrity is a concern, then all the files
should be check.

Here is a sample target:
---











And here would be how you call it:
-


 

Thanks,
Mark
 


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


-
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:
> Mark Thomas wrote:
>>
>>> Did I mention that uri is *not* decoded twice?
>>
>> You did and I still don't agree. The root cause of CVE-2007-1860 was a
>> double decoding. Once in httpd/mod_jk and once in Tomcat.
>>
> 
> Why do you don't agree?
> Please provide a use case and confirm your statements are
> legitimate.

Note: The name of the directory has been chosen to have greatest
variation in behaviour but the general case is any resource name that
contains %nn sequences. This isn't a frequent occurrence; I have only
seen %nn in a resource name in a webdav context and then not that often.

Software:
Win XP Home SP2 + patches
Sun JDK 1.6.0_01
Tomcat 5.5.x built from svn r545026
mod_jk 1.2.x built from svn r545026 with Visual Studio 6 SP6
mod_jk 1.2.23 downloaded from mirrors
mod_jk 1.2.22 downloaded from archive
httpd 2.2.4 downloaded from mirrors

All software installed on a single machine.

Configuration
Tomcat defaults

Single ajp13 worker

jkMount  /jsp-examples/* worker1

A simple 'hello world' html file was created at (directories created
where required):
/jsp-examples/%2e%2e/servlets-examples/index.html

Test 1: Tomcat only
http://localhost:8080/jsp-examples/%252e%252e/servlets-examples/index.html
This correctly showed the index.html I created above.

Test 2: httpd + mod_jk 1.2.22 + Tomcat
http://localhost/jsp-examples/%252e%252e/servlets-examples/index.html
This displayed the index.html from the /servlets-examples context.
This is security issue CVE-2007-1860.

Test 3: httpd + mod_jk 1.2.23 + Tomcat
http://localhost/jsp-examples/%252e%225e/servlets-examples/index.html
This correctly showed the index.html I created above. The issue here
is that any url manipulation (eg mod-rewrite) is bypassed.

Test 4: httpd + mod_jk svn r545026 + Tomcat
http://localhost/jsp-examples/%252e%252e/servlets-examples/index.html
404 is returned. This is incorrectly blocking access to the resource.

My expectation is that:
A) A request for
http://host:port/jsp-examples/%252e%225e/servlets-examples/index.html
returns the correct file for Tomcat standalone and httpd + mod_jk + Tomcat
B) No security issues
C) The full features of httpd (mod_rewrite etc) are available when
using mod_jk

Given that B) is a must, does this make A and C mutually exclusive? I
don't know mod_jk or httpd well enough to make such a pronouncement
but I would be surprised if one of the httpd / mod_jk guru's couldn't
find a solution that allows A, B & C.

-
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:


Single ajp13 worker

jkMount  /jsp-examples/* worker1

A simple 'hello world' html file was created at (directories created
where required):
/jsp-examples/%2e%2e/servlets-examples/index.html

Test 1: Tomcat only
http://localhost:8080/jsp-examples/%252e%252e/servlets-examples/index.html
This correctly showed the index.html I created above.



But this is oxymoron. You wish to serve the content from
servlets-examples with only jsp-examples mounted.
This is also the exact reason of CVE-2007-1860.




My expectation is that:
A) A request for
http://host:port/jsp-examples/%252e%225e/servlets-examples/index.html
returns the correct file for Tomcat standalone and httpd + mod_jk + Tomcat


Use 'JkMount /* worker1' if you need something like that.

The entire point of the story is that if you have *only*
JkMount  /jsp-examples/* then *only* that Context is allowed to be served.
Even hitting the Tomcat (that happens with < 1.2.24) is a security break.


Regards,
Mladen.

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