Bug 2516 - ssh client shouldn't trust the DNS AD bit blindly
Summary: ssh client shouldn't trust the DNS AD bit blindly
Status: CLOSED WONTFIX
Alias: None
Product: Portable OpenSSH
Classification: Unclassified
Component: ssh (show other bugs)
Version: 7.1p1
Hardware: All All
: P5 security
Assignee: Assigned to nobody
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2015-12-12 04:41 AEDT by scott-mindrot
Modified: 2016-08-02 10:41 AEST (History)
1 user (show)

See Also:

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description scott-mindrot 2015-12-12 04:41:01 AEDT 
I've been working on getting DNSSEC local validation working on OSX with ldns (see bug 2119), and I see that the code for libresolv and libldns both trust the AD bit in DNS responses for the SSHFP by default.

From RFC 4035 section 4.6,
   A resolver MUST disregard the meaning of the CD and AD bits in a
   response unless the response was obtained by using a secure channel
   or the resolver was specifically configured to regard the message
   header bits without using a secure channel.

My coffee house here happily sets the AD bit on DNSSEC answers, but I wouldn't trust that they did the correct validation... which means I could easily be auto-accepting server fingerprints for MITM hosts into which I may type my password (ie "Bad(tm)")

AD bit might be useful, but not in an untrusted environment, and currently openssh doesn't have any way to know if it can trust the AD bit it gets, so per the RFC, it should probably ignore it unless it's explicitly configured to do otherwise.

I suggest only treating the SSHFP as secure if the DNS response is locally validated (eg with ldns and a locally stored root anchor), and perhaps supporting the AD bit only if a (new) host config indicates that it's ok.
Comment 1 Damien Miller 2015-12-12 09:05:06 AEDT 
That RFC advice is irrelevant to OpenSSH because OpenSSH isn't a resolver. OpenSSH talks to a resolver via libc interfaces (or optionally ldns) and its up to the resolver in use to determine the trustworthyness of AD.
Comment 2 scott-mindrot 2015-12-12 11:56:12 AEDT 
The ssh process, (through libresolv, libldns or whatever), is processing a DNS packet from an untrusted third party resolver (it sends and receives DNS packets directly with the resolv.conf server, eg coffee shop router)... not sure who else is supposed to decide that the AD bit is untrusted at that point?
Comment 3 Damien Miller 2016-07-08 14:26:51 AEST 
Like I said, it's up to the resolver code. OpenSSH doesn't implement name resolution.

We couldn't implement this even if we wanted to*, as the libc resolver doesn't expose the AD information to its callers. 

* short of implementing a full resolver in OpenSSH, which isn't going to happen.
Comment 4 Damien Miller 2016-08-02 10:41:22 AEST 
Close all resolved bugs after 7.3p1 release