Date: Sat, 22 Jul 2006 16:09:34 +0200
From: Peter Bieringer <pb@...ringer.de>
To: Maillist full-disclosure <full-disclosure@...ts.grok.org.uk>
Subject: Linux: telnet/ssh and other clients can connect
 to wrong host in
 case of mixed IPv4/IPv6 environment and search suffices are used in
 /etc/resolv.conf

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi,

currently known affected:

Linux / Fedora Core 5 (glibc-2.4-8):
	telnet-0.17-35.2.1
	openssh-clients-4.3p2-4
	

Linux / Red Hat Enterprise 4 (glibc-2.3.4-2.19):
	telnet-0.17-31.EL4.3


During digging behind strange DNS requests receiving my DNS server I
found, that there must be something broken in resolver/client address
handling.

Scenario:
- - DNS-Server with catch-all zone(s) [catch-all is used for easyness]
- - Client has at least one search suffix configured in /etc/resolv.conf
- - Client want to connect to a hostname which isn't resolvable

What happens now:
Search prefices from /etc/resolv.conf are used during resolving. In
principle, this is ok (but can be discussed now...).

What happen on IPv4/IPv6 mixed environments:
Same, as for IPv4, but at a client uses the resolved addresses in a
strange and unexpected order.


How to test:
0) I supply a DNS zone containing following:

$ dig +short axfr getaddrinfo.bieringer.de  @ns.bieringer.de
ns.bieringer.de. hostmaster.bieringer.de. 2006072201 86400 7200 2592000 3600
ns.bieringer.de.
"*.1.getaddrinfo.bieringer.de has (only) a TXT record"
"*.2.getaddrinfo.bieringer.de has AAAA and a TXT record"
fec0::2
"*.3.getaddrinfo.bieringer.de has A and a TXT record"
127.0.0.3
"*.4.getaddrinfo.bieringer.de has A, AAAA and a TXT record"
fec0::4
127.0.0.4
ns.bieringer.de. hostmaster.bieringer.de. 2006072201 86400 7200 2592000 3600


I've setup a wildcard zone, but it would be easy to generate answers
relating to the query on the fly (e.g. for hostname->addr lookups where
hostname already include IPv4 address in an encoded way).


1) Extend your /etc/resolv.conf using following search suffices:

search 1.getaddrinfo.bieringer.de 2.getaddrinfo.bieringer.de
3.getaddrinfo.bieringer.de 4.getaddrinfo.bieringer.de


2) Add some IPv6 addresses on your system to the loopback device:

# for i in 1 2 3 4; do ip addr add  fec0::$i dev lo; done


3) Connect to a unknown host with e.g. "telnet" or "ssh"

$ telnet test.unknown
Trying 127.0.0.3...
telnet: connect to address 127.0.0.3: Connection refused
Trying fec0::2...
telnet: connect to address fec0::2: Connection refused


Same happen with ssh

$ ssh -p 29 -v test.unknown
OpenSSH_4.3p2, OpenSSL 0.9.8a 11 Oct 2005
debug1: Reading configuration data /home/peter/.ssh/config
debug1: Applying options for *
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Applying options for *
debug1: Connecting to test.unknown [127.0.0.3] port 29.
debug1: connect to address 127.0.0.3 port 29: Connection refused
debug1: Connecting to test.unknown [fec0::2] port 29.
debug1: connect to address fec0::2 port 29: Connection refused
ssh: connect to host test.unknown port 29: Connection refused


This means "telnet", "ssh" (other clients, too) try to connect

*1*) test.unknown.3.getaddrinfo.bieringer.de via IPv4
	-> *3rd* matching search suffix

*2*) test.unknown.2.getaddrinfo.bieringer.de via IPv6
	-> *2nd* matching search suffix


Imho, some questions are rising up here:

- - why is on mixed IPv4/IPv6 enabled environments the order wrong, I
would expect to connect first via IPv6 to
test.unknown.2.getaddrinfo.bieringer.de

- - and second...I would expect that no further (IPv4) connect is made to
a different host than test.unknown.2.getaddrinfo.bieringer.de


Looks like this is a combination of problems of resolver and the use of
the resolved data by a client in some general way in mixed IPv4/IPv6
environments.


Related Red Hat Bugzilla entries:
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=181061
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=199680


Probably other standard resolver using clients or servers (on
double-reverse-lookup) are affected.

Perhaps this can be happen also on another Unix like OS.

Feel free to test your implementation using the zone I provided ... but
take care, all requests are logged ;-)



BTW: there is another issue that too much lookups are done, see the
current query sequence here:

 AAAA? test.unknown. (30)
 AAAA? test.unknown.1.getaddrinfo.bieringer.de. (57)
 AAAA? test.unknown.2.getaddrinfo.bieringer.de. (57) [successful AAAA]
 A? test.unknown. (30)
 A? test.unknown.1.getaddrinfo.bieringer.de. (57)
 A? test.unknown.2.getaddrinfo.bieringer.de. (57)
 A? test.unknown.3.getaddrinfo.bieringer.de. (57) [successful A]

I would expect a different order at all but I think this is a related
problem.

 AAAA? test.unknown. (30)
 A? test.unknown. (30)
 AAAA? test.unknown.1.getaddrinfo.bieringer.de. (57)
 A? test.unknown.1.getaddrinfo.bieringer.de. (57)
 AAAA? test.unknown.2.getaddrinfo.bieringer.de. (57) [successful AAAA]
 A? test.unknown.2.getaddrinfo.bieringer.de. (57)
 A? test.unknown.3.getaddrinfo.bieringer.de. (57) [successful A, but
different name than successful AAAA, skipped!]


Note that current behavior can also lead to some delay problems during
DNS timeouts.


Happy testing.

Regards,
	Peter
- --
Dr. Peter Bieringer                     http://www.bieringer.de/pb/
GPG/PGP Key 0x958F422D                       mailto:pb@...ringer.de
Deep Space 6 Co-Founder and Core Member  http://www.deepspace6.net/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.4 (GNU/Linux)
Comment: GnuPT 2.8.4
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iD8DBQFEwjGae1eqe5WPQi0RAlYiAJ9B/zAY3eI4uWzKC3FE74Et9ce/BACfeeHv
6e53tzbY22pOWxbrJ3TMmM0=
=IC16
-----END PGP SIGNATURE-----

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/

Powered by blists - more mailing lists