nscd will reverse an IP address and later use the forward of it for lookups allowing for spoof attack which can be used to gather passwords and other data example: it does a reverse for 192.168.10.5, gets the answer localhost later it needs the address for localhost and assumes 192.168.10.5 and sends all data destined to localhost to 192.168.10.5 i saw this happen live on my server.. i have had to ask everyone using webmail and other services to change passwords etc Reproducible: Didn't try Steps to Reproduce: Example (this isn't where I saw it this time but have seen this plenty and it never dawned on me that it would be a problem) 1. with box 1 running nscd, ping box 2 that has reverse lookup of localhost 2. then ssh from box 2 to box 1 3. who will show user connected from box 2 as being connected from localhost 4. ping localhost, possible it will resolve to IP of box 2 depending on how nscd orders it cache Actual Results: In the actual case all traffic to localhost on my box was being sent to another box at some foreign IP address Expected Results: A proper DNS lookup of localhost [06:27:52]<root@igloo:/chroot/named/etc/pri> ping localhost PING localhost (203.210.158.212) 56(84) bytes of data. --- localhost ping statistics --- 2 packets transmitted, 0 received, 100% packet loss, time 1011ms [06:28:01]<root@igloo:/chroot/named/etc/pri> host 203.210.158.212 212.158.210.203.in-addr.arpa domain name pointer localhost. [06:28:07]<root@igloo:/chroot/named/etc/pri> host 203.210.158.212 ns2 Using domain server: Name: ns2 Address: 24.66.45.18#53 Aliases: 212.158.210.203.in-addr.arpa domain name pointer localhost. [06:28:15]<root@igloo:/chroot/named/etc/pri> host 203.210.158.212 ns1 Using domain server: Name: ns1 Address: 216.194.67.200#53 Aliases: 212.158.210.203.in-addr.arpa domain name pointer localhost. [06:28:21]<root@igloo:/chroot/named/etc/pri> host 203.210.158.212 ns3 Using domain server: Name: ns3 Address: 216.194.67.10#53 Aliases: 212.158.210.203.in-addr.arpa domain name pointer localhost. [06:28:45]<root@igloo:/chroot/named/etc/pri> /etc/init.d/nscd stop * Shutting down Name Service Cache Daemon... [ ok ] [06:29:18]<root@igloo:/chroot/named/etc/pri> ping localhost PING localhost (127.0.0.1) 56(84) bytes of data. 64 bytes from localhost (127.0.0.1): icmp_seq=1 ttl=64 time=0.114 ms 64 bytes from localhost (127.0.0.1): icmp_seq=2 ttl=64 time=0.079 ms
Thanks for reporting this (I think) Have you reported this to g this to ISC? How about a patch?
err/ Have you reported this to ISC?
I must be smoking crack today. qpkg -f `which nscd` sys-libs/glibc * Anyway this sounds like pebkac or an upstream bug. This is also somewhat of a very incomplete bug, please provide versions of everything. In addition could you try to reproduce with the follwing change in your /etc/nscd.conf -enable-cache hosts yes +enable-cache hosts no
Yes, in particular, is this still present with glibc-2.3.3? I know updating glibc is a fairly serious undertaking, so it would instead make sense to backport the nscd update to 2.3.2, but I can only ask. I haven't tried to reproduce this as I wouldn't really know how with only one box to play with.
Updating glibc is no more of a serious undertaking than simply merging it. I see no nscd update attached to this bug or a URL to one, so no backporting can even be considered at this time.
no response from submitter. closing as invalid.
