[
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)
