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

2016-02-17 Thread 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 > offi

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

2016-02-17 Thread 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 se

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

2016-02-17 Thread 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 vulnera

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

2016-02-17 Thread 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 respons

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

2016-02-17 Thread 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

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

2016-02-17 Thread 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,

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

2016-02-17 Thread John W. Blue
arald 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][

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

2016-02-17 Thread 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 g

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

2016-02-17 Thread 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