[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date: Sat, 22 Mar 2014 21:28:11 +1100
From: Michael Samuel <mik@...net.net>
To: oss-security@...ts.openwall.com
Subject: Re: Re: CVE request: claws-mail vcalendar plugin
stores user/password in cleartext
Ok, I'm going to disagree with each of your points individually:
On 22 March 2014 15:46, <cve-assign@...re.org> wrote:
> Enabling CURLOPT_SSL_VERIFYHOST but not CURLOPT_SSL_VERIFYPEER has
> valid but perhaps very unusual use cases. It might be appropriate for
> a product that has these expectations for a user:
>
> -- An SSL connection is not used for anything important.
>
-- The user needs SSL anyway (e.g., the other endpoint can only
> communicate over SSL, or the user has a requirement that
> cleartext cannot be sent directly).
If I enable SSL/TLS support in software, I expect a secure connection.
Doing this by
default (or worse - without an option to enable proper SSL/TLS) is a
vulnerability. If it's
deliberately that way it's a backdoor.
-- The user is typically in network environments in which an HTTPS
> proxy exists that is arguably legitimate but outside of the
> user's control. For example, these may be typical enterprise
> environments in which the HTTPS proxy has a certificate resigner.
> From an intranet user's perspective, arbitrary external web sites
> seem to have certificates that are issued to one host, and are
> signed by the enterprise CA.
>
> -- The user is freely allowed access to these intranets but has no
> way to bypass their HTTPS proxies.
>
> -- The user travels to many such network environments and does not
> have the time to configure his laptop to recognize all of these
> enterprise CAs as each one is encountered.
>
So you don't want to trust the enterprise CA, so instead you just trust
anything at
all?
(For example, a salesman visits many companies to do online demos, and
> uses the product to transmit a photo of each company's reception desk
> for his blog about reception desks.)
>
The salesperson will have to either use mobile internet or wait until they
have a
safe connection.
> What is typically less productive
> is to assign a CVE name for what a vendor has established as
> intentional behavior, and hope that this somehow fixes a problem. We
> realize that some CVE consumers could look at those types of CVEs as
> part of their decision about whether to start or stop using the
> product. In practice, this is not a CVE use case that we regularly
> encounter.
>
The vulnerability is still there. Distributions might choose to ignore
upstream and
apply their own patch (in which case coordination via a third-party is
useful). In any
case (as you mentioned) it's useful information when researching software. I
regularly search for "product CVE" before even bothering to download/test
software.
Regards,
Michael
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.
