CVE-2015-7547: getaddrinfo() stack-based buffer overflow
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
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 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
Re: CVE-2015-7547: getaddrinfo() stack-based buffer overflow
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
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
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: Zone hints for VPN environments
Hello Darcy and other posters - Original Message - From: "Darcy Kevin (FCA)" To: Sent: Tuesday, February 16, 2016 1:42 AM Subject: RE: Zone hints for VPN environments Note that there are additional considerations if there are any descendant (child, grandchild, etc.) zones of intra.example.net. Thanks for all your comments. I already have recognized that this is a more complex problem that I thought first. Another poster suggested "type slave", i.e. replicating the zone contents via the standards-defined AXFR/IXFR features of the protocol. While I'm generally a big fan of zone replication, between different legal entities there is often a concern about unintentional information disclosure. This is a good point but: Some VPN links are not always connected (the customer must explicitely activate it when a support operation is needed and disconnect when finished) so my named would produce a lot error log (and even loose all cached information after 14 days) during the closed VPN phase. Additionally in case of deeper DNS zones, for example departx.intra.example.net, addition slave configuration on my named and always keeping updated manually the zone list is needed. This is the reason why I prefer a solution to say to my named: "When resolving something in intra.example.net and deeper, use 10.55.2.3. For all other domains, use 192.0.2.44 and/or 198.51.100.2 or even the public root hints." => It does not hurt when 10.55.2.3 is sometimes not reachable because outside a VPN session, I don't need to resolve any host names inside intra.example.net into their IP addresses when no such service operation is running. Andreas -- "127.0.0.1 was ist das? Ich kenne nur ::1!" - www.swissipv6council.ch ___ 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
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. 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
* 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
pre heat cache
Is there anyway to pre-heat the cache in bind on startup besides having a custom script that did a bunch of queries on top hosts? I know you can dump it with rndc but can you load it back ? -- William Taylor Senior Systems Engineer http://sonic.com 707.522.1000 ext 2276 ___ 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: pre heat cache
On Wed, Feb 17, 2016 at 11:31:54AM -0800, William Taylor wrote: > Is there anyway to pre-heat the cache in bind on startup besides having > a custom script that did a bunch of queries on top hosts? > I know you can dump it with rndc but can you load it back ? It used to be possible to load the cache. I'm not sure if we still support that. I think at least one system test uses it somewhere. Mukund signature.asc Description: PGP 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
Re: pre heat cache
> Is there anyway to pre-heat the cache in bind on startup besides having > a custom script that did a bunch of queries on top hosts? > I know you can dump it with rndc but can you load it back ? Technically yes, but the option that can do it was only implemented for testing purposes. Using it in a production environment would not be a good idea. -- Evan Hunt -- e...@isc.org Internet Systems Consortium, Inc. ___ 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: pre heat cache
On Wed, Feb 17, 2016 at 11:31:54AM -0800, William Taylor wrote: > Is there anyway to pre-heat the cache in bind on startup besides having > a custom script that did a bunch of queries on top hosts? > I know you can dump it with rndc but can you load it back ? One way to achieve this is to have two nameserver and balance them behind dnsdist with the default 'leastOutstanding' policy. This means that as your server heats up its cache, it will only progressively get more traffic. This provides good end-user experience. http://dnsdist.org/ Preloading a cache has been considered by various implementations and generally causes more downtime/delay than heating up the cache to the point it has all relevant entries. Bert ___ 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
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
* 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
