Re: CVE-2015-7547: getaddrinfo() stack-based buffer overflow

[Florian Weimer]

* Mark Andrews:

> And the best way to deal with this is to have manufacturers update
> https://www.kb.cert.org/vuls/id/457759 with their status.  Yes it
> should be a much bigger list than what is there.  Every IoT vendor.
> Every router vendor.  Every OS vendor.  Yes, ISC needs to put in a
> offical status.  If you have a internet connected product and the
> manufacture is not on the list, contact the manufacture and ask
> them to provide a status update.

The real challenge are the vendors who do not realize they are
embedding a copy of glibc in their product.  I'm sure they exist.

> The list may have a lot of "affected if run on a vulnerable OS"
> responses.  For most of these the solution will be "fix the OS,
> relink if statically linked, and reboot the machine".

Static linking is less of a concern, for once.  The reason is that you
need to jump through very special hoops to get a statically linked
copy of nss_dns which uses a statically linked copy of libresolv.
Regular distribution builds for static linking use static dlopen to
dynamically link the required NSS libraries.  Due to some
implementation details, such statically linked binaries are not very
portable between different glibc versions, and there's a clear warning
at static link time that you need the DSOs for the same glibc version
you are statically linking against at run time.
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: CVE-2015-7547: getaddrinfo() stack-based buffer overflow

[Mark Andrews]

In message <87io1nrw2k@mid.deneb.enyo.de>, Florian Weimer writes:
> * Alan Clegg:
> 
> > While I agree that the "major distributions" (and even the minor ones) are
> > getting patches out, I'd like to point out something that Alan Cox posted
> > over on G+:
> >
> > "You can upgrade all your servers but if that little cheapo plastic box on
> > your network somewhere has a vulnerable post 2008 glibc and ever does DNS
> > lookups chances are it's the equivalent of a trapdoor into your network."
> >
> > https://plus.google.com/+AlanClegg/posts/R1UkJjHMMB6
> 
> glibc is usually considered way too bloated for use in embedded devices.
> I'm sure there are some uses in this space, but glibc is probably not
> a relevant player in this field.
> 
> That being said, there are apparently supported glibc ports to
> Android, specifically for running mostly unported GNU/Linux
> applications on top of Android devices (applications which do not work
> with Android's native Bionic libc, which is not affected by this
> issue).

And the best way to deal with this is to have manufacturers update
https://www.kb.cert.org/vuls/id/457759 with their status.  Yes it
should be a much bigger list than what is there.  Every IoT vendor.
Every router vendor.  Every OS vendor.  Yes, ISC needs to put in a
offical status.  If you have a internet connected product and the
manufacture is not on the list, contact the manufacture and ask
them to provide a status update.

The list may have a lot of "affected if run on a vulnerable OS"
responses.  For most of these the solution will be "fix the OS,
relink if statically linked, and reboot the machine".  The last
step is important as it ensures that you are using the new library
in all products on the machine.

Mark
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: CVE-2015-7547: getaddrinfo() stack-based buffer overflow

[Florian Weimer]

* Alan Clegg:

> While I agree that the "major distributions" (and even the minor ones) are
> getting patches out, I'd like to point out something that Alan Cox posted
> over on G+:
>
> "You can upgrade all your servers but if that little cheapo plastic box on
> your network somewhere has a vulnerable post 2008 glibc and ever does DNS
> lookups chances are it's the equivalent of a trapdoor into your network."
>
> https://plus.google.com/+AlanClegg/posts/R1UkJjHMMB6

glibc is usually considered way too bloated for use in embedded devices.
I'm sure there are some uses in this space, but glibc is probably not
a relevant player in this field.

That being said, there are apparently supported glibc ports to
Android, specifically for running mostly unported GNU/Linux
applications on top of Android devices (applications which do not work
with Android's native Bionic libc, which is not affected by this
issue).
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: CVE-2015-7547: getaddrinfo() stack-based buffer overflow

[Florian Weimer]

* Ben Croswell:

> Cyber folks asked if there was any way for the DNS servers to "protect" the
> vulnerable clients.
> The only thing i  could see from the explanation  was disabling or limiting
> edns0 sizes. That is obviously not a long term option.

EDNS0 buffer sizes do not apply to TCP responses, so this is not an
effective mitigation, I'm afraid.
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: CVE-2015-7547: getaddrinfo() stack-based buffer overflow

[G.W. Haywood]

Hi there,

On Wed, 17 Feb 2016, Dominique Jullier wrote:


Are they any thoughts around, how to handle yesterday's glibc
vulnerability[1][2] from the side bind?


This is a glibc issue, not a bind issue.  It makes no sense to attempt
to fix the problem by modifying bind.  Firstly, bind is not the only
software which may call glibc's getaddrinfo() function in a way which
could permit exploitation, and secondly, a 'sticking plaster' fix is
likely to come unstuck anyway.


Since it is a rather painful task in order to update all hosts ...


I fear that there's no alternative.

--

73,
Ged.
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: CVE-2015-7547: getaddrinfo() stack-based buffer overflow

[Ben Croswell]

Cyber folks asked if there was any way for the DNS servers to "protect" the
vulnerable clients.
The only thing i  could see from the explanation  was disabling or limiting
edns0 sizes. That is obviously not a long term option.
On Feb 17, 2016 11:39 AM, "Alan Clegg"  wrote:

> On 2/17/16, 11:34 AM, "Reindl Harald"  behalf of h.rei...@thelounge.net> wrote:
>
> >Am 17.02.2016 um 17:22 schrieb Dominique Jullier:
> >> Are they any thoughts around, how to handle yesterday's glibc
> >> vulnerability[1][2] from the side bind?
> >>
> >> Since it is a rather painful task in order to update all hosts to a new
> >> version of glibc, we were thinking about other possible workarounds
> >
> >Fedora, RHEL and Debian as well as likely all other relevant
> >distributions are providing a patched glibc - dunno what is "rather
> >painful" to apply a ordinary update like kernel security updates and
> >restart all network relevant processes or reboot
>
> While I agree that the "major distributions" (and even the minor ones) are
> getting patches out, I'd like to point out something that Alan Cox posted
> over on G+:
>
> "You can upgrade all your servers but if that little cheapo plastic box on
> your network somewhere has a vulnerable post 2008 glibc and ever does DNS
> lookups chances are it's the equivalent of a trapdoor into your network."
>
> https://plus.google.com/+AlanClegg/posts/R1UkJjHMMB6
>
> There does need to be something a bit deeper than "patch your servers"..
>
> AlanC
> >
>
>
> ___
> Please visit https://lists.isc.org/mailman/listinfo/bind-users to
> unsubscribe from this list
>
> bind-users mailing list
> bind-users@lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users
>
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

RE: CVE-2015-7547: getaddrinfo() stack-based buffer overflow

[John W. Blue]

I agree with Reindl, but (at the risk of this sounding bad) it also underscores 
why it is important to proactive in management of risk and change.

If you don't know what you don't know that is very risky behavior.  If there is 
a collective freak out on what to do to get something fixed regardless of the 
pain and suffering, well .. that is poor change management.  The good news is 
that both of those over-arching issues are addressable.

John

-Original Message-
From: bind-users-boun...@lists.isc.org 
[mailto:bind-users-boun...@lists.isc.org] On Behalf Of Reindl Harald
Sent: Wednesday, February 17, 2016 10:34 AM
To: bind-users@lists.isc.org
Subject: Re: CVE-2015-7547: getaddrinfo() stack-based buffer overflow



Am 17.02.2016 um 17:22 schrieb Dominique Jullier:
> Are they any thoughts around, how to handle yesterday's glibc 
> vulnerability[1][2] from the side bind?
>
> Since it is a rather painful task in order to update all hosts to a 
> new version of glibc, we were thinking about other possible 
> workarounds

Fedora, RHEL and Debian as well as likely all other relevant distributions are 
providing a patched glibc - dunno what is "rather painful" to apply a ordinary 
update like kernel security updates and restart all network relevant processes 
or reboot

___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: CVE-2015-7547: getaddrinfo() stack-based buffer overflow

[Alan Clegg]

On 2/17/16, 11:34 AM, "Reindl Harald"  wrote:

>Am 17.02.2016 um 17:22 schrieb Dominique Jullier:
>> Are they any thoughts around, how to handle yesterday's glibc
>> vulnerability[1][2] from the side bind?
>>
>> Since it is a rather painful task in order to update all hosts to a new
>> version of glibc, we were thinking about other possible workarounds
>
>Fedora, RHEL and Debian as well as likely all other relevant
>distributions are providing a patched glibc - dunno what is "rather
>painful" to apply a ordinary update like kernel security updates and
>restart all network relevant processes or reboot

While I agree that the "major distributions" (and even the minor ones) are
getting patches out, I'd like to point out something that Alan Cox posted
over on G+:

"You can upgrade all your servers but if that little cheapo plastic box on
your network somewhere has a vulnerable post 2008 glibc and ever does DNS
lookups chances are it's the equivalent of a trapdoor into your network."

https://plus.google.com/+AlanClegg/posts/R1UkJjHMMB6

There does need to be something a bit deeper than "patch your servers"..

AlanC
>


___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: CVE-2015-7547: getaddrinfo() stack-based buffer overflow

[Reindl Harald]

Am 17.02.2016 um 17:22 schrieb Dominique Jullier:

Are they any thoughts around, how to handle yesterday's glibc
vulnerability[1][2] from the side bind?

Since it is a rather painful task in order to update all hosts to a new
version of glibc, we were thinking about other possible workarounds


Fedora, RHEL and Debian as well as likely all other relevant 
distributions are providing a patched glibc - dunno what is "rather 
painful" to apply a ordinary update like kernel security updates and 
restart all network relevant processes or reboot




signature.asc
Description: OpenPGP digital signature
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

CVE-2015-7547: getaddrinfo() stack-based buffer overflow

[Dominique Jullier]

Hello all,

Are they any thoughts around, how to handle yesterday's glibc
vulnerability[1][2] from the side bind? 

Since it is a rather painful task in order to update all hosts to a new
version of glibc, we were thinking about other possible workarounds.

Any ideas how to drop non-compliant responses in bind? I.e. with an
extension/adaptation of bind?

[1]https://sourceware.org/ml/libc-alpha/2016-02/msg00416.html
[2]
https://googleonlinesecurity.blogspot.com/2016/02/cve-2015-7547-glibc-getaddrinfo-stack.html


smime.p7s
Description: S/MIME cryptographic signature
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users