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.
Powered by Openwall GNU/*/Linux - Powered by OpenVZ