[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date: Tue, 11 Nov 2014 02:38:09 +0100
From: "Jason A. Donenfeld" <Jason@...c4.com>
To: cve-assign@...re.org
Cc: oss-security@...ts.openwall.com
Subject: Re: CVE Request: Qt Creator fails to verify SSH host key
Seems reasonable enough to me. I'll encourage the vendor to change
practices, or to document that a generally expected practice is
intentionally different for their use case.
On Nov 10, 2014 7:14 PM, <cve-assign@...re.org> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> > they don't check host keys when connecting, which makes a
> > man-in-the-middle attack trivial.
>
> > // TODO: Mechanism for checking the host key. First connection to host:
> save, later: compare
>
> > has received a bit more of a hesitant reaction. The most recent
> > vendor feedback seems to indicate they're not super interested in
> > implementing this.
>
> We don't feel that this is a fair characterization of the (public)
> vendor response. There is a vendor response of:
>
> This was never considered much of an issue due to the scope
> of our SSH support. The main use case is developers
> communicating with their embedded devices that are locally
> connected, typically via USB. Host key checking is of
> limited value there, also because the same IP address is
> often used for different devices. So the anticipated first
> reaction from users would be "How do I turn it off?".
>
> This indicates that the current behavior is intentional behavior. The
> vendor has made a tradeoff between what they perceive as a security
> benefit and what they perceive as a support cost. We do not assign CVE
> IDs based on third-party reports that a vendor should have made a
> different tradeoff. Admittedly, the vendor might decide to change
> their tradeoff later (e.g., if they obtain data indicating that USB
> is actually not a prevalent use case).
>
> We agree that it would be nice to have a central place to track
> findings such as "the SSH security expectations for this product are
> different from the SSH security expectations for essentially every
> other product." CVE is not that place.
>
> Similarly, there is an opportunity for security improvement if the
> vendor were to implement key checking, even if the vendor insisted
> that this would not be enabled by default. This type of opportunity
> for security improvement cannot have a CVE assignment.
>
> - --
> 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)
>
> iQEcBAEBAgAGBQJUYP/lAAoJEKllVAevmvmsZIgH/1AjdVpx/gIRO5y0xTo76NQs
> Kb+hC7AAXlBT/ySTfmsWOmTxBE9L77sze2vdt1mOZOLeFCkOmxIQDkBmkP3tlx4o
> TawvLaebWa7e+RG15xLRhXcbUdXa9Fi4oBAMWNL7p+WN1VClh/wTl92EcyELrhp/
> iC22Wg9MaJKY7OGm4FuOghkwsM0L13tfoYvGNNsVOty2aWDopoMSzGU9mbvda/OB
> FwW5KGzBRSD38HTBmwG8eaHWWTWmnHAiT/n4zL7jO7YG6L+ZoYhpUS3Mh/qStlWr
> bgoXn7P6rlU+u+wPA/ZvSk3wWuLSh7623T+3dADJzeS4Ls1CG3bwi6u5kL8HyBA=
> =lZ3n
> -----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.
