Date: Sat, 22 Mar 2014 00:46:22 -0400 (EDT) From: cve-assign@...re.org To: meissner@...e.de Cc: cve-assign@...re.org, oss-security@...ts.openwall.com Subject: Re: CVE request: claws-mail vcalendar plugin stores user/password in cleartext -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 > http://www.thewildbeast.co.uk/claws-mail/bugzilla/show_bug.cgi?id=3106 > Description: > > src/plugins/rssyl/feed.c has this code: > > #if LIBCURL_VERSION_NUM >= 0x070a00 > curl_easy_setopt(eh, CURLOPT_SSL_VERIFYPEER, 0); > curl_easy_setopt(eh, CURLOPT_SSL_VERIFYHOST, 0); > #endif > > Meaning you are not checking ssl remote host validity at all. > Comment 1: > > I think this is a remnant from early development, when I did not need > to be bothered by extra errors from libcurl. > > However, while I agree that CURLOPT_SSL_VERIFYHOST should probably be > enabled, We can provide a CVE assignment for this one specific issue (i.e., the vendor's comment that CURLOPT_SSL_VERIFYHOST=0 is a "remnant" and is not an intentional choice). Use CVE-2014-2576. At the moment, we do not want to proceed with CVE assignments for the choices that are actively disputed by the vendor (or plugin vendors). 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). -- 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. -- Thus, CURLOPT_SSL_VERIFYPEER would mean that the user cannot use the product 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.) In this specific case, one may be able to argue that the product in question almost certainly doesn't have those expectations. One also may be able to argue that the vendor's decision about CURLOPT_SSL_VERIFYPEER is almost certainly based on a misunderstanding of what CURLOPT_SSL_VERIFYPEER means, lack of experience with man-in-the-middle threat models, or incorrect assumptions about the relationship between CURLOPT_SSL_VERIFYPEER and the existence of for-profit Certification Authorities. In such cases, what is typically most productive is to convince the vendor to change the product's behavior and make an announcement that there's a recommended security update to remove the old behavior. (Redistributing the product with a third-party patch is a workaround.) 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. - -- CVE assignment team, MITRE CVE Numbering Authority M/S M300 202 Burlington Road, Bedford, MA 01730 USA [ PGP key available through http://cve.mitre.org/cve/request_id.html ] -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.14 (SunOS) iQEcBAEBAgAGBQJTLROEAAoJEKllVAevmvmsZ3kH/2egm7+4z1lguaBdhNLJcpEF LQG7a21T6JgbYeQW8OfGXdGKK45Yg1fLk1tL8BXyojTBCzwmz+w4tpsfr0JXOkvD tqhAp2zOc7WmCtfI7+homhix3Ljz0pM4J6fwbs4ddmjKM0PWz9OntVjijuRJcN61 vw4alZaXRP/KppRDIuTaobInHrV1nJ4YZjdyF2MbcjsNYcadHFv3//fOkVfxgGnl p6aS9cUWaDZ/6mRYXMbdNp8l7FP8M5szFBRIyhxrURkcLFEOQdEoKvY3Ck4iLk51 UrdYaFhMRmAQFUngBxgpC0EWYEEjIrkIUA4YJUdmgjAerI+XiDdK3zCULH4yf4s= =jwQ3 -----END PGP SIGNATURE-----
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