full-disclosure - 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

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

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [day] [month] [year] [list]

Message-ID: <44C5D676.4010005@bieringer.de>
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/