Bug 156048 - nscd vulnerable to cache poisoning
nscd vulnerable to cache poisoning
Status: CLOSED DUPLICATE of bug 152848
Product: Fedora Legacy
Classification: Retired
Component: glibc (Show other bugs)
rhl7.3
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Fedora Legacy Bugs
LEGACY, rh73, publish-rhl73
: Security
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2005-04-26 19:33 EDT by Need Real Name
Modified: 2016-11-24 10:21 EST (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2005-05-05 02:42:02 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Need Real Name 2005-04-26 19:33:57 EDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.7) Gecko/20050414 Firefox/1.0.3

Description of problem:
From time to time we've seen cron jobs get timeouts connecting to services on localhost.  Finally caught it in the act, tried to telnet to port 25 on localhost, and it attempted to connect to some third-party IP address instead of 127.0.0.1!

> telnet localhost 25
Trying 203.210.151.30...
telnet: connect to address 203.210.151.30: Connection refused

> ping localhost
PING localhost (203.210.151.30) from 204.212.42.4 : 56(84) bytes of data.
64 bytes from localhost (203.210.151.30): icmp_seq=1 ttl=50 time=532 ms
64 bytes from localhost (203.210.151.30): icmp_seq=2 ttl=50 time=538 ms

Further investigation showed that that IP address had recently sent us email, triggering a reverse DNS lookup in sendmail.  Reverse DNS pointed to localhost.

Restarting nscd solved the problem.  Spotted the same thing with another IP (again rDNS triggered through sendmail), disabled nscd entirely, and we haven't seen it since.

Version-Release number of selected component (if applicable):
nscd-2.2.5-44.legacy.3

How reproducible:
Sometimes

Steps to Reproduce:
We were unable to induce the cache poisoning deliberately, but we were able to observe it several times, always under the same circumstances (following incoming mail from an IP with rDNS pointing to localhost).

Actual Results:  Attempting to ping or telnet to localhost tried to connect to the wrong IP address.

Expected Results:  Localhost should have resolved to 127.0.0.1 as set in /etc/hosts

Additional info:

This may be related to bug 152761 about a problem with the resolver library in glibc.  However, we were already running the glibc release that is supposed to have fixed that bug.
Comment 1 Marc Deslauriers 2005-04-26 20:14:32 EDT
What do your /etc/hosts and /etc/nswitch.conf files contain?
Comment 2 Need Real Name 2005-04-26 20:30:50 EDT
Relevant lines from...
/etc/hosts:
127.0.0.1       localhost.localdomain    localhost   localhost.speed.net
- I have since changed this to:
127.0.0.1       localhost    localhost.localdomain

/etc/nsswitch.conf:
hosts:      files dns
Comment 3 Marc Deslauriers 2005-04-26 23:51:48 EDT
Seems to be a known issue fixed in later versions of glibc...I'll try and find a
patch...

See bug 90463 and bug 56545
Comment 4 Marc Deslauriers 2005-04-27 00:07:03 EDT
Looks like the glibc-2.2.4-nscd-hstcache.patch patch from
glibc-2.2.4-32.18.src.rpm takes care of this issue.

I'll build some test packages for rhl7.3 tomorrow.
Comment 5 Marc Deslauriers 2005-04-27 13:36:34 EDT
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Here are updated glibc packages to test/QA that may correct the issue:

* Wed Apr 27 2005 Marc Deslauriers <marcdeslauriers@videotron.ca> 2.2.4-44.legacy.4
- - Added patch so gethostbyaddr and gethostbyname don't use the same cache

2ed45236c3f1dc1ad090ca068b6ab9871ec7a0c2  glibc-2.2.5-44.legacy.4.i386.rpm
d342ed96344b248e44a69fffab8ecfec7c5af3d1  glibc-2.2.5-44.legacy.4.i686.rpm
caa130a388f5844de8d0f765c1af01afabb71ad3  glibc-2.2.5-44.legacy.4.src.rpm
cdfa401bf9415547c5945ef1751a614856144e18  glibc-common-2.2.5-44.legacy.4.i386.rpm
7fea39b6b95b359dd876782a7a372577492942a1  glibc-debug-2.2.5-44.legacy.4.i386.rpm
e47473b12c68fa09a7a100ffc5eb9f395c22e52f  glibc-debug-2.2.5-44.legacy.4.i686.rpm
f8cd5b999a8373a509a23adb71618dcf4c475d6e 
glibc-debug-static-2.2.5-44.legacy.4.i386.rpm
2fd3461497d86cb8d7abf3c135e42a255da027fa  glibc-devel-2.2.5-44.legacy.4.i386.rpm
864c634b5adac25f5bab5d3ccf1d2923c4a19fbf  glibc-profile-2.2.5-44.legacy.4.i386.rpm
cb2221cb4c71a399dda76b9fe7338e6a6bfc8dfb  glibc-utils-2.2.5-44.legacy.4.i386.rpm
46049abdeda819e1682d4deeda69f655a2131525  nscd-2.2.5-44.legacy.4.i386.rpm

http://www.infostrategique.com/linuxrpms/legacy/7.3/glibc-2.2.5-44.legacy.4.i386.rpm
http://www.infostrategique.com/linuxrpms/legacy/7.3/glibc-2.2.5-44.legacy.4.i686.rpm
http://www.infostrategique.com/linuxrpms/legacy/7.3/glibc-2.2.5-44.legacy.4.src.rpm
http://www.infostrategique.com/linuxrpms/legacy/7.3/glibc-common-2.2.5-44.legacy.4.i386.rpm
http://www.infostrategique.com/linuxrpms/legacy/7.3/glibc-debug-2.2.5-44.legacy.4.i386.rpm
http://www.infostrategique.com/linuxrpms/legacy/7.3/glibc-debug-2.2.5-44.legacy.4.i686.rpm
http://www.infostrategique.com/linuxrpms/legacy/7.3/glibc-debug-static-2.2.5-44.legacy.4.i386.rpm
http://www.infostrategique.com/linuxrpms/legacy/7.3/glibc-devel-2.2.5-44.legacy.4.i386.rpm
http://www.infostrategique.com/linuxrpms/legacy/7.3/glibc-profile-2.2.5-44.legacy.4.i386.rpm
http://www.infostrategique.com/linuxrpms/legacy/7.3/glibc-utils-2.2.5-44.legacy.4.i386.rpm
http://www.infostrategique.com/linuxrpms/legacy/7.3/nscd-2.2.5-44.legacy.4.i386.rpm

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.6 (GNU/Linux)

iD8DBQFCb82nLMAs/0C4zNoRAlt3AJ4uiL0F+m+RiIQWWHWRLZI+gpdNJQCeN4M6
skHXs07HwX6DfTiBgGwMrEI=
=LpSt
-----END PGP SIGNATURE-----
Comment 6 Pekka Savola 2005-05-01 03:09:04 EDT
I'll mark this one duplicate of #152848 so that we only need to
track the glibc update in one place.. (I wonder if there's a better way to do
these..)
Comment 7 Pekka Savola 2005-05-05 02:42:02 EDT

*** This bug has been marked as a duplicate of 152848 ***

Note You need to log in before you can comment on or make changes to this bug.