openssh bugs - Jun 2013 - [Bug 2119] New: SSHFP with DNSSEC – no trust anchors given, validation always fails

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

            Bug ID: 2119
           Summary: SSHFP with DNSSEC ? no trust anchors given, validation
                    always fails
           Product: Portable OpenSSH
           Version: 6.2p1
          Hardware: Other
                OS: Linux
            Status: NEW
          Severity: enhancement
          Priority: P5
         Component: ssh
          Assignee: unassigned-bugs at mindrot.org
          Reporter: grawity at gmail.com

The ldns DNS resolver, as used by openbsd-compat/getrrsetbyname-ldns.c,
always fails to verify the DNSSEC signatures:

debug3: verify_host_key_dns
debug2: ldns: got 6 answers from DNS
debug2: ldns: trying to validate RRset
debug2: ldns: got 1 signature(s) (RRTYPE 46) from DNS
debug2: ldns: RRset validation failed: General LDNS error
debug1: found 6 insecure fingerprints in DNS

The problem is that ldns is not being given any trust anchor, so it
defaults to an empty list and automatically fails. This makes the ldns
support useless when used standalone (i.e. when the resolver doesn't
set the AD bit).

Either ldns or OpenSSH should be changed to read the default root key ?
see read_key_file() in ldns source (ldns defines LDNS_TRUST_ANCHOR_FILE
as "/etc/unbound/root.key" but doesn't use it automatically).

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

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

Damien Miller <djm at mindrot.org> changed:

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

--- Comment #1 from Damien Miller <djm at mindrot.org> ---
IMO this is for ldns to fix, otherwise every program that uses it would
need to configure trust anchors and that seems a bit silly.

-- 
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=2119

scott-mindrot at shambarger.net changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |scott-mindrot at shambarger.ne
                   |                            |t

--- Comment #2 from scott-mindrot at shambarger.net ---
I encountered this error using openssh on macports... here's my
analysis of the situation (modified from my macports bug)

ssh performs SSHFP fingerprint lookup when VerifyHostKeyDNS is yes or
ask.

Configured with --with-ldns, ssh support validating the SSHFP with
DNSSEC.  SSHFP of host keys validated this way are implicitly trusted. 
If the resolver has DNSSEC validation, and sets the AD bit on the DNS
response, ldns will mark the SSHFP valid without further work.  If the
resolver does not support DNSSEC, or is authoritative for the domain
(eg internal DNS), then ldns must perform the validation locally (the
AD bit is not set).  For this, ldns needs a trust anchor.

I couldn't find anything in the ldns documentation, but the code in
ldns/resolver.c looks for the keyword "anchor" in /etc/resolv.conf to
locate a file containing a DS or DNSKEY RR, and loads it as a trust
anchor.  Without a trust anchor, local DNSSEC validation always fails.

Adding the "anchor" field to resolv.conf allows ldns validation to
succeed.  However, OSX re-creates resolv.conf from scutil's DNS config
whenever the network changes... edits to /etc/resolv.conf are lost.

The only solution to get ldns validation to work on OSX is to add a
trust anchor from a specific file (at least when it is needed for local
validation)

I've created a patch to do this... I chose a "well-known" file
location
for the trust anchor, /etc/trusted-key.key (used by dig, freeipa, etc).
 The other option was drill's default: /etc/unbound/root.key, but that
seemed rather "unbound specific."

I plan to modify my macports patch to include a configure option for
the location of the trusted key file (and make it more general).  Not
sure if I should update the patch to put a note in the man page...

Log of ssh -vv host with the patch applied (note: the macports patch
looks for anchors in two locations atm):

debug2: ldns: got 4 answers from DNS
debug2: ldns: attempt to load trust anchor from file
/etc/trusted-key.key
debug2: ldns: new anchor added to trust chain
debug2: ldns: attempt to load trust anchor from file
/opt/local/etc/trusted-key.key
debug2: ldns: file not found
debug2: ldns: trying to validate RRset
debug2: ldns: got 1 signature(s) (RRTYPE 46) from DNS
debug2: ldns: RRset is signed with a valid key
debug1: found 4 secure fingerprints in DNS
debug1: matching host key fingerprint found in DNS

I'm not sure which version I should supply the patch for... currently
it's against openssh 6.9p1.

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

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

--- Comment #3 from scott-mindrot at shambarger.net ---
Created attachment 2746
  --> https://bugzilla.mindrot.org/attachment.cgi?id=2746&action=edit
Patch to add ldns trust anchor from file on OSX

I've attached my modified macports patch to load the ldns trust anchor
(on OSX only) from the file 'trusted-key.key' located in either a
global (ETCDIR) or ssh-specific (SSHDIR) location.

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

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

--- Comment #4 from scott-mindrot at shambarger.net ---
(In reply to Damien Miller from comment #1)
> IMO this is for ldns to fix, otherwise every program that uses it
> would need to configure trust anchors and that seems a bit silly.
Replying to [comment:1 raimue@?]:
> I agree with the [https://bugzilla.mindrot.org/show_bug.cgi?id=2119#c1
upstream answer]. Was this ever reported to ldns upstream?
(I'm copying this from my comment on the macports openssh bug for
reference in this discussion)

I looked into submitting a patch to ldns upstream, and created a
working patch before realizing that I would break existing users of
libldns (for example, drill) if it was applied.

Basically, ldns_resolver_new_frm_file() loads policy from a file (as
the name suggests), one specifically documented to be /etc/resolv.conf
if the filename parameter is NULL (which is how it's currently called
from openssh).

drill uses this function if it's called without a server parameter, and
the use of /etc/resolv.conf may be overridden with the -c parameter 

If drill is run with a server, ldns_resolver_new() is used and no
default anchors are loaded -- and then only if in chase/trace mode, and
no other keys are yet loaded, it specifically loads
/etc/unbound/root.key as it's default.

Basically, drill expects to the ldns interface to allow all loaded keys
to be configurable at runtime, with no "magic policy" loading keys
from
files that it can't override.  If I modified
ldns_resolver_new_frm_file() to load keys from, say,
/etc/trusted-key.key, then users of drill (and possibly other library
clients) couldn't control the keys they were using from parameters,
breaking use cases where specific keys need to be loaded (eg testing or
private roots).

I could, of course, submit a new interface to ldns that explicitly
loaded default keys from /etc/trusted-key.key (or some other default),
but then openssh couldn't use that interface until the new library
version was available on any particular distribution.

That leaves the final option, which is to use libldns the way drill
does, and load policy from the files explicitly specified... and at
least on OSX, we can't add that policy to the default file
(/etc/resolv.conf) because configd overwrites it.

I agree that having a general purpose "just resolve my hostname"
interface that loaded keys and policy from reasonable defaults might be
a useful interface for ldns to have, but we'd need to get that added,
and then we could use it when compiled against a recent enough version
-- in the meantime, the only way we can get a working ldns library on
OSX is to load the keys with ldns_resolver_push_dnssec_anchor(), and
"fixing" the existing ldns interface would really break current users
of it.

-- 
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=2119

--- Comment #5 from Damien Miller <djm at mindrot.org> ---
Are these trusted-key.key files a standard or documented somewhere?

-- 
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=2119

--- Comment #6 from Mantas M. <grawity at gmail.com> ---
(In reply to Damien Miller from comment #5)
> Are these trusted-key.key files a standard or documented somewhere?
The location isn't quite standard, just a BIND9 default. The *format*
is the same as "zonefile" format for DNSKEY or DS records (so ldns
already has a parser for those).

The sad part is, ldns already allows the path to be set at compile time
and Arch even compiles it with
"--with-trust-anchor=/etc/trusted-key.key"... but it only applies to
CLI tools like `drill`, and not the library itself.

-- 
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=2119

sergio <sergio+it at outerface.net> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |sergio+it at outerface.net

--- Comment #7 from sergio <sergio+it at outerface.net> ---
The other side of this bus is a serious security, as ad flag can be
spoofed:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=618863

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