Bugzilla – Bug 1182157
VUL-0: CVE-2020-13949: thrift: potential DoS when processing untrusted payloads
Last modified: 2024-07-26 18:52:26 UTC
CVE-2020-13949: Apache Thrift: potential DoS when processing untrusted payloads From: "Jens Geyer" Date: Thu, 11 Feb 2021 23:43:29 +0100 CVE-2020-13949: potential DoS when processing untrusted Thrift payloads Severity: Important Vendor: The Apache Software Foundation Versions Affected: Apache Thrift up to and including 0.13.0 Description: Applications using Thrift would not error upon receiving messages declaring containers of sizes larger than the payload. As a result, malicious RPC clients could send short messages which would result in a large memory allocation, potentially leading to denial of service. Mitigation: Upgrade to version 0.14.0 Credit: This issue was reported by Hasnain Lakhani of Facebook. On behalf of the Apache Thrift PMC, Jens Geyer References: http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2020-13949 http://seclists.org/oss-sec/2021/q1/140
Seems SOC ships thrift twice in different packages: https://build.suse.de/package/show/SUSE:SLE-12-SP4:Update:Products:Cloud9:Update/thrift https://build.suse.de/package/show/SUSE:SLE-12-SP4:Update:Products:Cloud9:Update/python-thrift This was deemed out of scope for LTS of SOC8 unless it is specifically requested. The following issues mention the CVE: https://issues.apache.org/jira/browse/THRIFT-5021 https://issues.apache.org/jira/browse/THRIFT-5007 https://issues.apache.org/jira/browse/THRIFT-5035 https://issues.apache.org/jira/browse/THRIFT-5237 While this doesn't mention the problem, it also sounds relevant: https://issues.apache.org/jira/browse/THRIFT-5369
Our investigation so far has not yield any evidence that the thrift (GO implementation where the CVE is applicable) package is being used by the product. We've combed through all the CI logs for the Cloud 9 gating jobs and found no evidence that the thrift RPM package was being used or even installed. Since the thrift package is available in our product repo, there's a chance that a customer may unintentionally installed it. We came up with the following options: 1) document the fact that the existing package have a vulnerability and it will not be supported by the product going forward. We will not be upgrading the existing package to 0.14.2. 2) document the fact that the existing package have a vulnerability and it will not be supported by the product going forward. We can create a newer version of the package with nothing in it, which effectively disabling the package. 3) update the package to version 0.14.2 and keep supporting it till EOL.
Please advice on the proposed options so we can proceed.
(In reply to Guang Yee from comment #2) > We came up with the following options: > > 1) document the fact that the existing package have a vulnerability and it > will not be supported by the product going forward. We will not be upgrading > the existing > package to 0.14.2. > > 2) document the fact that the existing package have a vulnerability and it > will not be supported by the product going forward. We can create a newer > version of the package with nothing in it, which effectively disabling the > package. > > 3) update the package to version 0.14.2 and keep supporting it till EOL. Solution 1 or 2 sounds good. There is no need to put more effort into this then needed.