lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Tue, 25 Jul 2006 10:29:42 +0200 From: Peter Bieringer <pb@...ringer.de> To: "full-disclosure@...ts.grok.org.uk" <full-disclosure@...ts.grok.org.uk> Cc: Valdis.Kletnieks@...edu Subject: 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 > 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@...ringer.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/
Powered by blists - more mailing lists