[
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
secur...@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)
