-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Viola,
On 9/22/2010 11:29 PM, viola lu wrote: > thanks. I tried it on tomcat 6.0.26, and 6.0.29, it worked for the second > one, i can get correct response headers on tomcat 6.0.26 and tomcat 6.0.29: > tomcat 6.0.26 What is "the first one" and "the second one"? The bugs you mentioned in your first post? Remember, not everyone is thinking what you're thinking: please be clear when posting. > suse10sp268:~ # wget -S -O - --post-data='test send post' > http://9.125.1.248:8080/BasicAuthor_without_realm/BasicAuthor > --07:21:33-- http://9.125.1.248:8080/BasicAuthor_without_realm/BasicAuthor > => `-' > Connecting to 9.125.1.248:8080... connected. > HTTP request sent, awaiting response... > HTTP/1.1 401 Unauthorized > Server: Apache-Coyote/1.1 > *WWW-Authenticate: Basic realm="9.125.1.248:8080"* Good: this reproduces the bug. > *tomcat 6.0.29:* > suse10sp268:~ # wget -S -O - --post-data='test send post' > http://9.125.1.248:8080/BasicAuthor_without_realm/BasicAuthor > --07:24:02-- http://9.125.1.248:8080/BasicAuthor_without_realm/BasicAuthor > => `-' > Connecting to 9.125.1.248:8080... connected. > HTTP request sent, awaiting response... > HTTP/1.1 401 Unauthorized > Server: Apache-Coyote/1.1 > *WWW-Authenticate: Basic realm="Authentication required"* ...and this shows that the bug has been fixed: no IP and port. > But for the first one, both got the same response: 200 OK as below: > suse10sp268:~ # wget -S -O - --header='Transfer-Encoding:unsupported' > --post-data='test send post' > http://9.125.1.248:8080/SecurityTomcat/SecurityServlet > --07:12:16-- http://9.125.1.248:8080/SecurityTomcat/SecurityServlet > => `-' > Connecting to 9.125.1.248:8080... connected. > HTTP request sent, awaiting response... > HTTP/1.1 200 OK > Server: Apache-Coyote/1.1 > Content-Type: text/html > Content-Length: 61 > Date: Thu, 23 Sep 2010 03:09:09 GMT > Connection: keep-alive > Length: 61 [text/html] > 0% > [ > ] 0 --.--K/s unsupported > application/x-www-form-urlencoded > 9.125.1.248 > 100%[=====================================================================================================================================>] > 61 --.--K/s > > 07:12:16 (7.27 MB/s) - `-' saved [61/61] > > Seems no difference on tomcat 6.0.26 and tomcat 6.0.29, is there something > wrong? Maybe this is sensitive to other conditions as well. On 9/24/2010 12:57 AM, viola lu wrote: > After debug into tomcat source code, i found that if transfer-encode is set > as 'buffered', tomcat 6.0.26 will report null pointer exception in buffered > filter recycle, but in tomcat 6.0.29 , directly report 501 error. But not > sure attackers how to obtain sensitive information via a crafted header? When buffers are not recycled properly, information /can/ leak across requests. This means that, under the right conditions, an attacker /might/ be able to exploit the server to disclose information. Just because a vulnerability does not have an exploit doesn't mean it's not a vulnerability: the possibility exists that information can be disclosed. It's not absolutely necessary to be able to actually steal information from a server to be considered a vulnerability. This one might not be reproducible in any predictable way. - -chris -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkycrgEACgkQ9CaO5/Lv0PDJMgCfZbZmJQzqGKx8vwQ6m7IGd+HV OR4AnjjvmJ37pfrQFtii+lUaRPruYaKD =vKvJ -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
