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 1606-1] poppler packages fix execution of arbitrary code
Hi Eugene, * Eugene V. Lyubimkin <[EMAIL PROTECTED]> [2008-07-09 21:44]: > Steve Kemp wrote: > > For the unstable distribution (sid), this problem has been fixed in > > version 0.8.0-1. > Unstable has now version 0.8.4, how it can be? > > (please CC me in replies) See the changelog of poppler in unstable: http://packages.debian.org/changelogs/pool/main/p/poppler/poppler_0.8.4-1/changelog The version in unstable was fixed quite some time ago. Maybe we should add this to the Debian security FAQ as this question pops up every now and then? Cheers Nico -- Nico Golde - http://www.ngolde.de - [EMAIL PROTECTED] - GPG: 0x73647CFF For security reasons, all text in this mail is double-rot13 encrypted. pgpkv9pWP0hQ8.pgp Description: PGP signature
Re: [SECURITY] [DSA 1606-1] poppler packages fix execution of arbitrary code
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Steve Kemp wrote: > For the unstable distribution (sid), this problem has been fixed in > version 0.8.0-1. Unstable has now version 0.8.4, how it can be? (please CC me in replies) - -- Eugene V. Lyubimkin aka JackYF, Ukrainian C++ developer. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFIdQuWchorMMFUmYwRAi5YAJ0Wf6OlgFxI6zAMZoy6+hynxAks7QCgyaHK KRS+fqt4vHyb7WgS7VHYJgc= =gHcr -END PGP SIGNATURE- -- 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: DNS Cache poisoning and pdnsd
* Pierre Habouzit: > And the code matches the documentation. And yes a new socket is used for each > request if that matters. But it seems to use a weak PRNG (random from libc). -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Jörn Henning/EDV/OZV ist außer Haus.
Ich werde ab 09.07.2008 nicht im Büro sein. Ich kehre zurück am 14.07.2008. Ich werde Ihre Nachricht nach meiner Rückkehr beantworten. In dringenden Fällen wenden Sie sich bitte an [EMAIL PROTECTED], [EMAIL PROTECTED] oder [EMAIL PROTECTED] -- 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 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: DNS Cache poisoning and pdnsd
On Wed, Jul 09, 2008 at 09:44:21AM +, Kapil Hari Paranjape wrote: > Hello, > > The Debian advisory does not mention the status of "pdnsd" w.r.t the > DNS cache poisoning problem. A quick check seems to suggest that > "pdnsd" also randomises the source port while sending out a query. > > Could the maintainer of "pdnsd" please confirm this? I do not want to > file a pointless bug report if this is not a problem! Quoting pndnsd.conf(5): query_port_start=number; If given, defines the start of the port range used for queries of pdnsd. The value given must be >= 1024. The purpose of this option is to aid certain firewall configurations that are based on the source port. Please keep in mind that another application may bind a port in that range, so a stateful firewall using tar‐ get port and/or process uid may be more effective. In case a query start port is given pdnsd uses this port as the first port of a specified port range (see query_port_end) used for queries. pdnsd will try to randomly select a free port from this range as local port for the query. To ensure that there are enough ports for pdnsd to use, the range between query_port_start and query_port_end should be adjusted to at least (par_queries * proc_limit). A higher value is highly recommended, because other applications may also allo‐ cate ports in that range. If possible, this range should be kept out of the space that other applications usually use. query_port_end=number; Only used if query_port_start is given. Defines the last port of the range started by query_port_start used for querys by pdnsd. The default is 65535, which is also the maximum legal value for ^ this option.For details see thedescriptionof query_port_start. And the code matches the documentation. And yes a new socket is used for each request if that matters. -- ·O· Pierre Habouzit ··O[EMAIL PROTECTED] OOOhttp://www.madism.org pgpAcfhYOW29S.pgp Description: PGP signature
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]
DNS Cache poisoning and pdnsd
Hello, The Debian advisory does not mention the status of "pdnsd" w.r.t the DNS cache poisoning problem. A quick check seems to suggest that "pdnsd" also randomises the source port while sending out a query. Could the maintainer of "pdnsd" please confirm this? I do not want to file a pointless bug report if this is not a problem! Thanks and regards, Kapil. -- signature.asc Description: Digital signature
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]
