Re: How to reproduce tomcat security vulnerabilities
-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
Re: How to reproduce tomcat security vulnerabilities
Got it. Appreciate your clarification, Christopher. I will keep post clear to understand.:) On Fri, Sep 24, 2010 at 9:56 PM, Christopher Schultz ch...@christopherschultz.net wrote: -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 -- viola
Re: How to reproduce tomcat security vulnerabilities
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? On Thu, Sep 23, 2010 at 11:29 AM, viola lu viola...@gmail.com 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 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* *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* But for the first one, both got the same repsonse: 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? Appreciate if you can provide more help! On Thu, Sep 23, 2010 at 2:25 AM, Christopher Schultz ch...@christopherschultz.net wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Viola, On 9/21/2010 10:13 PM, viola lu wrote: Here is my client: [snip] Note that your client can be replaced by this one-liner: $ wget -S -O - --header='Transfer-Encoding: unsupported' \ --post-data='test send post' \ http://localhost:8080/SecurityTomcat/SecurityServlet It also has the added advantages of not stripping newlines from the response, and including the response headers in the output. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkyaShYACgkQ9CaO5/Lv0PBzFgCeMVSEXNtPhBFe0ae+M3Ip0aOT 6SgAnAihZq7v3w6icGiPeceYFjnAPN21 =LoyH -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org -- viola -- viola
Re: How to reproduce tomcat security vulnerabilities
On 21/09/2010 19:13, viola lu wrote: Can someone give some hints? Take a look at the security pages. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: How to reproduce tomcat security vulnerabilities
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Viola, On 9/21/2010 10:13 PM, viola lu wrote: Here is my client: [snip] Note that your client can be replaced by this one-liner: $ wget -S -O - --header='Transfer-Encoding: unsupported' \ --post-data='test send post' \ http://localhost:8080/SecurityTomcat/SecurityServlet It also has the added advantages of not stripping newlines from the response, and including the response headers in the output. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkyaShYACgkQ9CaO5/Lv0PBzFgCeMVSEXNtPhBFe0ae+M3Ip0aOT 6SgAnAihZq7v3w6icGiPeceYFjnAPN21 =LoyH -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: How to reproduce tomcat security vulnerabilities
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 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* *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* But for the first one, both got the same repsonse: 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? Appreciate if you can provide more help! On Thu, Sep 23, 2010 at 2:25 AM, Christopher Schultz ch...@christopherschultz.net wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Viola, On 9/21/2010 10:13 PM, viola lu wrote: Here is my client: [snip] Note that your client can be replaced by this one-liner: $ wget -S -O - --header='Transfer-Encoding: unsupported' \ --post-data='test send post' \ http://localhost:8080/SecurityTomcat/SecurityServlet It also has the added advantages of not stripping newlines from the response, and including the response headers in the output. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkyaShYACgkQ9CaO5/Lv0PBzFgCeMVSEXNtPhBFe0ae+M3Ip0aOT 6SgAnAihZq7v3w6icGiPeceYFjnAPN21 =LoyH -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org -- viola
How to reproduce tomcat security vulnerabilities
Hi,
From tomcat 6.0.28 fix list:
http://tomcat.apache.org/security-6.html#Fixed_in_Apache_Tomcat_6.0.28,
there are two security vulnerabilities fixed, but i have no idea how to
trigger these flaws in tomcat 6.0.27 and what's the failure should be after
several trial
for example the first one:*Remote Denial Of Service and Information
Disclosure Vulnerability
I created a client sending a POST request whose Transfer-encoding is
unsupported to a servlet, the servlet will return
Server returned HTTP response code: 501, is this the failure symptom?Here
is my client:
URL url = new URL(http://localhost:8080/SecurityTomcat/SecurityServlet;);
URLConnection connection = url.openConnection();
((HttpURLConnection) connection).setRequestMethod(POST);
connection.setDoOutput(true);
connection.setDoInput(true); // Only if you expect to read a
response...
connection.setUseCaches(false); // Highly recommended...
connection.setRequestProperty(Content-Type,
application/x-www-form-urlencoded);
//connection.setRequestProperty(Transfer-Encoding,
unsupported);
connection.setRequestProperty(Transfer-Encoding,
unsupported);
PrintWriter output;
output = new PrintWriter(new
OutputStreamWriter(connection.getOutputStream()));
output.write(test send post);
// output.write(request);
output.flush();
BufferedReader reader = new BufferedReader(new
InputStreamReader(connection.getInputStream()));
StringBuilder sb = new StringBuilder();
String line = reader.readLine();
while (line!=null line.length() 0) {
sb.append(line);
line = reader.readLine();
}
System.out.println(sb.toString());
output.close();
reader.close();
} catch (UnsupportedEncodingException e) {
// TODO Auto-generated catch block
e.printStackTrace();
} catch (ProtocolException e) {
// TODO Auto-generated catch block
e.printStackTrace();
} catch (IOException e) {
// TODO Auto-generated catch block
e.printStackTrace();
}
The second one,**Information disclosure in authentication headers,** in my
opinion, this is reproduced by sending an unauthorized request, and then
401 status code returns, if i can catch *WWW-Authenticate http header
content, server hostname will be printed out, am i right?
Can someone give some hints? Thanks in advance!*
*
--
viola
