[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20141110181405.98BC46C004F@smtpvmsrv1.mitre.org>
Date: Mon, 10 Nov 2014 13:14:05 -0500 (EST)
From: cve-assign@...re.org
To: Jason@...c4.com
Cc: cve-assign@...re.org, oss-security@...ts.openwall.com
Subject: Re: CVE Request: Qt Creator fails to verify SSH host key
-----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.
