Message-ID: <495AAD1D.4080203@cwilson.fastmail.fm>
Date: Tue, 30 Dec 2008 18:22:05 -0500
From: Charles Wilson <cygwin AT cwilson DOT fastmail DOT fm>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.8.1.18) Gecko/20081105 Thunderbird/2.0.0.18 Mnenhy/0.7.5.666
MIME-Version: 1.0
To: Cygwin Mailing List <cygwin AT cygwin DOT com>
Subject: cygwin-1.7, sshd, tcpd, and IPv6/Vista
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com

Noticed an odd behavior when setting up cygwin-1.7 and sshd. Because
cygwin-1.7 (and the cygwin-1.7 flavors of openssh and tcp_wrappers)
support IPv6 when the underlying host OS supports it...the default
/etc/hosts.allow "paranoid" setting matches for "localhost".

That is, 'ssh localhost' is denied by tcpd. This was originally reported
here: http://www.cygwin.com/ml/cygwin/2008-10/msg00370.html

Here's the default hosts.allow:

ALL : PARANOID : deny
sshd: ALL

The "PARANOID" setting denies any address whose name and IP address do
not match, as determined by gethostbyname/res_search.

[Bzzt. wrong:] I *believe* the reason for the match is that, on Vista,
IPv6 is enabled by default (and, there is NO way to disable it for the
loopback interface). So, it seems tcpd is always confused by this when
querying localhost by name, and puts 'localhost' in the 'paranoid' bin:

$ /usr/sbin/tcpdmatch sshd localhost
client:   hostname paranoid
client:   address  ::1
server:   process  sshd
access:   denied

client:   hostname paranoid
client:   address  127.0.0.1
server:   process  sshd
access:   denied

$ /usr/sbin/tcpdmatch.exe sshd 127.0.0.1
client:   address  127.0.0.1
server:   process  sshd
access:   granted

$ /usr/sbin/tcpdmatch.exe sshd ::1
client:   address  ::1
server:   process  sshd
access:   granted

NOPE. IPv6 is not the (true) culprit. Enabling the logs, I get the
following messages:

Dec 30 16:53:02 mymachine warning: sshd: no such process name in
/etc/inetd.conf
Dec 30 16:53:02 mymachine warning: localhost: hostname alias
Dec 30 16:53:02 mymachine warning: (official name: mymachine)
Dec 30 16:53:02 mymachine warning: host name/address mismatch: ::1 !=
mymachine
Dec 30 16:53:02 mymachine matched:  /etc/hosts.allow line 13
Dec 30 16:53:02 mymachine option:   deny
Dec 30 16:53:02 mymachine warning: /etc/hosts.allow, line 13: host
name/address mismatch: 127.0.0.1 != mymachine
Dec 30 16:53:02 mymachine matched:  /etc/hosts.allow line 13
Dec 30 16:53:02 mymachine option:   deny

When given a hostname, tcpd does this:
  look up IP addr (and canonical name) of supplied hostname
     call this IP#1
  get list of IP addr associated with canonical name
  make sure IP#1 is in the list -- if not, error.
  Verify also that gethostbyaddr() and gethostbyname() return
     the same hostname

There is a special case for handling localhost
   && STR_NE(host->name, "localhost")) {
but by this time, host->name no longer holds "localhost" but instead
holds the string representation of the IP address, so I'm not sure that
this 'special case' ever solved anything.

Anyway, because "127.0.0.1" != "mymachine" (or, for that matter,
"localhost" != "mymachine"), the paranoid rule matches, and access is
denied. Ditto for IPv6 "::1" loopback.

I don't recall seeing this problem earlier (e.g. XP, or cygwin-1.5), but
I just tried on Vista/cygwin-1.5 and NOW I get the same behavior as above!


One possible fix is to insert the following:

ALL : 127.0.0.1/32 : allow
ALL : [::1]/128 : allow

*before* the PARANOID line in hosts.allow.

However, this could cause some un-desired behavior in certain cases,
such as:

I use Spybot Search & Destroy.  One of the things it does is modify the
/etc/hosts file (actually the /c/Windows/system32/drivers/etc/hosts
file), and maps lots -- about 8000 -- of "bad" names to 127.0.0.1:

127.0.0.1       localhost
::1             localhost
# Start of entries inserted by Spybot - Search & Destroy
127.0.0.1     www.007guard.com
127.0.0.1     007guard.com
...
127.0.0.1     www.zxlinks.com
127.0.0.1     zyban-zocor-levitra.com
# This list is Copyright 2000-2008 Safer Networking Limited
# End of entries inserted by Spybot - Search & Destroy

Note: I removed all of spybot's entries, and rebooted with a "normal"
hosts file. I still get the behavior described above, where
/usr/sbin/tcpdmatch sshd localhost failed due to the paranoid rule. So,
the 8000+ entries in hosts all mapping to 127.0.0.1 is NOT the problem.

If you insert the "allow" lines shown above into hosts.allow, then with
these Spybot entries in your /etc/hosts file, you would get the
following behavior (for ANY service, even those otherwise denied):

$ /usr/sbin/tcpdmatch.exe rsh adaware.cc
client:   hostname paranoid
client:   address  127.0.0.1
server:   process  rsh
access:   granted

Now, that might be very worrying, but if someone at adaware.cc was
trying to rsh to your box, it wouldn't come in as a "adaware.cc"
request. It would come in from 62.80.127.193 (incoming TCP/UDP packets
encode source IP addr, not hostname). And

$ /usr/sbin/tcpdmatch.exe rsh 62.80.127.193
client:   address  62.80.127.193
server:   process  rsh
access:   denied

So, the "allow" entries in hosts.allow are really only enabling access
form the actual "127.0.0.1" aka "::1" machine -- that is, the actual
local host.  They do not REALLY enable access from those bad guys that
spybot maps to localhost.

Can anybody think of an alternate explanation (perhaps this is a bug in
cygwin-1.7's resolver code, or a bug I haven't spotted in tcpd?) Am I
being too blase' about modifying hosts.allow as

ALL : 127.0.0.1/32 : allow
ALL : [::1]/128 : allow
ALL : PARANOID : deny
sshd: all

or, am I right that doing so is perfectly safe even with a munged up
hosts file -- and if so, should I modify the default hosts.allow shipped
with tcp_wrappers?

--
Chuck


--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/