Matthew Vernon found that the OpenSSH client may fail to check DNS SSHFP records. When using DNS SSHFP records, if the server offers the client a certificate that the client does not accept, the client does not then verify the DNS SSHFP records. A host verification prompt is still displayed before connecting. A malicious server could possibly use this flaw to disable DNS SSHFP checking and trick a client into connecting to it, if the user accepts 'yes' at the host verification prompt. Original report including a possible patch: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=742513
Created openssh tracking bugs for this issue: Affects: fedora-all [bug 1081341]
openssh-6.4p1-4.fc20 has been pushed to the Fedora 20 stable repository. If problems still persist, please make note of it in this bug report.
openssh-6.2p2-8.fc19 has been pushed to the Fedora 19 stable repository. If problems still persist, please make note of it in this bug report.
IssueDescription: It was discovered that OpenSSH clients did not correctly verify DNS SSHFP records. A malicious server could use this flaw to force a connecting client to skip the DNS SSHFP record check and require the user to perform manual host verification of the DNS SSHFP record.
This issue has been addressed in the following products: Red Hat Enterprise Linux 6 Via RHSA-2014:1552 https://rhn.redhat.com/errata/RHSA-2014-1552.html
Statement: The Red Hat Security Response Team has rated this issue as having Moderate security impact. This issue is not planned to be fixed in Red Hat Enterprise Linux 5 as it is now in Production 3 Phase of the support and maintenance life cycle, https://access.redhat.com/support/policy/updates/errata/
Upstream patch: http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/usr.bin/ssh/sshconnect.c#rev1.247 https://github.com/openssh/openssh-portable/commit/7d6a9fb660c808882d064e152d6070ffc3844c3f
This issue has been addressed in the following products: Red Hat Enterprise Linux 7 Via RHSA-2015:0425 https://rhn.redhat.com/errata/RHSA-2015-0425.html