From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-2.9 required=5.0 tests=DKIM_ADSP_CUSTOM_MED, DKIM_INVALID,DKIM_SIGNED,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,HTML_MESSAGE,MAILING_LIST_MULTI, RCVD_IN_DNSWL_MED,RCVD_IN_MSPIKE_H4,RCVD_IN_MSPIKE_WL, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.4 Received: from second.openwall.net (second.openwall.net [193.110.157.125]) by inbox.vuxu.org (Postfix) with SMTP id C6D292162E for ; Fri, 8 Mar 2024 22:55:45 +0100 (CET) Received: (qmail 8016 invoked by uid 550); 8 Mar 2024 21:51:40 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Reply-To: musl@lists.openwall.com Received: (qmail 7980 invoked from network); 8 Mar 2024 21:51:40 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1709934930; x=1710539730; darn=lists.openwall.com; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=qdDc3SnqVg9i63hoiO/wjKIWdXaTCQdZshR2rLBnlsQ=; b=jAJHdRPrfa6gY7uhhp9Uv+0832kb33IatoW+eJIxrSNO9ydYMkYtfkn1L8O6WMfmmA MkPaMwFJCi8Ffvvx4j4Excw8CkSUpmYIouUBCzegARHtS0BovLRkmVCM5QG6Iag66JLu 15paKa88n5/NzvoK8pOaDT2JBv8jSOGrXLRgoNkXrBgGfW52SOk38eXNBW9OVIy9Ln2U HqIrdwChMfBZEEOzsSwAPytAolyC3wEcMWlbQRW+JK+z8s7CHNrf2zu4gt+Jf96YSAZ3 h7EmUKzsvfcwE08Z3w4zi11SaX7GLOJGyP2DVfVUsUtxMrxWQg4VKogfb3zblHypN2Od fZ3Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1709934930; x=1710539730; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=qdDc3SnqVg9i63hoiO/wjKIWdXaTCQdZshR2rLBnlsQ=; b=ihgM8bO3TQVa0uebESjX0sayQ4REuSTdp2BeLCX/GyeEpd8MNv/U64NYce2saPw5L9 QN2UCor0d1MDQZSdlqtlW/RwibE8j9sRjCevI0WMOBTbzNU5MPXpC90Q6/HOPSv1HHs1 CohWjIXcVsdsHdllFrhwp4oVG+G4Nl5aXt6AM7LgIwiqIAGsMm2ZLv/i9c/Y14ezmn82 H6phlLE8fms+apwY3MSHwdzaipM8jKxYWVHySrpOQxedBuiIVjp1j9BK2Zbzc5a5fklh iG4iPwLzXjrbwDY1XErFEN24fPx3aD9kf4Jb4qhyOWwA6rwuZSgXDQGv06cBSC7l6nxa b+oQ== X-Gm-Message-State: AOJu0YzIG7tB/Szoaxbp21/a7UmDF0/MxRWTSNpbbmX5dGgpstIl6UyC 1fXZ6ShepXCHMjABJs4IgeEQWhToTQ8TshTOjovEKtZXmAdt6MUfmdy6ZsXrCs2IocuFxGovJN4 29XhRoth1KOb/QLyJ2Ud2xSjbtCeMRnrBM5Q= X-Google-Smtp-Source: AGHT+IHEoQebKZFyfEzApTs6RRfPrSS6tTtugF1+8YR9E1E1UBy2Fs+v2Oz9IiW6lRoFwX1xm7xJC+9r/sLVJZ0Cfso= X-Received: by 2002:ac2:4907:0:b0:512:b696:e312 with SMTP id n7-20020ac24907000000b00512b696e312mr173324lfi.46.1709934930059; Fri, 08 Mar 2024 13:55:30 -0800 (PST) MIME-Version: 1.0 References: <20240307024316.GI4163@brightrain.aerifal.cx> <20240308000818.GJ4163@brightrain.aerifal.cx> <20240308025204.GK4163@brightrain.aerifal.cx> <20240308034740.GL4163@brightrain.aerifal.cx> <20240308133102.GN4163@brightrain.aerifal.cx> <20240308203143.GQ4163@brightrain.aerifal.cx> In-Reply-To: <20240308203143.GQ4163@brightrain.aerifal.cx> From: David Schinazi Date: Fri, 8 Mar 2024 13:55:18 -0800 Message-ID: To: Rich Felker Cc: musl@lists.openwall.com Content-Type: multipart/alternative; boundary="000000000000186bb006132d4076" Subject: Re: [musl] mDNS in musl --000000000000186bb006132d4076 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Fri, Mar 8, 2024 at 12:31=E2=80=AFPM Rich Felker wrote= : > On Fri, Mar 08, 2024 at 11:15:52AM -0800, David Schinazi wrote: > > On Fri, Mar 8, 2024 at 5:30=E2=80=AFAM Rich Felker wr= ote: > > > > > On Thu, Mar 07, 2024 at 08:47:20PM -0800, David Schinazi wrote: > > > > Thanks. How would you feel about the following potential > configuration > > > > design? > > > > * Add a new configuration option "send_mdns_unicast" > > > > * When true, use the current behavior > > > > * When false, send the query on all non-loopback non-p2p interfaces > > > > * Have send_mdns_unicast default to false > > > > > > > > I was thinking through how to pick interfaces, looked up what other > mDNS > > > > libraries do, and pretty much all of them don't allow configuring > > > > interfaces, whereas Avahi exposes allow-interfaces and > deny-interfaces. > > > I'm > > > > leaning towards not making this configurable to reduce complexity. = I > > > think > > > > that anyone interested in that level of config is probably using > Avahi > > > > anyway. > > > > > > > > Additionally this design has two nice properties: the default > behavior is > > > > RFC-compliant, and it means that for my use-case I don't need to > change > > > the > > > > config file, which was a big part of my motivation for doing this > inside > > > of > > > > musl in the first place :-) > > > > > > As discussed in this thread, I don't think so. The biggest problems I > > > initially brought up were increased information leakage in the defaul= t > > > configuration and inability to control where the traffic goes when yo= u > > > do want it on. The above proposal just reverts to the initial, except > > > for providing a way to opt-out. > > > > > > For the most part, mDNS is very much a "home user, personal device on > > > trusted network" thing. Not only do you not want it to default on > > > because a lot of systems will be network servers on networks where > > > it's not meaningful (and can be a weakness that aids attackers in > > > lateral movement), but you also don't want it on when connected to > > > public wifi. For example if you have an open browser tab to > > > http://mything.local, and migrate to an untrusted network (with your > > > laptop, tablet, phone, whatever), now your browser will be leaking > > > private data (likely at least session auth tokens, maybe more) to > > > whoever answers the mDNS query for mything.local. > > > > That's not quite right. The security properties of mDNS and DNS are the > > same. DNS is inherently insecure, regardless of unicast vs multicast. I= f > > I'm on a coffee shop Wi-Fi, all my DNS queries are sent in the clear to > > whatever IP address the DHCP server gave me. > > That's not the case. Connections to non-mDNS hosts are authenticated > by TLS with certificates issued on the basis of ownership of the > domain name. That's not possible with mDNS hostnames, so they'll > either be no-TLS or self-signed certs. That's why the above attack is > possible. It was also possible with normal DNS in the bad old days of > http://, but that time is long gone. > Apologies for being pedantic, but that's not true. The ability to get TLS certificates for a domain name that you own is a property of the WebPKI, not a property of TLS. What you wrote is true, but only in the context of a Web browser with an unmodified root certificate store. The features I mentioned above don't use the WebPKI, they have a separate root of trust. For example, some of those Apple features exchange TLS certificates via an out-of-band mechanism such as Apple trusted servers. Another example is the Apple Watch: when you first pair a new Apple Watch with an iPhone, they exchange ed25519 public keys. Then any time the watch wants to transfer a large file to/from the phone, it'll connect to Wi-Fi, use mDNS to find the phone, and set up an IKEv2/IPsec tunnel that then protects the exchange. It's resilient to any attacks at the mDNS level. You're absolutely right that the security of Web requests using local connectivity is completely broken by the lack of WebPKI certificates for those. But sending the DNS query over multicast as opposed to unencrypted unicast to an untrusted DNS server doesn't change the security properties. In your example above, the open tab to http://mything.local will send that query to the recursive resolver - and if that's the one received by DHCP then that server can reply with its own address and receive your auth tokens. One potential fix here is to configure your resolv.conf to localhost and then apply policy in that local resolver. But in practice, application developers don't rely on security at that layer, they assume that DNS is unsafe and implement encryption in userspace with some out of band trust mechanism. > So the stack has to deal with > > the fact that any DNS response can be spoofed. > > That's also not possible with DNSSEC, but only helps if you're > validating it. > > > The most widely used > > solution is TLS: a successful DNS hijack can prevent you from accessing= a > > TLS service, but can't impersonate it. That's true of both mDNS and > regular > > unicast DNS. As an example, all Apple devices have mDNS enabled on all > > interfaces, with no security impact - the features that rely on it > > (AirDrop, AirPlay, contact sharing, etc) all use mTLS to ensure they're > > talking to the right device regardless of the correctness of DNS. > (Printing > > remains completely insecure, but that's also independent of DNS - your > > coffee shop Wi-Fi access point can attack you at the IP layer too). One > > might think that DNSSEC could save us here, but it doesn't. DNSSEC was > > unfortunately built with a fundamental design flaw: it requires you to > > trust all resolvers on the path, including recursive resolvers. So even > if > > you ask for DNSSEC validation of the DNS records for www.example.com, > your > > coffee shop DNS recursive resolver can tell you "I checked, and > example.com > > does not support DNSSEC, here's the IP address for www.example.com > though" > > and you have to accept it. > > This is a completely false but somehow persistent myth about DNSSEC. > You cannot lie that a zone does not support DNSSEC. The only way to > claim a zone does not support DNSSEC is with a signature chain from > the DNS root proving the nonexistence of the DS records for the > delegation. Without that, the reply is BOGUS and will be ignored as if > there was no reply at all. > I was talking about the case where the recursive resolver does the validation, which is what's deployed in practice today. What you wrote is only true if the client does the DNSSEC validation itself. Most clients don't do that today, because too many domains are just misconfigured and broken. Eric Rescorla (the editor of the TLS RFCs) wrote a great blog post about this: https://educatedguesswork.org/posts/dns-security-dnssec/#validation-at-the-= endpoint-versus-the-recursive > > Windows has a setting when you add wifi networks for whether they're > > > treated as private/trusted or public. I would guess it controls > > > whether mDNS is used, among other things like SMB scanning or > > > whatever. The same really belongs in a network configurator for > > > Linux-based personal devices. > > > > > > Fortunately, I think an approach where you opt-in particular > > > interfaces/source-addresses, rather than send everywhere by default, > > > has lower implementation cost and complexity on top of being the safe > > > thing to do. So none of the above should be taken as a "no" for the > > > functionality, just a no for "on by default and send everywhere". > > > > > > > And that's totally fair. If your argument is that "defaults should > reflect > > the previous behavior", then I can't argue. That said, I disagree that > this > > is measurably safer. > > Per above, your disagreement seems to be based at least in part on > misinformation. > There are many topics that I am incredibly under-informed or misinformed on. And to be honest, the intricacies of the Linux kernel syscall API is definitely one of them. Internet standards as they relate to security and DNS though, I do know a few things about. It's kind of my job :-) > > Regarding untrusted networks, one thing I hadn't considered yet is > > > that a network configurator probably needs a way to setup resolv.conf > > > such that .local queries temp-fail rather than perma-fail (as they > > > would if you just sent the query to public dns) to use during certain > > > race windows while switching networks. IOW "send .local queries to > > > configured nameservers" and "treat .local specially but with an empty > > > list of interfaces to send to" should be distinct configurations. > > > > Yeah, caching negative results in DNS has been a tricky thing from the > > start. You probably could hack something by installing a fake SOA recor= d > > for .local. in your recursive resolver running on localhost. But the > > RFC-compliant answer is for stub resolvers to treat it specially and kn= ow > > that those often never get an answer (musl doesn't cache DNS results so > in > > a way we're avoiding this problem altogether at the stub resolver). > > The problem here is not about caching, just about clients using a > response. You want a task (like a browser with open tabs) trying to > contact the site to get a tempfail rather than NxDomain which might > make it stop trying. But you probably want NxDomain if mDNS has been > disabled entirely, so that every .local lookup doesn't hang 5 seconds > or whatever before saying "inconclusive". > I'm assuming that by tempfail you mean EAI_AGAIN. The two browsers that I've written code in don't use that (Chrome just treats it the same as a resolution failure and will automatically refresh the tab on a network change; Safari doesn't use getaddrinfo and instead relies on an asynchronous DNS API that adds results as they come in - I wrote that algorithm up in RFC 8305). All that said, synchronous blocking APIs like getaddrinfo need to eventually return even if no one replies, so EAI_AGAIN makes sense in that case - whereas if .local is blocked by policy then immediately returning EAI_NONAME is best. David --000000000000186bb006132d4076 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Fri, Mar 8, 2024 at 12:31=E2=80=AF= PM Rich Felker <dalias@libc.org&g= t; wrote:
On Fri= , Mar 08, 2024 at 11:15:52AM -0800, David Schinazi wrote:
> On Fri, Mar 8, 2024 at 5:30=E2=80=AFAM Rich Felker <dalias@libc.org> wrote:
>
> > On Thu, Mar 07, 2024 at 08:47:20PM -0800, David Schinazi wrote: > > > Thanks. How would you feel about the following potential con= figuration
> > > design?
> > > * Add a new configuration option "send_mdns_unicast&quo= t;
> > > * When true, use the current behavior
> > > * When false, send the query on all non-loopback non-p2p int= erfaces
> > > * Have send_mdns_unicast default to false
> > >
> > > I was thinking through how to pick interfaces, looked up wha= t other mDNS
> > > libraries do, and pretty much all of them don't allow co= nfiguring
> > > interfaces, whereas Avahi exposes allow-interfaces and deny-= interfaces.
> > I'm
> > > leaning towards not making this configurable to reduce compl= exity. I
> > think
> > > that anyone interested in that level of config is probably u= sing Avahi
> > > anyway.
> > >
> > > Additionally this design has two nice properties: the defaul= t behavior is
> > > RFC-compliant, and it means that for my use-case I don't= need to change
> > the
> > > config file, which was a big part of my motivation for doing= this inside
> > of
> > > musl in the first place :-)
> >
> > As discussed in this thread, I don't think so. The biggest pr= oblems I
> > initially brought up were increased information leakage in the de= fault
> > configuration and inability to control where the traffic goes whe= n you
> > do want it on. The above proposal just reverts to the initial, ex= cept
> > for providing a way to opt-out.
> >
> > For the most part, mDNS is very much a "home user, personal = device on
> > trusted network" thing. Not only do you not want it to defau= lt on
> > because a lot of systems will be network servers on networks wher= e
> > it's not meaningful (and can be a weakness that aids attacker= s in
> > lateral movement), but you also don't want it on when connect= ed to
> > public wifi. For example if you have an open browser tab to
> > http://mything.local, and migrate to an untrusted network (with yo= ur
> > laptop, tablet, phone, whatever), now your browser will be leakin= g
> > private data (likely at least session auth tokens, maybe more) to=
> > whoever answers the mDNS query for mything.local.
>
> That's not quite right. The security properties of mDNS and DNS ar= e the
> same. DNS is inherently insecure, regardless of unicast vs multicast. = If
> I'm on a coffee shop Wi-Fi, all my DNS queries are sent in the cle= ar to
> whatever IP address the DHCP server gave me.

That's not the case. Connections to non-mDNS hosts are authenticated by TLS with certificates issued on the basis of ownership of the
domain name. That's not possible with mDNS hostnames, so they'll either be no-TLS or self-signed certs. That's why the above attack is possible. It was also possible with normal DNS in the bad old days of
http://, but that time is long gone.

Ap= ologies for being pedantic, but that's not true. The ability to get TLS= certificates for a domain name that you own is a property of the WebPKI, n= ot a property of TLS. What you wrote is true, but only in the context of a = Web browser with an unmodified root certificate store. The features I menti= oned above don't use the WebPKI, they have a separate root of trust. Fo= r example, some of those Apple features exchange TLS certificates via an ou= t-of-band mechanism such as Apple trusted servers. Another example is the A= pple Watch: when you first pair a new Apple Watch with an iPhone, they exch= ange ed25519 public keys. Then any time the watch wants to transfer a large= file to/from the phone, it'll connect to Wi-Fi, use mDNS to find the p= hone, and set up an IKEv2/IPsec tunnel that then protects the exchange. It&= #39;s resilient to any attacks at the mDNS level.

= You're absolutely right that the security of Web requests using local c= onnectivity is completely broken by the lack of WebPKI certificates for tho= se. But sending the DNS query over multicast as opposed to unencrypted unic= ast to an untrusted DNS server doesn't change the security properties. = In your example above, the open tab to htt= p://mything.local will send that query to the recursive resolver - and = if that's the one received by DHCP then that server can reply with its = own address and receive your auth tokens. One potential fix here is to conf= igure your resolv.conf to localhost and then apply policy in that local res= olver. But in practice, application developers don't rely on security a= t that layer, they assume that DNS is unsafe and implement encryption in us= erspace with some out of band trust mechanism.

> So the stack has to deal with
> the fact that any DNS response can be spoofed.

That's also not possible with DNSSEC, but only helps if you're
validating it.

> The most widely used
> solution is TLS: a successful DNS hijack can prevent you from accessin= g a
> TLS service, but can't impersonate it. That's true of both mDN= S and regular
> unicast DNS. As an example, all Apple devices have mDNS enabled on all=
> interfaces, with no security impact - the features that rely on it
> (AirDrop, AirPlay, contact sharing, etc) all use mTLS to ensure they&#= 39;re
> talking to the right device regardless of the correctness of DNS. (Pri= nting
> remains completely insecure, but that's also independent of DNS - = your
> coffee shop Wi-Fi access point can attack you at the IP layer too). On= e
> might think that DNSSEC could save us here, but it doesn't. DNSSEC= was
> unfortunately built with a fundamental design flaw: it requires you to=
> trust all resolvers on the path, including recursive resolvers. So eve= n if
> you ask for DNSSEC validation of the DNS records for www.example.com,= your
> coffee shop DNS recursive resolver can tell you "I checked, and <= a href=3D"http://example.com" rel=3D"noreferrer" target=3D"_blank">example.= com
> does not support DNSSEC, here's the IP address for www.example.com though"
> and you have to accept it.

This is a completely false but somehow persistent myth about DNSSEC.
You cannot lie that a zone does not support DNSSEC. The only way to
claim a zone does not support DNSSEC is with a signature chain from
the DNS root proving the nonexistence of the DS records for the
delegation. Without that, the reply is BOGUS and will be ignored as if
there was no reply at all.

I was talkin= g about the case where the recursive resolver does the validation, which is= what's deployed in practice today. What you wrote is only true if the = client does the DNSSEC validation itself. Most clients don't do that to= day, because too many domains are just misconfigured and broken. Eric Resco= rla (the editor of the TLS RFCs) wrote a great blog post about this:
<= div>

> > Windows has a setting when you add wifi networks for whether they= 're
> > treated as private/trusted or public. I would guess it controls > > whether mDNS is used, among other things like SMB scanning or
> > whatever. The same really belongs in a network configurator for > > Linux-based personal devices.
> >
> > Fortunately, I think an approach where you opt-in particular
> > interfaces/source-addresses, rather than send everywhere by defau= lt,
> > has lower implementation cost and complexity on top of being the = safe
> > thing to do. So none of the above should be taken as a "no&q= uot; for the
> > functionality, just a no for "on by default and send everywh= ere".
> >
>
> And that's totally fair. If your argument is that "defaults s= hould reflect
> the previous behavior", then I can't argue. That said, I disa= gree that this
> is measurably safer.

Per above, your disagreement seems to be based at least in part on
misinformation.

There are many topics t= hat I am incredibly=C2=A0under-informed=C2=A0or misinformed on. And to be h= onest, the intricacies of the Linux kernel syscall API is definitely one of= them. Internet standards as they relate to security and DNS though, I do k= now a few things about. It's kind of my job :-)

> > Regarding untrusted networks, one thing I hadn't considered y= et is
> > that a network configurator probably needs a way to setup resolv.= conf
> > such that .local queries temp-fail rather than perma-fail (as the= y
> > would if you just sent the query to public dns) to use during cer= tain
> > race windows while switching networks. IOW "send .local quer= ies to
> > configured nameservers" and "treat .local specially but= with an empty
> > list of interfaces to send to" should be distinct configurat= ions.
>
> Yeah, caching negative results in DNS has been a tricky thing from the=
> start. You probably could hack something by installing a fake SOA reco= rd
> for .local. in your recursive resolver running on localhost. But the > RFC-compliant answer is for stub resolvers to treat it specially and k= now
> that those often never get an answer (musl doesn't cache DNS resul= ts so in
> a way we're avoiding this problem altogether at the stub resolver)= .

The problem here is not about caching, just about clients using a
response. You want a task (like a browser with open tabs) trying to
contact the site to get a tempfail rather than NxDomain which might
make it stop trying. But you probably want NxDomain if mDNS has been
disabled entirely, so that every .local lookup doesn't hang 5 seconds or whatever before saying "inconclusive".
I'm assuming that by tempfail you mean=C2=A0EAI_AGAIN. The= two browsers that I've written code in don't use that (Chrome just= treats it the same as a resolution failure and will automatically=C2=A0ref= resh the tab on a network change; Safari doesn't use getaddrinfo and in= stead relies on an asynchronous DNS API that adds results as they come in -= I wrote that algorithm up in RFC 8305). All that said, synchronous blockin= g APIs like getaddrinfo need to eventually return even if no one replies, s= o EAI_AGAIN makes sense in that case - whereas if .local is blocked by poli= cy then immediately returning EAI_NONAME is best.

= David
--000000000000186bb006132d4076--