Full Disclosure mailing list archives
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
From: Peter Bieringer <pb () bieringer de>
Date: Sat, 22 Jul 2006 16:09:34 +0200
-----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 () bieringer 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/
Current thread:
- 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 Peter Bieringer (Jul 22)
- Re: 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 Juri Haberland (Jul 22)
- Re: 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 Valdis . Kletnieks (Jul 22)