[dns-operations] CVE-2015-7547: glibc getaddrinfo buffer overflow

Tue Feb 23 21:28:42 UTC 2016

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.

We're solely talking about a risk to the client, end system, which invoked
the call.

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.

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.

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.

-G

On 24 February 2016 at 10:23, Mark Andrews <marka at isc.org> wrote:

>
> In message <CAA=nHSLvy=
> L3cMA8DKtPm1VgZr74N9ysk4vVg6kC-shZ29ChQQ at mail.gmail.com>
> , George Michaelson writes:
> >
> > possibly silly Q. apologies if this is well understood and covered.
> >
> > given [client] -> [resolver A] -> [resolver B] -> [resolver C] ->
> > [authority]
> >
> > who gets broken into and why?
>
> The client.  That is the entity calling getaddrinfo.
>
> > given [client] -> [8.8.8.8] -> [authority]
> >
> > who gets broken into and why?
>
> The client.  That is the entity calling getaddrinfo.
>
> getaddrinfo is dying on well formed DNS responses.  Intermediate
> resolvers aren't designed to protect you from well formed DNS
> responses to queries initiated from the client.  They should protect
> you from malformed DNS responses which is one of the design goals
> of BIND.  getaddrinfo should also protect you from both well formed
> and malformed DNS responses but in this case it doesn't though it
> is attempting to.  Bugs happen.
>
> Mark
>
> > [client] is assumed to be { [client], [client] -> [NAT/Router DNS agent]
> }
> >
> > -G
> >
> > On 24 February 2016 at 09:34, Robert Edmonds <edmonds at mycre.ws> wrote:
> >
> > > Mukund Sivaraman wrote:
> > > > Assuming the 2nd message overflows on the stack and overwrites the
> > > > return address suitably,
> > >
> > > Once the attacker controls the instruction pointer, it's game over.
> > >
> > > --
> > > Robert Edmonds
> > > _______________________________________________
> > > dns-operations mailing list
> > > dns-operations at lists.dns-oarc.net
> > > https://lists.dns-oarc.net/mailman/listinfo/dns-operations
> > > dns-jobs mailing list
> > > https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
> > >
> >
> > --047d7b2e459c48e655052c75fa70
> > Content-Type: text/html; charset="UTF-8"
> > Content-Transfer-Encoding: quoted-printable
> >
> > <div dir=3D"ltr">possibly silly Q. apologies if this is well understood
> and=
> >  covered.<div><br></div><div>given [client] -> [resolver A] ->
> [resol=
> > ver B] -> [resolver C] -> [authority]</div><div><br></div><div>who
> ge=
> > ts broken into and why?</div><div><br></div><div>given [client] ->
> [8.8.=
> > 8.8] -> [authority]</div><div><br></div><div>who gets broken into and
> wh=
> > y?</div><div><br></div><div>[client] is assumed to be { [client],
> [client] =
> > -> [NAT/Router DNS agent]
> }</div><div><br></div><div>-G</div></div><div =
> > class=3D"gmail_extra"><br><div class=3D"gmail_quote">On 24 February 2016
> at=
> >  09:34, Robert Edmonds <span dir=3D"ltr"><<a href=3D"mailto:
> edmonds at mycr=
> > e.ws" target=3D"_blank">edmonds at mycre.ws</a>></span>
> wrote:<br><blockquo=
> > te class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc
> so=
> > lid;padding-left:1ex"><span class=3D"">Mukund Sivaraman wrote:<br>
> > > Assuming the 2nd message overflows on the stack and overwrites
> the<br>
> > > return address suitably,<br>
> > <br>
> > </span>Once the attacker controls the instruction pointer, it's game
> ov=
> > er.<br>
> > <span class=3D"HOEnZb"><font color=3D"#888888"><br>
> > --<br>
> > Robert Edmonds<br>
> > </font></span><div class=3D"HOEnZb"><div
> class=3D"h5">_____________________=
> > __________________________<br>
> > dns-operations mailing list<br>
> > <a href=3D"mailto:dns-operations at lists.dns-oarc.net
> ">dns-operations at lists.d=
> > ns-oarc.net</a><br>
> > <a href=3D"https://lists.dns-oarc.net/mailman/listinfo/dns-operations
> > dns-jobs" rel=3D"noreferrer" target=3D"_blank">
> https://lists.dns-oarc.net/m=
> > ailman/listinfo/dns-operations<br>
> > dns-jobs</a> mailing list<br>
> > <a href=3D"https://lists.dns-oarc.net/mailman/listinfo/dns-jobs"
> rel=3D"nor=
> > eferrer" target=3D"_blank">
> https://lists.dns-oarc.net/mailman/listinfo/dns-=
> > jobs</a><br>
> > </div></div></blockquote></div><br></div>
> >
> > --047d7b2e459c48e655052c75fa70--
> >
> > --===============7144437757527182240==
> > Content-Type: text/plain; charset="us-ascii"
> > MIME-Version: 1.0
> > Content-Transfer-Encoding: 7bit
> > Content-Disposition: inline
> >
> > _______________________________________________
> > dns-operations mailing list
> > dns-operations at lists.dns-oarc.net
> > https://lists.dns-oarc.net/mailman/listinfo/dns-operations
> > dns-jobs mailing list
> > https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
> > --===============7144437757527182240==--
> --
> Mark Andrews, ISC
> 1 Seymour St., Dundas Valley, NSW 2117, Australia
> PHONE: +61 2 9871 4742                 INTERNET: marka at isc.org
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.dns-oarc.net/pipermail/dns-operations/attachments/20160224/0dba1ca8/attachment.html>