Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date: Tue, 11 Nov 2014 02:38:09 +0100
From: "Jason A. Donenfeld" <>
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, <> wrote:

> 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 ]
> 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

Powered by blists - more mailing lists

Your e-mail address:

Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.

Powered by Openwall GNU/*/Linux - Powered by OpenVZ