via Marcus


    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.



References:
http://seclists.org/oss-sec/2014/q1/636