[jira] [Commented] (THRIFT-4928) Sensitive information about expected and actual reading lengths (len, got) is leaked from TIOStreamTransport to TTransport through a TTransportException

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

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

Max commented on THRIFT-4928:
-----------------------------

Just because a tool reported an issue – doesn't immediately mean there's a real exploitable bug. Tools are never perfect; you have to use the head to validate the findings.

Before even doing CVSS scoring (to measure the impact severity) here — what class of bug is this? [CWE-200|https://cwe.mitre.org/data/definitions/200.html] I suppose?.. Note what it says:
{quote}The product exposes sensitive information to an actor +that is not explicitly authorized to have access to that information+_._
{quote}
An actor who is viewing server logs is either already authorized to view the logs, or uses another unrelated vuln to gain access to the logs. Note: it'd be completely different matter if this information was exposed to another client connection. But it lands in the logs.

It does not even land in the logs immediately. The code *throws an exception*. The application can choose to log it, or not log it. The log control you're talking about — can be implemented in the application which uses Thrift, with no changes to Thrift required.

Next, I might get proven wrong here, but I'd not strictly classify reading lengths as sensitive information. Per OWASP definitions, sensitive information is people's PII, passwords, keys, access tokens, credit card numbers, things like that. Expected message length is part of public contract of a Thrift service — so {{len}} is definitely not "sensitive information" when viewed in context. The taint analysis tool will tell you that it is — simply because it originates from across the trust boundary. But the tool has no understanding of the context; that's why we have to use the head and think ourselves.

For the benefit of the doubt, let's assume anyway that 1) the two integer numbers are sensitive information, 2) the exceptions are always logged by the application. What's the worst thing that can happen?

[My attempt|https://nvd.nist.gov/vuln-metrics/cvss/v3-calculator?vector=AV:L/AC:H/PR:L/UI:N/S:U/C:L/I:N/A:N/E:U/RL:W/RC:X/CR:L/IR:X/AR:X/MAV:L/MAC:H/MPR:L/MUI:N/MS:U/MC:L/MI:N/MA:N&version=3.1] at reasonably scoring this gives severity *1.6 out of 10*. Which is... low, and purely hypothetical (further assuming an unknown attack which can use those numbers for confidentiality breach).

Finally, and perhaps most importantly, remarks about *responsible disclosure* do apply. You *should not* report such things via public Jira. Follow the instructions from [https://www.apache.org/security/] and *report the issue to security@thrift.apache.org in private*.

My advice is to close this issue and its duplicates, and direct the OP to follow responsible disclosure process.
  

> Sensitive information about expected and actual reading lengths (len, got) is leaked from TIOStreamTransport to TTransport through a TTransportException
> --------------------------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: THRIFT-4928
>                 URL: https://issues.apache.org/jira/browse/THRIFT-4928
>             Project: Thrift
>          Issue Type: Bug
>          Components: Java - Library
>    Affects Versions: 0.11.0, 0.12.0
>         Environment: 	Ubuntu 16.04.3 LTS
> 	Open JDK version "1.8.0_191" build 25.191-b12
>            Reporter: xiaoqin.fu
>            Priority: Major
>          Time Spent: 20m
>  Remaining Estimate: 0h
>
>    Operations: During Apache Thrift integration testing, I developed a calculator application with a client and a server. The client sent a computational command and get the result from the server. After I applied dynamic taint analyzer (distTaint), I found bugs from taint paths finally.
>   The source: org.apache.thrift.transport.TIOStreamTransport:
>     public int read(byte[] buf, int off, int len) throws TTransportException {
>     if (inputStream_ == null) {
>       throw new TTransportException(TTransportException.NOT_OPEN, "Cannot read from null inputStream");
>     }
>     int bytesRead;
> 	......
>       bytesRead = inputStream_.read(buf, off, len);
> 	......
>   }
>   
>   The sink: org.apache.thrift.transport.TTransport, 
>   public int readAll(byte[] buf, int off, int len)
> 	throws TTransportException {
> 	......	
> 	if (ret <= 0) {
> 		throw new TTransportException(
> 		"Cannot read. Remote side has closed. Tried to read "
> 			+ len
> 			+ " bytes, but only got "
> 			+ got
> 			+ " bytes. (This is often indicative of an internal error on the server side. Please check your server logs.)");
> 		}
> 	......
>   }
>   Sensitive information about expected and actual reading lengths (len, got) is leaked.
>   The tainted path:
>    org.apache.thrift.transport.TIOStreamTransport --> 
>    org.apache.thrift.transport.TTransport
>    
> I am going to submit a CVE, so please confirm this is not a true positive.



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