You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by bu...@apache.org on 2008/01/28 15:52:49 UTC
DO NOT REPLY [Bug 44310] New: - Possible data packet corruption when sending data on the outputStream of a recycled response
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG�
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://issues.apache.org/bugzilla/show_bug.cgi?id=44310>.
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=44310
Summary: Possible data packet corruption when sending data on the
outputStream of a recycled response
Product: Tomcat 6
Version: 6.0.14
Platform: All
OS/Version: All
Status: NEW
Severity: normal
Priority: P2
Component: Connectors
AssignedTo: tomcat-dev@jakarta.apache.org
ReportedBy: cpierret@sparus-software.com
When using asynchronous sending (with async receive through Comet API), a
servlet can try to use a recycled response and its output stream by error.
If it is the case, then some random client may get the data sent to another client.
An exception is thrown :
java.lang.NullPointerException
at
org.apache.coyote.http11.InternalNioOutputBuffer.addToBB(InternalNioOutputBuffer.java:615)
at
org.apache.coyote.http11.InternalNioOutputBuffer.commit(InternalNioOutputBuffer.java:608)
at org.apache.coyote.http11.Http11NioProcessor.action(Http11NioProcessor.java:1017)
at org.apache.coyote.Response.action(Response.java:183)
at org.apache.coyote.Response.sendHeaders(Response.java:379)
at org.apache.catalina.connector.OutputBuffer.doFlush(OutputBuffer.java:305)
at org.apache.catalina.connector.OutputBuffer.flush(OutputBuffer.java:288)
at
org.apache.catalina.connector.CoyoteOutputStream.flush(CoyoteOutputStream.java:98)
By activating
-Dorg.apache.catalina.connector.RECYCLE_FACADES=true
on the command line, the problem of data corruption does not occur anymore
(exception occurs in write and not flush).
It is a robustness issue for applications trying to use asynchronous IOs in tomcat.
--
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: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
DO NOT REPLY [Bug 44310] - Possible data packet corruption when sending data on the outputStream of a recycled response
Posted by bu...@apache.org.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG�
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://issues.apache.org/bugzilla/show_bug.cgi?id=44310>.
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=44310
------- Additional Comments From cpierret@sparus-software.com 2008-01-28 12:55 -------
Short explanation:
Using this failure, a black hat could craft a malicious application in order to
write arbitrary data to a random connection in any web app in the same tomcat
instance.
Long explanation:
When developing asynchronous IO on top of tomcat, one need some kind of thread
pool writing asynchronously on sockets (through response's outputStream) and use
Comet API for reading.
When doing so, you need to track any error or exception that may occur and avoid
any thread writing as soon as any such error or exception occurs while reading
(say a mobile device disconnected due to bad cellular network condition). It is
close to impossible to ensure such behavior (if you can prove me wrong, you are
hired and will get big bonuses from me :-). While in the process of running
stability and load testing on such an application, where we made a lot of effort
to avoid such bad behavior, we encountered rare cases that produced such bad
condition (using the outputstream from a recycled response) thus resulting in
data corruption in random other client connection. It took several weeks to
find out why it was occurring and the consequences of such error is extremely
bad: "data corruption!". We still do not see how to avoid all cases that could
lead it to occur.
Furthermore, the patch is attached, simple (5 lines moved) and very unlikely to
introduce any regression.
I have no requirement to include it in 6.0.16 since I have a workaround (disable
recycling facades), but I think that other developers may encounter this kind of
issue and take a lot of time (one man month in our case) to find this same
workaround.
--
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: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
DO NOT REPLY [Bug 44310] - Possible data packet corruption when sending data on the outputStream of a recycled response
Posted by bu...@apache.org.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG�
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://issues.apache.org/bugzilla/show_bug.cgi?id=44310>.
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=44310
------- Additional Comments From cpierret@sparus-software.com 2008-01-29 04:24 -------
I agree the current servlet spec is quite clear about not reusing objects
outside of the request/response scope.
The servlet spec does not offer any support for asynchronous I/Os, which is the
context of the current request.
In order to improve overall robustness of tomcat in front of what can be
considered bad programming in the context of the current servlet spec but is
required to implement asynchronous SENDs (using an application-defined thread
SEND pool that have no real way to sync with RECV errors without blocking), I
suggested that the lifecycle of public objects (Response, OutputStream)
referencing internal implementation details (OutputBuffer) be in sync.
The outputBuffer is recycled, but public objects that may have been stored for
application-defined purposes are still pointing to it, which is , in my opinion,
not the best design possible.
I have a design pattern of trying to keep related API objects' lifecycles in
sync to avoid the kind of issue I was experiencing before applying the patch.
I will anyhow ship my product with this patch in my installer , which packages
tomcat inside.
e.g.: the application I am talking about is a commercial Mobile SSL VPN based on
tomcat. It may be bold, but it works like a charm...
--
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: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
DO NOT REPLY [Bug 44310] - Possible data packet corruption when sending data on the outputStream of a recycled response
Posted by bu...@apache.org.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG�
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://issues.apache.org/bugzilla/show_bug.cgi?id=44310>.
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=44310
funkman@joedog.org changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution| |INVALID
------- Additional Comments From funkman@joedog.org 2008-01-28 16:57 -------
If a security manager is enabled, the response is already discarded and not
recycled. This means in a shared/hosted (or any tin foil hat like) environment,
a black hat couldn't exploit this issue.
The spec is clear about servlets not reusing requests/responses outside of the
current request.
Filip/Remy are much in tune with the comet api internals and can comment if the
above is incorrect.
--
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: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
DO NOT REPLY [Bug 44310] - Possible data packet corruption when sending data on the outputStream of a recycled response
Posted by bu...@apache.org.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG�
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://issues.apache.org/bugzilla/show_bug.cgi?id=44310>.
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=44310
------- Additional Comments From cpierret@sparus-software.com 2008-01-28 07:00 -------
Thinking about it, it could be used to create a security exploit between webapps.
e.g.: You could write a webapp that could send arbitrary data to clients of
another webapp ...
--
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: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
DO NOT REPLY [Bug 44310] - Possible data packet corruption when sending data on the outputStream of a recycled response
Posted by bu...@apache.org.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG�
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://issues.apache.org/bugzilla/show_bug.cgi?id=44310>.
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=44310
------- Additional Comments From markt@apache.org 2008-01-28 12:30 -------
Could you be clearer how this happens please. It looks at the minute as if the
root cause of this is a coding error in the servlet.
--
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: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
DO NOT REPLY [Bug 44310] - Possible data packet corruption when sending data on the outputStream of a recycled response
Posted by bu...@apache.org.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG�
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://issues.apache.org/bugzilla/show_bug.cgi?id=44310>.
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=44310
------- Additional Comments From cpierret@sparus-software.com 2008-01-28 06:57 -------
Created an attachment (id=21437)
--> (http://issues.apache.org/bugzilla/attachment.cgi?id=21437&action=view)
Fixing recycle code for Coyote Response
A patch improving robustness of recycle code
--
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: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
DO NOT REPLY [Bug 44310] - Possible data packet corruption when sending data on the outputStream of a recycled response
Posted by bu...@apache.org.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG�
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://issues.apache.org/bugzilla/show_bug.cgi?id=44310>.
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=44310
------- Additional Comments From markt@apache.org 2008-01-28 13:21 -------
My current thoughts are that the option should be documented as recommended
configuration for comet on the appropriate page of the documentation.
--
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: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
DO NOT REPLY [Bug 44310] - Possible data packet corruption when sending data on the outputStream of a recycled response
Posted by bu...@apache.org.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG�
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://issues.apache.org/bugzilla/show_bug.cgi?id=44310>.
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=44310
------- Additional Comments From cpierret@sparus-software.com 2008-01-28 15:36 -------
This issue does not depend on the usage of the Comet API.
It is related to the usage of the Coyote Response object with sends occurring in
separate thread as read.
In Response.recycle(), the outputBuffer is always recycled and neither the
Response that references the outputStream that references the outputBuffer are.
It can lead to the outputStream referencing the outputBuffer reallocated to
another outputStream in another Response object, which can occur as soon as you
try to send data asynchronously in another thread (due to read errors not
depending on the usage of Comet).
At least the outputBuffer should not be recycled by default in this case for
consistency, since there are two public API objects referencing it without being
recycled. IMHO, the behaviour of the Response.recyle can be viewed as
inconsistent and can lead to inter web app side effects.
The attached patch fixes this issue with a regression risk that is extremely low .
--
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: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org