Re: [DSA 1605-1] DNS vulnerability impact on the libc stub resolver
On Mon, 11 Aug 2008 19:25:17 +0200 Moritz Muehlenhoff <[EMAIL PROTECTED]> wrote: > The Linux kernel implements UDP source port randomisation since 2.6.24: > > | This patch causes UDP port allocation to be randomized like TCP. > | The earlier code would always choose same port (ie first empty list). > > http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=32c1da70810017a98aa6c431a5494a302b6b9a30 I met Yoshifuji (Usagi - IPv6 for Linux kernel - maintainer) and asked him this issue, he said "I'm not sure about cryptography, it's not so strong randomization, but 'better than nothing', I think". -- Regards, Hideki Yamane henrich @ debian.or.jp/iijmio-mail.jp http://wiki.debian.org/HidekiYamane -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [DSA 1605-1] DNS vulnerability impact on the libc stub resolver
Quoting Vincent Deffontaines ([EMAIL PROTECTED]): > No I confirm NAT source port randomization was included in 2.6.21 as far > as Netfilter NAT is concerned. > Commit is : > http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=41f4689a7c8cd76b77864461b3c58fde8f322b2c > > The 2.6.24 commit is Linux network stack, not Netfilter. As I said in our brief off-list side discussion, my apologies for having been too tired at the moment I posted my comment about 2.6.24. (It was late.) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [DSA 1605-1] DNS vulnerability impact on the libc stub resolver
Rick Moen a écrit : > Quoting Vincent Deffontaines ([EMAIL PROTECTED]): > >> And the Linux kernel (Netfilter) implements NAT source port >> randomization >> since 2.6.21, which can make it a conveninent way to protect your natted >> hosts without any patching. >> >> See http://software.inl.fr/trac/wiki/contribs/RandomSkype for details. > > I believe this works on UDP traffic only starting with 2.6.24. See: > http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=32c1da70810017a98aa6c431a5494a302b6b9a30 > http://www.kernel.org/pub/linux/kernel/v2.6/ChangeLog-2.6.24 > No I confirm NAT source port randomization was included in 2.6.21 as far as Netfilter NAT is concerned. Commit is : http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=41f4689a7c8cd76b77864461b3c58fde8f322b2c The 2.6.24 commit is Linux network stack, not Netfilter. Vincent -- On sait qu'une cité va devenir grande quand on y voit les anciens planter des arbres, alors qu'ils savent qu'ils ne profiteront jamais de leur ombre. Proverbe Grec -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [DSA 1605-1] DNS vulnerability impact on the libc stub resolver
Quoting Vincent Deffontaines ([EMAIL PROTECTED]): > And the Linux kernel (Netfilter) implements NAT source port randomization > since 2.6.21, which can make it a conveninent way to protect your natted > hosts without any patching. > > See http://software.inl.fr/trac/wiki/contribs/RandomSkype for details. I believe this works on UDP traffic only starting with 2.6.24. See: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=32c1da70810017a98aa6c431a5494a302b6b9a30 http://www.kernel.org/pub/linux/kernel/v2.6/ChangeLog-2.6.24 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [DSA 1605-1] DNS vulnerability impact on the libc stub resolver
Moritz Muehlenhoff a écrit : > Hideki Yamane wrote: >>> The 2.6.24 >>> kernel available since the last etch point release offers some >>> protection as well. >> >> Umm? This is NEW information for me. Could you give me any references? >> (certainly if you can disclosure. It is a sensitive issue.) > > The Linux kernel implements UDP source port randomisation since 2.6.24: And the Linux kernel (Netfilter) implements NAT source port randomization since 2.6.21, which can make it a conveninent way to protect your natted hosts without any patching. See http://software.inl.fr/trac/wiki/contribs/RandomSkype for details. Vincent -- On sait qu'une cité va devenir grande quand on y voit les anciens planter des arbres, alors qu'ils savent qu'ils ne profiteront jamais de leur ombre. Proverbe Grec -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [DSA 1605-1] DNS vulnerability impact on the libc stub resolver
* Hideki Yamane: > On Sun, 10 Aug 2008 22:11:05 +0200 > Florian Weimer <[EMAIL PROTECTED]> wrote: >> The 2.6.24 >> kernel available since the last etch point release offers some >> protection as well. > > Umm? This is NEW information for me. Could you give me any > references? It adds a weak form of source port randomization. I fear it's not good enough, but it's better than nothing. > And do you know this article? > http://technorati.com/posts/MqY%2Bc19oV42Zc0fXp5GQZC1UJxLVsVOhxhlxAxXB6S8%3D > If it's true, ... it's fear. 10 hours matches theoretical predictions for 200 Mbps attacks, so this isn't really surprising. > #OT > > BTW, in Japan, there are a lot of wireless Access Point (in Cafe, McDonalds > or so) and many many people (Windows, Mac and a few Linux and *BSD users ;) > use such wireless AP and unpatched name servers provided by dhcpd... > > oh no ;( On shared media networks, there are often better attacks than blind spoofing. 8-( -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [DSA 1605-1] DNS vulnerability impact on the libc stub resolver
Hideki Yamane wrote: >> The 2.6.24 >> kernel available since the last etch point release offers some >> protection as well. > > Umm? This is NEW information for me. Could you give me any references? > (certainly if you can disclosure. It is a sensitive issue.) The Linux kernel implements UDP source port randomisation since 2.6.24: | This patch causes UDP port allocation to be randomized like TCP. | The earlier code would always choose same port (ie first empty list). http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=32c1da70810017a98aa6c431a5494a302b6b9a30 Cheers, Moritz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [DSA 1605-1] DNS vulnerability impact on the libc stub resolver
Quoting Hideki Yamane ([EMAIL PROTECTED]): > I want to know that, too. > Should ALL systems (servers or desktops/laptops) need to be installed > and configure bind9 (or something) package, or need to wait for update? My own preference is, indeed, to have one of the following as a local recursive resolver: o MaraDNS's recursor module (not enabling the authoritative zoneserver): Author built in a custom RNG from the beginning o Unbound: Author built in a custom RNG from the beginning o dnscache from djbdns: built in a custom RNG from the beginning, _and_ the author made a point of warning everyone else of the pitfall but you have to put up with djb weirdness, apply patches, etc.) o PowerDNS Recursor: Retrofitted a custom RNG in March 2008, after the Kaminsky issue emerged behind closed doors, which is better than nothing but doesn't lend confidence. (OTOH, it's small, light, and easy to install/configure.) o BIND9 run just for its recursive-resolver functions (but it's bloated, slow, overfeatured, and ignored the issue for years) I'd lock the host's DNS client via /etc/resolv.conf to query only localhost. At that point, client weaknesses in source port randomisation becomes a non-issue. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [DSA 1605-1] DNS vulnerability impact on the libc stub resolver
Hi, Thanks to Florian for this reply. On Sun, 10 Aug 2008 22:11:05 +0200 Florian Weimer <[EMAIL PROTECTED]> wrote: > The 2.6.24 > kernel available since the last etch point release offers some > protection as well. Umm? This is NEW information for me. Could you give me any references? (certainly if you can disclosure. It is a sensitive issue.) > Unfortunately, it turns out the GNU libc fix is more difficult than > initially assumed. However, I didn't know at the time how aggressively > the stub resolver issue would be pushed, so I opted for the advisory to > document that the issue is on our radar screen. Okay, thanks. I'll wait. And do you know this article? http://technorati.com/posts/MqY%2Bc19oV42Zc0fXp5GQZC1UJxLVsVOhxhlxAxXB6S8%3D If it's true, ... it's fear. -- #OT BTW, in Japan, there are a lot of wireless Access Point (in Cafe, McDonalds or so) and many many people (Windows, Mac and a few Linux and *BSD users ;) use such wireless AP and unpatched name servers provided by dhcpd... oh no ;( -- Regards, Hideki Yamane henrich @ debian.or.jp/iijmio-mail.jp http://wiki.debian.org/HidekiYamane -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [DSA 1605-1] DNS vulnerability impact on the libc stub resolver
* Hideki Yamane: > On Wed, 09 Jul 2008 03:55:27 + > Nick Boyce <[EMAIL PROTECTED]> wrote: >> Also, which Debian systems would otherwise use the libc stub resolver ? >> All systems which *don't* have BIND installed ? > > I want to know that, too. > Should ALL systems (servers or desktops/laptops) need to be installed > and configure bind9 (or something) package, or need to wait for update? It depends on what the system does. A successful attack requires the ability to reflect DNS queries through the resolver, and some information must leak back to the attacker. In general, I would use the local BIND hack only for highly exposed servers (such as IRC servers, which have a history of attracting all kinds of evilness). The 2.6.24 kernel available since the last etch point release offers some protection as well. Unfortunately, it turns out the GNU libc fix is more difficult than initially assumed. However, I didn't know at the time how aggressively the stub resolver issue would be pushed, so I opted for the advisory to document that the issue is on our radar screen. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [DSA 1605-1] DNS vulnerability impact on the libc stub resolver
Hi security experts, On Wed, 09 Jul 2008 03:55:27 + Nick Boyce <[EMAIL PROTECTED]> wrote: > Also, which Debian systems would otherwise use the libc stub resolver ? > All systems which *don't* have BIND installed ? I want to know that, too. Should ALL systems (servers or desktops/laptops) need to be installed and configure bind9 (or something) package, or need to wait for update? And some of Japanese Debian users ask me, "Really? Should we need to care about glibc for this issue? Any distros except Debian have not released any security advisories for glibc yet. I read DSA, but how do we deal with this glibc's DNS vulnerability?" At CERT site, glibc has "Status Summary Unknown" see http://www.kb.cert.org/vuls/id/MIMG-7ECL7W At glibc upstream cvsweb page, I cannot find any update for this issue. http://sources.redhat.com/cgi-bin/cvsweb.cgi/libc/NEWS?cvsroot=glibc If we don't apply workaround in DSA-1605, my Debian box is exploitable? If exploitable, is it easy (impact/risk)? I'm confused... help. -- Regards, Hideki Yamane henrich @ debian.or.jp/iijmio-mail.jp http://wiki.debian.org/HidekiYamane -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [SECURITY] [DSA 1605-1] DNS vulnerability impact on the libc stub resolver
* Joey Hess: > IIRC Dan Kaminsky has been suggesting using opendns, which has fixed > servers, if your ISPs server is not fixed. Won't using a third-party DNS > server defeat any filtering your ISP does on their network, and allow the > stub resolver to be spoofed? I disagree with this recommendation. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [SECURITY] [DSA 1605-1] DNS vulnerability impact on the libc stub resolver
Florian Weimer wrote: > On the hand, if you don't build a network of your own, and your ISP > properly filters their Internet connection and their customer interfaces > to stop source address spoofing, it's not possible forge DNS traffic > which claims to come from the ISP resolver. (Since the addresses > involved are theirs, they can actually do it--globally, on the whole > Internet, it's much more difficult.) IIRC Dan Kaminsky has been suggesting using opendns, which has fixed servers, if your ISPs server is not fixed. Won't using a third-party DNS server defeat any filtering your ISP does on their network, and allow the stub resolver to be spoofed? -- see shy jo signature.asc Description: Digital signature
Re: [SECURITY] [DSA 1605-1] DNS vulnerability impact on the libc stub resolver
Quoting Florian Weimer ([EMAIL PROTECTED]): > lwresd is far less-tested than BIND, and tweaking the NSS configuration > is something few people like to do. Incidentally, the documentation for nss_lwres suggests the following entry in /etc/nsswitch.conf, for Linux systems installing lwresd: "hosts: files lwres [NOTFOUND=return] dns" I had somehow missed lwresd's existence entirely, when I built my catalogue of DNS nameserver implementations for Linux (http://linuxmafia.com/faq/Network_Other/dns-servers.html), so I've just written an entry, furnishing the above and other suggestions / comments. (Entry may have errors, as I've not yet experimented with lwresd, only read about it.) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [SECURITY] [DSA 1605-1] DNS vulnerability impact on the libc stub resolver
On Thu, 10 Jul 2008, Florian Weimer wrote: > * Henrique de Moraes Holschuh: > > 3. Install lwresd from an updated BIND9, install libnss-lwres, and replace > > "dns" with "lwres" in /etc/nsswitch.conf. Make sure to restart lwres when > > /etc/resolv.conf changes. > > lwresd is far less-tested than BIND, and tweaking the NSS configuration > is something few people like to do. Indeed it is far less tested, it doesn't even work well out-of-the-box in Debian because nobody did the integration work. But it IS an alternative people often forget. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [SECURITY] [DSA 1605-1] DNS vulnerability impact on the libc stub resolver
* Noah Meyerhans: > On Wed, Jul 09, 2008 at 06:10:51PM +0200, Wolfgang Jeltsch wrote: >> > At this time, it is not possible to implement the recommended >> > countermeasures in the GNU libc stub resolver. >> >> I don???t have bind9 installed. Am I affected by the libc stub resolver bug? > > Yes. I suggest that you install bind9, configure it to only listen on > 127.0.0.1, and add "nameserver 127.0.0.1" to resolv.conf before any > other nameserver lines (since they're queried in order). On the hand, if you don't build a network of your own, and your ISP properly filters their Internet connection and their customer interfaces to stop source address spoofing, it's not possible forge DNS traffic which claims to come from the ISP resolver. (Since the addresses involved are theirs, they can actually do it--globally, on the whole Internet, it's much more difficult.) So in many cases, countermeasures aren't really necessary. On the other hand, the amount of filtering varies greatly from region to region, and even from ISP to ISP. Certainly, there are some broadband deployments with shockingly little filtering, and customers can attack each other in these cases (but only by spoofing blindly). That's why we're looking into providing a libc update. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [SECURITY] [DSA 1605-1] DNS vulnerability impact on the libc stub resolver
* Henrique de Moraes Holschuh: > 3. Install lwresd from an updated BIND9, install libnss-lwres, and replace > "dns" with "lwres" in /etc/nsswitch.conf. Make sure to restart lwres when > /etc/resolv.conf changes. lwresd is far less-tested than BIND, and tweaking the NSS configuration is something few people like to do. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [SECURITY] [DSA 1605-1] DNS vulnerability impact on the libc stub resolver
Quoting Hubert Chathi ([EMAIL PROTECTED]): > I'm really more concerned about the fact that it's orphaned. And it > appears to be unmaintained upstream (last release in 2001, and > upstream moved it from the "releases" directory to the "old-releases" > directory). Point taken. I assume you are referring to ftp://sources.redhat.com/pub/glibc/old-releases/nss_lwres-0.93.tar.gz Here's original NSS module author Mark Kettenis <[EMAIL PROTECTED]>'s release announcement in July 2000: http://sources.redhat.com/ml/libc-alpha/2000-07/msg00172.html I guess we can hope that the current security incident will encourage the glibc developers to consider adopting Kettenis's NSS code, as part of a larger plan to (finally!) phase out the legacy BIND8 resolver code. But that won't happen quickly, if at all, I fear. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [SECURITY] [DSA 1605-1] DNS vulnerability impact on the libc stub resolver
On Wed, 9 Jul 2008 15:45:12 -0700 Rick Moen <[EMAIL PROTECTED]> wrote: > Quoting Hubert Chathi ([EMAIL PROTECTED]): > > > Hmm... libnss-lwres is orphaned (#475089), and is uninstallable on > > sid. > > I'll bet the version of the missing dependency package (liblwres30) in > lenny would suffice. I'm really more concerned about the fact that it's orphaned. And it appears to be unmaintained upstream (last release in 2001, and upstream moved it from the "releases" directory to the "old-releases" directory). -- Hubert Chathi <[EMAIL PROTECTED]> -- Jabber: [EMAIL PROTECTED] PGP/GnuPG key: 1024D/124B61FA http://www.uhoreg.ca/ Fingerprint: 96C5 012F 5F74 A5F7 1FF7 5291 AF29 C719 124B 61FA -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [SECURITY] [DSA 1605-1] DNS vulnerability impact on the libc stub resolver
Incoming from Micah Anderson: > * s. keeling <[EMAIL PROTECTED]> [2008-07-09 17:31-0400]: > > Micah Anderson <[EMAIL PROTECTED]>: > > > * Wolfgang Jeltsch <[EMAIL PROTECTED]> [2008-07-09 13:31-0400]: > > > > > > configure it to only listen on 127.0.0.1, > > > > > > > > How do I do this? dpkg-reconfigure doesn?t help. > > > > > > I think the bind9 package comes configured this way by default in > > > Debian (a caching-only local nameserver). > > > > If that's what the OP requires, maradns provides that, and a lot > > simpler. > > What could be more simpler than apt-get install bind9? ... followed by configuring it for (assumed, worst case) his particular Franken-network situation. I've fought with bind numerous times before, and didn't enjoy it. If all he needs is caching-only local, that's what maradns is for. I'm not dissing bind*. I'm just suggesting maradns's simpler, and possibly apropos in OP's situation. I could be wrong though; the start of this thread recedes into the depths of time ... and I may have missed important details. -- Any technology distinguishable from magic is insufficiently advanced. (*) Please don't Cc: me. - - -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [SECURITY] [DSA 1605-1] DNS vulnerability impact on the libc stub resolver
* s. keeling <[EMAIL PROTECTED]> [2008-07-09 17:31-0400]: > Micah Anderson <[EMAIL PROTECTED]>: > > * Wolfgang Jeltsch <[EMAIL PROTECTED]> [2008-07-09 13:31-0400]: > > > > > configure it to only listen on 127.0.0.1, > > > > > > How do I do this? dpkg-reconfigure doesn?t help. > > > > I think the bind9 package comes configured this way by default in > > Debian (a caching-only local nameserver). > > If that's what the OP requires, maradns provides that, and a lot > simpler. What could be more simpler than apt-get install bind9? micah -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [SECURITY] [DSA 1605-1] DNS vulnerability impact on the libc stub resolver
Micah Anderson <[EMAIL PROTECTED]>: > * Wolfgang Jeltsch <[EMAIL PROTECTED]> [2008-07-09 13:31-0400]: > > > > configure it to only listen on 127.0.0.1, > > > > How do I do this? dpkg-reconfigure doesn?t help. > > I think the bind9 package comes configured this way by default in > Debian (a caching-only local nameserver). If that's what the OP requires, maradns provides that, and a lot simpler. -- Any technology distinguishable from magic is insufficiently advanced. (*)http://blinkynet.net/comp/uip5.html Linux Counter #80292 - -http://www.faqs.org/rfcs/rfc1855.htmlPlease, don't Cc: me. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [SECURITY] [DSA 1605-1] DNS vulnerability impact on the libc stub resolver
Quoting Hubert Chathi ([EMAIL PROTECTED]): > Hmm... libnss-lwres is orphaned (#475089), and is uninstallable on sid. I'll bet the version of the missing dependency package (liblwres30) in lenny would suffice. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [SECURITY] [DSA 1605-1] DNS vulnerability impact on the libc stub resolver
On Tue, 8 Jul 2008 22:43:54 -0300 Henrique de Moraes Holschuh <[EMAIL PROTECTED]> wrote: > On Tue, 08 Jul 2008, Florian Weimer wrote: > > 1. Install a local BIND 9 resoler on the host, possibly in > > forward-only mode. BIND 9 will then use source port randomization > > when sending queries over the network. (Other caching resolvers can > > be used instead.) > > > > 2. Rely on IP address spoofing protection if available. Successful > > attacks must spoof the address of one of the resolvers, which may > > not be possible if the network is guarded properly against IP > > spoofing attacks (both from internal and external sources). > > 3. Install lwresd from an updated BIND9, install libnss-lwres, and > replace "dns" with "lwres" in /etc/nsswitch.conf. Make sure to > restart lwres when /etc/resolv.conf changes. Hmm... libnss-lwres is orphaned (#475089), and is uninstallable on sid. -- Hubert Chathi <[EMAIL PROTECTED]> -- Jabber: [EMAIL PROTECTED] PGP/GnuPG key: 1024D/124B61FA http://www.uhoreg.ca/ Fingerprint: 96C5 012F 5F74 A5F7 1FF7 5291 AF29 C719 124B 61FA -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [SECURITY] [DSA 1605-1] DNS vulnerability impact on the libc stub resolver
* Wolfgang Jeltsch <[EMAIL PROTECTED]> [2008-07-09 13:31-0400]: > > > configure it to only listen on 127.0.0.1, > > How do I do this? dpkg-reconfigure doesn’t help. I think the bind9 package comes configured this way by default in Debian (a caching-only local nameserver). Micah -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [SECURITY] [DSA 1605-1] DNS vulnerability impact on the libc stub resolver
Am Mittwoch, 9. Juli 2008 22:39 schrieb Rick Moen: > Quoting Wolfgang Jeltsch ([EMAIL PROTECTED]): > > Am Mittwoch, 9. Juli 2008 20:51 schrieb Noah Meyerhans: > > > > I suggest that you install bind9, > […] > > > > configure it to only listen on 127.0.0.1, > > > > How do I do this? dpkg-reconfigure doesn’t help. > > Although this will require a substantial investment of your time, I > recommend studying > http://www.cymru.com/Documents/secure-bind-template.html , to better > understand how to properly configure and lock down BIND9. Oh no. I just wanted to do a security update. I didn’t want to install bind9 at all. Short question: Is it sufficient if I use iptables with a stateful filter which only allows incoming packets if they are ESTABLISHED, RELATED or have an acceptable TCP destination port (like ssh or http)? I do this anyway. Best wishes, Wolfgang -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [SECURITY] [DSA 1605-1] DNS vulnerability impact on the libc stub resolver
Quoting Wolfgang Jeltsch ([EMAIL PROTECTED]): > Am Mittwoch, 9. Juli 2008 20:51 schrieb Noah Meyerhans: > > > > I suggest that you install bind9, > > How do I tell bind9 what DNS servers to ask? Is this also done by > resolv.conf? If yes, named would ask itself if 127.0.0.1 is the first entry. > > > > configure it to only listen on 127.0.0.1, > > How do I do this? dpkg-reconfigure doesn???t help. Although this will require a substantial investment of your time, I recommend studying http://www.cymru.com/Documents/secure-bind-template.html , to better understand how to properly configure and lock down BIND9. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [SECURITY] [DSA 1605-1] DNS vulnerability impact on the libc stub resolver
Am Mittwoch, 9. Juli 2008 20:51 schrieb Noah Meyerhans: > On Wed, Jul 09, 2008 at 06:10:51PM +0200, Wolfgang Jeltsch wrote: > > > At this time, it is not possible to implement the recommended > > > countermeasures in the GNU libc stub resolver. > > > > I don’t have bind9 installed. Am I affected by the libc stub resolver > > bug? > > Yes. Even if the bug is fixed in my provider’s DNS servers? > > I suggest that you install bind9, How do I tell bind9 what DNS servers to ask? Is this also done by resolv.conf? If yes, named would ask itself if 127.0.0.1 is the first entry. > > configure it to only listen on 127.0.0.1, How do I do this? dpkg-reconfigure doesn’t help. > > and add "nameserver 127.0.0.1" to resolv.conf before any > > other nameserver lines (since they're queried in order). Shouldn’t I remove the other entries? The other nameservers shouldn’t be contacted anymore, right? Best wishes, Wolfgang -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [SECURITY] [DSA 1605-1] DNS vulnerability impact on the libc stub resolver
On Wed, Jul 09, 2008 at 06:10:51PM +0200, Wolfgang Jeltsch wrote: > > At this time, it is not possible to implement the recommended > > countermeasures in the GNU libc stub resolver. > > I don???t have bind9 installed. Am I affected by the libc stub resolver bug? Yes. I suggest that you install bind9, configure it to only listen on 127.0.0.1, and add "nameserver 127.0.0.1" to resolv.conf before any other nameserver lines (since they're queried in order). > > The following workarounds are available: > > > > 1. Install a local BIND 9 resoler on the host, possibly in > > forward-only mode. BIND 9 will then use source port randomization > > when sending queries over the network. (Other caching resolvers can > > be used instead.) > > > > 2. Rely on IP address spoofing protection if available. Successful > > attacks must spoof the address of one of the resolvers, which may not > > be possible if the network is guarded properly against IP spoofing > > attacks (both from internal and external sources). > > Is it okay to apply only workaround 2? Is my server guarded properly against > IP spoofing attacks (both from internal and external sources) if the content > of /proc/sys/net/ipv4/conf/all/rp_filter is 1? rp_filter doesn't actually do anything meaningful on single-homed machines. All it does is drop inbound packets from host H on interface A if, to reach H, the kernel would send a packet out interface B. It doesn't magically protect against IP spoofing (if it was that easy, then IP spoofing wouldn't be an issue). If you've only got one interface, it doesn't do anything. noah signature.asc Description: Digital signature
Re: [SECURITY] [DSA 1605-1] DNS vulnerability impact on the libc stub resolver
On Tue, 08 Jul 2008 19:50:44 +0200 Florian Weimer <[EMAIL PROTECTED]> wrote: > PowerDNS is not available on all architectures, and Unbound and tinydns > are not part of etch. How about making page about this issue in wiki.debian.org? I'm so confused to a flood of information about this issue... -- Regards, Hideki Yamane henrich @ debian.or.jp/iijmio-mail.jp -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [SECURITY] [DSA 1605-1] DNS vulnerability impact on the libc stub resolver
Am Dienstag, 8. Juli 2008 19:05 schrieb Florian Weimer: > […] > At this time, it is not possible to implement the recommended > countermeasures in the GNU libc stub resolver. Hello, I don’t have bind9 installed. Am I affected by the libc stub resolver bug? > The following workarounds are available: > > 1. Install a local BIND 9 resoler on the host, possibly in > forward-only mode. BIND 9 will then use source port randomization > when sending queries over the network. (Other caching resolvers can > be used instead.) > > 2. Rely on IP address spoofing protection if available. Successful > attacks must spoof the address of one of the resolvers, which may not > be possible if the network is guarded properly against IP spoofing > attacks (both from internal and external sources). Is it okay to apply only workaround 2? Is my server guarded properly against IP spoofing attacks (both from internal and external sources) if the content of /proc/sys/net/ipv4/conf/all/rp_filter is 1? > […] Best wishes, Wolfgang -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [SECURITY] [DSA 1605-1] DNS vulnerability impact on the libc stub resolver
On Tuesday 08 of July 2008, Florian Weimer wrote: > * Mert Dirik: > >> PowerDNS is not available on all architectures, and Unbound and tinydns > >> are not part of etch. > >> > >> So it's lack of alternatives, more or less. > > > > I don't really know much about these things but can't maradns > > MaraDNS could be used, I think. However, I'm not familiar with that > implementation. > > > or dnsmasq be used with same purpose? > > dnsmasq needs to be patched first. AFAIK dnsmasq if forwarding-only resolver, it needs some real DNS server to send queries to be resolved. So it should be OK. Or am I completely wrong? Can someone confirm or oppose this? -- Regards Vladislav Kurz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [SECURITY] [DSA 1605-1] DNS vulnerability impact on the libc stub resolver
Quoting Josip Rodin ([EMAIL PROTECTED]): > Why is this phrased in a way that it prefers BIND as a recursive resolver, > when that same software was *only just* patched to be acceptable for the > same purpose? Although I'm not much of a BIND9 fan -- it remains RAM-hogging, slow, overfeatured, and questionably architected (monolithic) -- but it _was_ a good, from-scratch rewrite of the awful spaghetti code that was BIND8. My understanding is that the resolver in glibc is the last piece of BIND8 code in standard Linux and BSD systems, so the current meltdown doesn't surprise _me_, one bit. (For years, I've been saying on http://linuxmafia.com/faq/Network_Other/dns-servers.html that "Some BIND8 code still lives on, in the DNS resolver library shipped with typical Linux and BSD distributions. This is regrettable, but the occasional security failures in that codebase should not be attributed to BIND9.") When I last researched alternative resolver libraries, I turned up: o adns http://www.chiark.greenend.org.uk/~ian/adns/ GPL, C o Ares ftp://athena-dist.mit.edu/pub/ATHENA/ares/MIT/X, C o FireDNS http://firestuff.org/projects/firedns/ GPL, C o ldnshttp://www.nlnetlabs.nl/ldns/new-BSD, C o Net::DNS http://www.net-dns.org/GPL, Perl o Poslib http://posadis.sourceforge.net/poslib/ GPL, C++ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [SECURITY] [DSA 1605-1] DNS vulnerability impact on the libc stub resolver
Debian Security Team wrote: At this time, it is not possible to implement the recommended countermeasures in the GNU libc stub resolver. The following workarounds are available: 1. Install a local BIND 9 resolver on the host, possibly in forward-only mode. Uh .. is there any documentation on how to do that ? Although I run a BIND 9 nameserver I don't know how to extract the BIND 9 resolver from such a system (for use on other systems) - and there doesn't seem to be any actual stand-alone package for such a thing. Also, which Debian systems would otherwise use the libc stub resolver ? All systems which *don't* have BIND installed ? Cluebats welcome. Cheers Nick Boyce -- Leave the Olympics in Greece, where they belong. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [SECURITY] [DSA 1605-1] DNS vulnerability impact on the libc stub resolver
On Tue, 08 Jul 2008, Florian Weimer wrote: > 1. Install a local BIND 9 resoler on the host, possibly in > forward-only mode. BIND 9 will then use source port randomization > when sending queries over the network. (Other caching resolvers can > be used instead.) > > 2. Rely on IP address spoofing protection if available. Successful > attacks must spoof the address of one of the resolvers, which may not > be possible if the network is guarded properly against IP spoofing > attacks (both from internal and external sources). 3. Install lwresd from an updated BIND9, install libnss-lwres, and replace "dns" with "lwres" in /etc/nsswitch.conf. Make sure to restart lwres when /etc/resolv.conf changes. However, expect applications that require DNS round-robin in the resolver to break (just like they break with the libc resolver with A record ordering enabled). -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [SECURITY] [DSA 1605-1] DNS vulnerability impact on the libc stub resolver
* Mert Dirik: >> PowerDNS is not available on all architectures, and Unbound and tinydns >> are not part of etch. >> >> So it's lack of alternatives, more or less. > I don't really know much about these things but can't maradns MaraDNS could be used, I think. However, I'm not familiar with that implementation. > or dnsmasq be used with same purpose? dnsmasq needs to be patched first. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [SECURITY] [DSA 1605-1] DNS vulnerability impact on the libc stub resolver
Florian Weimer yazmış: > * Josip Rodin: > >> Why is this phrased in a way that it prefers BIND as a recursive resolver, >> when that same software was *only just* patched to be acceptable for the >> same purpose? > > PowerDNS is not available on all architectures, and Unbound and tinydns > are not part of etch. > > So it's lack of alternatives, more or less. > I don't really know much about these things but can't maradns or dnsmasq be used with same purpose? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [SECURITY] [DSA 1605-1] DNS vulnerability impact on the libc stub resolver
On Tue, Jul 08, 2008 at 07:50:44PM +0200, Florian Weimer wrote: > > Why is this phrased in a way that it prefers BIND as a recursive resolver, > > when that same software was *only just* patched to be acceptable for the > > same purpose? > > PowerDNS is not available on all architectures, and Unbound and tinydns > are not part of etch. > > So it's lack of alternatives, more or less. Sigh. Speaking of which, it looks like the pdns-recursor bug #395801 may no longer be relevant (it was in 2006). I'll go file a new bug. -- 2. That which causes joy or happiness. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [SECURITY] [DSA 1605-1] DNS vulnerability impact on the libc stub resolver
* Josip Rodin: > Why is this phrased in a way that it prefers BIND as a recursive resolver, > when that same software was *only just* patched to be acceptable for the > same purpose? PowerDNS is not available on all architectures, and Unbound and tinydns are not part of etch. So it's lack of alternatives, more or less. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [SECURITY] [DSA 1605-1] DNS vulnerability impact on the libc stub resolver
On Tue, Jul 08, 2008 at 07:05:29PM +0200, Florian Weimer wrote: > Package: glibc > > At this time, it is not possible to implement the recommended > countermeasures in the GNU libc stub resolver. The following > workarounds are available: > > 1. Install a local BIND 9 resoler on the host, possibly in > forward-only mode. BIND 9 will then use source port randomization > when sending queries over the network. (Other caching resolvers can > be used instead.) Why is this phrased in a way that it prefers BIND as a recursive resolver, when that same software was *only just* patched to be acceptable for the same purpose? I'm not particularly hell-bent on security, but I would expect the security team to avoid doing these kinds of things... -- 2. That which causes joy or happiness. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
