[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <201403220446.s2M4kMrm004908@linus.mitre.org>
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.
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
