[prev in list] [next in list] [prev in thread] [next in thread]
List: oss-security
Subject: Re: [oss-security] Re: CVE request: claws-mail vcalendar plugin stores user/password in cleartext
From: Michael Samuel <mik () miknet ! net>
Date: 2014-03-22 10:28:11
Message-ID: CACYkhxj=X2ruNshELiTHS_paRfn2q40cBZkBUybscWhZbQDGvQ () mail ! gmail ! com
[Download RAW message or body]
Ok, I'm going to disagree with each of your points individually:
On 22 March 2014 15:46, <cve-assign@mitre.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
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic