<div dir="ltr">What you clarified is that the participation in the chain does not expose intermediate systems or the authority to a risk. Its the subsequent processing in the glibc getaddrinfo() call which is the leak, not handling the information along the chain.<div><br></div><div>We're solely talking about a risk to the client, end system, which invoked the call.</div><div><br></div><div>NAT home routers are only broken if they emit a call locally to getaddrinfo() and have a low bar Linux system to be broken into. But then they have your home router.</div><div><br></div><div>Servers outside of the DNS ecology get broken by making them emit getaddrinfo() -not by participating in the DNS query chain in the middle. They are functionally clients in this model.</div><div><br>Servers inside the ecology get broken by making calls to getaddrinfo(). Same as above. If your resolver/authority can be driven to call getaddrinfo() the wrong way, you're as broken as a home consumer. But not because you were along a DNS path, because you were functionally acting like a client when you made the call.</div><div><br></div><div>-G</div></div><div class="gmail_extra"><br><div class="gmail_quote">On 24 February 2016 at 10:23, Mark Andrews <span dir="ltr"><<a href="mailto:marka@isc.org" target="_blank">marka@isc.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
In message <CAA=nHSLvy=<a href="mailto:L3cMA8DKtPm1VgZr74N9ysk4vVg6kC-shZ29ChQQ@mail.gmail.com">L3cMA8DKtPm1VgZr74N9ysk4vVg6kC-shZ29ChQQ@mail.gmail.com</a>><br>
<span class="">, George Michaelson writes:<br>
><br>
> possibly silly Q. apologies if this is well understood and covered.<br>
><br>
> given [client] -> [resolver A] -> [resolver B] -> [resolver C] -><br>
> [authority]<br>
><br>
> who gets broken into and why?<br>
<br>
</span>The client. That is the entity calling getaddrinfo.<br>
<span class=""><br>
> given [client] -> [8.8.8.8] -> [authority]<br>
><br>
> who gets broken into and why?<br>
<br>
</span>The client. That is the entity calling getaddrinfo.<br>
<br>
getaddrinfo is dying on well formed DNS responses. Intermediate<br>
resolvers aren't designed to protect you from well formed DNS<br>
responses to queries initiated from the client. They should protect<br>
you from malformed DNS responses which is one of the design goals<br>
of BIND. getaddrinfo should also protect you from both well formed<br>
and malformed DNS responses but in this case it doesn't though it<br>
is attempting to. Bugs happen.<br>
<br>
Mark<br>
<span class=""><br>
> [client] is assumed to be { [client], [client] -> [NAT/Router DNS agent] }<br>
><br>
> -G<br>
><br>
> On 24 February 2016 at 09:34, Robert Edmonds <<a href="mailto:edmonds@mycre.ws">edmonds@mycre.ws</a>> wrote:<br>
><br>
> > Mukund Sivaraman wrote:<br>
> > > Assuming the 2nd message overflows on the stack and overwrites the<br>
> > > return address suitably,<br>
> ><br>
> > Once the attacker controls the instruction pointer, it's game over.<br>
> ><br>
> > --<br>
> > Robert Edmonds<br>
> > _______________________________________________<br>
> > dns-operations mailing list<br>
> > <a href="mailto:dns-operations@lists.dns-oarc.net">dns-operations@lists.dns-oarc.net</a><br>
> > <a href="https://lists.dns-oarc.net/mailman/listinfo/dns-operations" rel="noreferrer" target="_blank">https://lists.dns-oarc.net/mailman/listinfo/dns-operations</a><br>
> > dns-jobs mailing list<br>
> > <a href="https://lists.dns-oarc.net/mailman/listinfo/dns-jobs" rel="noreferrer" target="_blank">https://lists.dns-oarc.net/mailman/listinfo/dns-jobs</a><br>
> ><br>
><br>
</span>> --047d7b2e459c48e655052c75fa70<br>
> Content-Type: text/html; charset="UTF-8"<br>
> Content-Transfer-Encoding: quoted-printable<br>
><br>
> <div dir=3D"ltr">possibly silly Q. apologies if this is well understood and=<br>
> covered.<div><br></div><div>given [client] -> [resolver A] -> [resol=<br>
> ver B] -> [resolver C] -> [authority]</div><div><br></div><div>who ge=<br>
> ts broken into and why?</div><div><br></div><div>given [client] -> [8.8.=<br>
> 8.8] -> [authority]</div><div><br></div><div>who gets broken into and wh=<br>
> y?</div><div><br></div><div>[client] is assumed to be { [client], [client] =<br>
> -> [NAT/Router DNS agent] }</div><div><br></div><div>-G</div></div><div =<br>
> class=3D"gmail_extra"><br><div class=3D"gmail_quote">On 24 February 2016 at=<br>
> 09:34, Robert Edmonds <span dir=3D"ltr"><<a href=3D"mailto:<a href="mailto:edmonds@mycr">edmonds@mycr</a>=<br>
> <a href="http://e.ws" rel="noreferrer" target="_blank">e.ws</a>" target=3D"_blank"><a href="mailto:edmonds@mycre.ws">edmonds@mycre.ws</a></a>></span> wrote:<br><blockquo=<br>
> te class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc so=<br>
> lid;padding-left:1ex"><span class=3D"">Mukund Sivaraman wrote:<br><br>
> > Assuming the 2nd message overflows on the stack and overwrites the<br><br>
> > return address suitably,<br><br>
> <br><br>
> </span>Once the attacker controls the instruction pointer, it's game ov=<br>
> er.<br><br>
> <span class=3D"HOEnZb"><font color=3D"#888888"><br><br>
> --<br><br>
> Robert Edmonds<br><br>
> </font></span><div class=3D"HOEnZb"><div class=3D"h5">_____________________=<br>
> __________________________<br><br>
> dns-operations mailing list<br><br>
> <a href=3D"mailto:<a href="mailto:dns-operations@lists.dns-oarc.net">dns-operations@lists.dns-oarc.net</a>">dns-operations@lists.d=<br>
> <a href="http://ns-oarc.net" rel="noreferrer" target="_blank">ns-oarc.net</a></a><br><br>
> <a href=3D"<a href="https://lists.dns-oarc.net/mailman/listinfo/dns-operations" rel="noreferrer" target="_blank">https://lists.dns-oarc.net/mailman/listinfo/dns-operations</a><br>
> dns-jobs" rel=3D"noreferrer" target=3D"_blank"><a href="https://lists.dns-oarc.net/m=" rel="noreferrer" target="_blank">https://lists.dns-oarc.net/m=</a><br>
> ailman/listinfo/dns-operations<br><br>
> dns-jobs</a> mailing list<br><br>
> <a href=3D"<a href="https://lists.dns-oarc.net/mailman/listinfo/dns-jobs" rel="noreferrer" target="_blank">https://lists.dns-oarc.net/mailman/listinfo/dns-jobs</a>" rel=3D"nor=<br>
> eferrer" target=3D"_blank"><a href="https://lists.dns-oarc.net/mailman/listinfo/dns-=" rel="noreferrer" target="_blank">https://lists.dns-oarc.net/mailman/listinfo/dns-=</a><br>
> jobs</a><br><br>
> </div></div></blockquote></div><br></div><br>
><br>
> --047d7b2e459c48e655052c75fa70--<br>
><br>
> --===============7144437757527182240==<br>
> Content-Type: text/plain; charset="us-ascii"<br>
> MIME-Version: 1.0<br>
> Content-Transfer-Encoding: 7bit<br>
> Content-Disposition: inline<br>
<span class="">><br>
> _______________________________________________<br>
> dns-operations mailing list<br>
> <a href="mailto:dns-operations@lists.dns-oarc.net">dns-operations@lists.dns-oarc.net</a><br>
> <a href="https://lists.dns-oarc.net/mailman/listinfo/dns-operations" rel="noreferrer" target="_blank">https://lists.dns-oarc.net/mailman/listinfo/dns-operations</a><br>
> dns-jobs mailing list<br>
> <a href="https://lists.dns-oarc.net/mailman/listinfo/dns-jobs" rel="noreferrer" target="_blank">https://lists.dns-oarc.net/mailman/listinfo/dns-jobs</a><br>
</span>> --===============7144437757527182240==--<br>
<span class="HOEnZb"><font color="#888888">--<br>
Mark Andrews, ISC<br>
1 Seymour St., Dundas Valley, NSW 2117, Australia<br>
PHONE: <a href="tel:%2B61%202%209871%204742" value="+61298714742">+61 2 9871 4742</a> INTERNET: <a href="mailto:marka@isc.org">marka@isc.org</a><br>
</font></span></blockquote></div><br></div>