Full Disclosure mailing list archives
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
From: Peter Bieringer <pb () bieringer de>
Date: Tue, 25 Jul 2006 10:29:42 +0200
On Sat, 22 Jul 2006 16:09:34 +0200, Peter Bieringer said:Linux / Fedora Core 5 (glibc-2.4-8):Known deficiency in glibc. Code to do RFC3484 precedence tables landed in Fedora Rawhide the first half of May and is in FC6-test. I don't know the status of that glibc code landing in RHEL 5.0. Bugzilla: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=190495 http://people.redhat.com/drepper/linux-rfc3484.html for the how-and-why. Short-form answer: Once the glibc code lands on your system, you should be able to just do this: # cp /etc/share/doc/glibc-common-2.<mumble>/gai.conf /etc # vi /etc/gai.conf and configure whatever flavor of precedence you wanted for your particular network configuration. and tell it what order you want addresses tried on
I tried this glibc version on FC5, this will only fix the sort order (precedence of IPv6 before IPv4). But this won't fix the real issue. This new behavior would lead to more problems! The main problem is the current implementation which looks like following: for $suffix in ("", searchsuffices(/etc/resolv.conf)) { $result_aaaa = lookup(AAAA,$host.$suffix) if (defined $result_aaaa) { break; }; }; for $suffix in ("", searchsuffices(/etc/resolv.conf)) { $result_a = lookup(A, $host.$suffix) if ($defined result_a) { break; }; }; sortresults($result_a, $result_aaaa) E.g. following can happen: AAAA? www.redhat.com. (32) AAAA? www.redhat.com. (43) AAAA? www.redhat.com.2.getaddrinfo.bieringer.de. (59) A? www.redhat.com. (32) 2 successful queries, but *2* different hosts! Depending on sort algorithm, this can lead to connect to www.redhat.com.2.getaddrinfo.bieringer.de via IPv6 first, and if successful, there is no reason for the client to www.redhat.com via IPv4. This can be used for delivering unwanted IPv6 addresses to clients by only adding a prepared search suffix to /etc/resolv.conf. If client is IPv6 enabled, it never reached the host via IPv4. Details for demonstration can be found here: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=190495#c30 A proper working implementation has to work like following: for $suffix in ("", searchsuffices(/etc/resolv.conf)) { $result_aaaa = lookup(AAAA,$host.$suffix) $result_a = lookup(A, $host.$suffix) if (defined $result_aaaa || $defined result_a) { break; }; } sortresults($result_a, $result_aaaa) In this case, only following queries are made: AAAA? www.redhat.com. (32) A? www.redhat.com. (32) And client only gets IPv4 address for www.redhat.com, nothing more at the moment (because www.redhat.com provides no AAAA record). Imho, all IPv6 enabled (g)libc version need to be fixed if not already working proper. 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/ OpenBC http://www.openbc.com/hp/Peter_Bieringer/ Personal invitation to OpenBC http://www.openbc.com/go/invita/3889 _______________________________________________ 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:
- 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 Peter Bieringer (Jul 25)