openssh bugs - Aug 2012 - [Bug 2040] New: Downgrade attack vulnerability when checking SSHFP records

https://bugzilla.mindrot.org/show_bug.cgi?id=2040

          Priority: P5
            Bug ID: 2040
          Assignee: unassigned-bugs at mindrot.org
           Summary: Downgrade attack vulnerability when checking SSHFP
                    records
          Severity: minor
    Classification: Unclassified
                OS: All
          Reporter: ondrej at caletka.cz
          Hardware: All
            Status: NEW
           Version: 6.1p1
         Component: ssh
           Product: Portable OpenSSH

Created attachment 2183
  --> https://bugzilla.mindrot.org/attachment.cgi?id=2183&action=edit
Fix downgrade attack vulnerability in handling SSHFP records

To quote RFC 6594, section 4.1.:
> Secure Shell implementations that support SHA-256 fingerprints MUST prefer
a SHA-256 fingerprint over SHA-1 if both are available for a server.  If the
SHA-256 fingerprint is tested and does not match the SSH public key received
from the SSH server, then the key MUST be rejected rather than testing the
alternative SHA-1 fingerprint.
The current version of SSH does not conform this requirement. Attached
patch fixes this issue.

It can be tested using this command:
$ ssh -vv -o HostKeyAlgorithms=ecdsa-sha2-nistp521 -o
VerifyHostKeyDNS=yes sshfp-test-downgrade.oskarcz.net

(The SSHFP records with SHA-256 digests for hostname
sshfp-test-downgrade.oskarcz.net are intentionally altered.)

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=2040

--- Comment #1 from Ond?ej Caletka <ondrej at caletka.cz> ---
Created attachment 2184
  --> https://bugzilla.mindrot.org/attachment.cgi?id=2184&action=edit
Handle future digest types correctly

When testing, I also found out that when a SSHFP record for the host
uses digest type other than SHA1 or SHA256, the SSHFP check fails even
if SHA1 or SHA256 matches the offered host key.

This patch changes this behavior to ignore future digest types.

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=2040

--- Comment #2 from Ond?ej Caletka <ondrej at caletka.cz> ---
(In reply to comment #1)
> Created attachment 2184 [details]
> Handle future digest types correctly
> 
> When testing, I also found out that when a SSHFP record for the host
> uses digest type other than SHA1 or SHA256, the SSHFP check fails
> even if SHA1 or SHA256 matches the offered host key.
> 
> This patch changes this behavior to ignore future digest types.
Feel free to test it using 
ssh -vv -o VerifyHostKeyDNS=yes -o
HostKeyAlgorithms=ecdsa-sha2-nistp521 sshfp-test-newdigest.oskarcz.net

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=2040

Damien Miller <djm at mindrot.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |djm at mindrot.org

--- Comment #3 from Damien Miller <djm at mindrot.org> ---
Wouldn't it be simpler and safer to verify that all fingerprints match?
I.e verify that both SHA1 and SHA256 SSHFP records verify correctly.
Right now we need only one success and ignore all the hash
mismatches...

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
You are watching someone on the CC list of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=2040

Ond?ej Caletka <ondrej at caletka.cz> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Attachment #2183|0                           |1
        is obsolete|                            |

--- Comment #4 from Ond?ej Caletka <ondrej at caletka.cz> ---
Created attachment 2188
  --> https://bugzilla.mindrot.org/attachment.cgi?id=2188&action=edit
Fix downgrade attack vulnerability in handling SSHFP records

I realized that only fingerprints for same key algorithm as sshd
offered should be counted as found. Otherwise, it would reject SHA-1
SSHFP only because there is a SHA-256 SSHFP for another key algorithm.

As usual, testcase is here, having only SHA-1 SSHFP for RSA Host key:
$ ./ssh -vv -o HostKeyAlgorithms=ssh-rsa -o VerifyHostKeyDNS=yes
sshfp-test-downgrade.oskarcz.net

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
You are watching someone on the CC list of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=2040

--- Comment #5 from Ond?ej Caletka <ondrej at caletka.cz> ---
(In reply to comment #3)
> Wouldn't it be simpler and safer to verify that all fingerprints
> match? I.e verify that both SHA1 and SHA256 SSHFP records verify
> correctly. Right now we need only one success and ignore all the
> hash mismatches...
This would actually prevent doing a smooth host key rollover, where you
pre-publish SSHFP records for the new Host key, then change the host
key and delete old SSHFP records after that. As DNS updates are never
synchronous, you cannot change SSHFP records at the same moment as host
key.

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
You are watching someone on the CC list of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=2040

Ond?ej Caletka <ondrej at caletka.cz> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Attachment #2188|0                           |1
        is obsolete|                            |

--- Comment #6 from Ond?ej Caletka <ondrej at caletka.cz> ---
Created attachment 2211
  --> https://bugzilla.mindrot.org/attachment.cgi?id=2211&action=edit
Fix downgrade attack vulnerability in handling SSHFP records

Here comes a new version of the patch fixing downgrade vulnerability as
the former one did not work well after applying the ?future digests?
patch. Instructions counting found DNS records are shifted after
hostkey initialization.

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
You are watching someone on the CC list of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=2040

Ond?ej Caletka <ondrej at caletka.cz> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Attachment #2211|0                           |1
        is obsolete|                            |

--- Comment #7 from Ond?ej Caletka <ondrej at caletka.cz> ---
Created attachment 2402
  --> https://bugzilla.mindrot.org/attachment.cgi?id=2402&action=edit
Fix downgrade attack vulnerability in handling SSHFP records

The same patch, only rebased to OpenSSH 6.4p1 codebase.

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
You are watching someone on the CC list of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=2040

Ond?ej Caletka <ondrej at caletka.cz> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Attachment #2184|0                           |1
        is obsolete|                            |

--- Comment #8 from Ond?ej Caletka <ondrej at caletka.cz> ---
Created attachment 2403
  --> https://bugzilla.mindrot.org/attachment.cgi?id=2403&action=edit
Handle future digest types correctly

The same patch, only rebased to OpenSSH 6.4p1 codebase.
Hoping these patche would be eventually make it to a release. :)

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
You are watching someone on the CC list of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=2040

Celeste Liu <CoelacanthusHex at gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |CoelacanthusHex at gmail.com

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
You are watching someone on the CC list of the bug.