Bug 2516

Summary:	ssh client shouldn't trust the DNS AD bit blindly
Product:	Portable OpenSSH	Reporter:	scott-mindrot
Component:	ssh	Assignee:	Assigned to nobody <unassigned-bugs>
Status:	CLOSED WONTFIX
Severity:	security	CC:	djm
Priority:	P5
Version:	7.1p1
Hardware:	All
OS:	All

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