Mailing-List: contact dev-help@thrift.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@thrift.apache.org
Date: Thu, 14 Sep 2017 05:15:00 +0000 (UTC)
From: "ASF GitHub Bot (JIRA)" <jira@apache.org>
To: dev@thrift.apache.org
Message-ID: <JIRA.13101073.1505015654000.109177.1505366100223@Atlassian.JIRA>
In-Reply-To: <JIRA.13101073.1505015654000@Atlassian.JIRA>
References: <JIRA.13101073.1505015654000@Atlassian.JIRA> <JIRA.13101073.1505015654762@jira-lw-us.apache.org>
Subject: [jira] [Commented] (THRIFT-4326) Ruby BufferedTransport not safe
 for reuse after reading corrupted input
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
archived-at: Thu, 14 Sep 2017 05:15:05 -0000


    [ https://issues.apache.org/jira/browse/THRIFT-4326?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16165759#comment-16165759 ] 

ASF GitHub Bot commented on THRIFT-4326:
----------------------------------------

Github user jeking3 commented on the issue:

    https://github.com/apache/thrift/pull/1352
  
    Of course now I see job 2 is failing in nodejs as well.  Spectacular!  Well, let's see how this fares.  If we can get job 4 to pass that would be ideal.  If this one doesn't work I'll run it locally myself in docker and validate it before merging.


> Ruby BufferedTransport not safe for reuse after reading corrupted input
> -----------------------------------------------------------------------
>
>                 Key: THRIFT-4326
>                 URL: https://issues.apache.org/jira/browse/THRIFT-4326
>             Project: Thrift
>          Issue Type: Bug
>          Components: Ruby - Library
>    Affects Versions: 0.10.0
>         Environment: Originally observed with Thrift 0.9.3 on Linux with Ruby 2.3.4, but have also reproduced on Mac OS X with Thrift 0.10.0.
>            Reporter: Ben Weintraub
>
> We've experimented with the Ruby {{BufferedTransport}} class as a wrapper around the {{HttpClientTransport}} class, and found that we were getting clusters sporadic {{Thrift::ProtocolException}} errors in Ruby client processes after network issues caused corruption of some Thrift response bodies.
> Using a bare {{HttpClientTransport}} makes these issues disappear.
> For a given service, we retain a long-lived protocol instance ({{CompactProtocol}} in our case), which in turn holds a reference to a long-lived {{BufferedTransport}} instance.
> The problem seems to stem from the case where the Thrift client is interrupted (e.g. by a Ruby timeout exception) before consuming to the end of the {{@rbuf}} instance variable in {{BufferedTransport}}, leaving {{@index}} pointing to the middle of the read buffer, and meaning that when the transport is re-used upon the next service call, the {{BufferedTransport}} continues reading where it left off in the old buffer, rather than calling through to the wrapped {{HttpClientTransport}} to read the new response obtained from the last call to {{#flush}}.
> Now I know {{Timeout}} is fundamentally unsafe in Ruby and can lead to all kinds of issues like this, but I've also found that this same issue can be triggered by another fairly plausible scenario: if the Thrift service returns a well-formed Thrift response but with N extra bytes of garbage tacked onto the end, then the next N following service calls through the same {{BufferedTransport}} instance will fail with a {{Thrift::ProtocolException}}, as the {{BufferedTransport}} will continue attempting to read the left-over bytes in {{@rbuf}}.
> The naive solution seems like it would be to just reset {{@rbuf}} from {{#flush}}.


--
This message was sent by Atlassian JIRA
(v6.4.14#64029)