[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20141008151129.GQ23797@brightrain.aerifal.cx>
Date: Wed, 8 Oct 2014 11:11:29 -0400
From: Rich Felker <dalias@...c.org>
To: oss-security@...ts.openwall.com
Cc: cve-assign@...re.org
Subject: Re: Re: Discussion: information leakage from server
and client software - CVE/hardening/other?
On Tue, Oct 07, 2014 at 05:57:25PM -0600, Kurt Seifried wrote:
>
>
> On 07/10/14 03:56 PM, cve-assign@...re.org wrote:
> >> So for example the
> >> http://boingboing.net/2014/10/07/adobe-ebook-drm-secretly-build.html
> >> article would indicate to me that this is CVE worthy under #4
> >
> > Currently not; Adobe has a statement quoted at:
> >
> > http://arstechnica.com/security/2014/10/adobes-e-book-reader-sends-your-reading-logs-back-to-adobe-in-plain-text/
> >
> > indicating that the information disclosure is intentional, and is
> > (from their point of view) useful to them. This is just an example of
> > a behavior that might also occur in an open-source product. The Adobe
> > issue itself is off-topic for this list.
>
> Then by that measure we could for example have challenged CVE-2011-4083
> for example saying that it is useful to us. The same would go for any
> "unsanitized" log file submissions. I fear this is a slippery slope
> where vendors can effectively game their CVE numbers with "oh we meant
> to do that" which makes CVE much less useful =(
I agree with Kurt. I think there should be something along the lines
of "reasonable expectation of privacy" here. I admit that this is
subjective, but cases like the Adobe one are pretty clear. Even if
it's not 100% clear whether the vendor has a legitimate need for the
data (I would say they don't, but this is not the point right now),
random third parties with the ability to intercept unencrypted network
traffic certainly do not have a legitimate need for it. So at the very
least, I think any transmission of data where the user might have a
reasonable expectation that the data is "private", if it takes place
over a non-encrypted channel, is CVE-worthy.
Rich
Powered by blists - more mailing lists
Please check out the
Open Source Software Security Wiki, which is counterpart to this
mailing list.
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
