[jira] [Commented] (THRIFT-5237) Implement MAX_MESSAGE_SIZE and consolidate limits into a TConfiguration class

["Antoine Pitrou (Jira)" <ji...@apache.org>]

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

Antoine Pitrou commented on THRIFT-5237:
----------------------------------------

Sorry to comment on this issue, but has some analysis of the vulnerability be posted somewhere? In Parquet C++ people have encountered real-world situations where the new message size would prevent from reading legitimate data (see ARROW-13655). Our initial intuition is to simply disable the max message size limit (by bumping it to the max allowable value), but it is not clear what the consequences are. In particular, the CVE-2020-13949 description says:
{quote}In Apache Thrift 0.9.3 to 0.13.0, malicious RPC clients could send short messages which would result in a large memory allocation, potentially leading to denial of service.{quote}

... which is extremely vague (why would a short message result in a large memory allocation? What is the involved mechanism?).

 

> Implement MAX_MESSAGE_SIZE and consolidate limits into a TConfiguration class
> -----------------------------------------------------------------------------
>
>                 Key: THRIFT-5237
>                 URL: https://issues.apache.org/jira/browse/THRIFT-5237
>             Project: Thrift
>          Issue Type: Improvement
>          Components: C glib - Library, C++ - Library, Java - Library
>            Reporter: Zezeng Wang
>            Assignee: Zezeng Wang
>            Priority: Major
>             Fix For: 0.14.0
>
>          Time Spent: 7.5h
>  Remaining Estimate: 0h
>
> This ticket has two related goals:
> a) to implement a new limit for the maximum message size similar to max frames size etc
> b) consolidate and centralize all limits we have (max msg size,. max frame size and max recursion depth) into one place in the code



--
This message was sent by Atlassian Jira
(v8.3.4#803005)