Mailing-List: contact bugs-help@httpd.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Apache HTTPD Bugs Notification List" <bugs@httpd.apache.org>
From: bugzilla@apache.org
To: bugs@httpd.apache.org
Subject: DO NOT REPLY [Bug 40841]  New:  - mod_proxy_ftp segfaults on IPv4
 requests to hosts with DNS AAAA records
Message-ID: <bug-40841-7868@http.issues.apache.org/bugzilla/>
Date: Sun, 29 Oct 2006 07:04:28 -0800 (PST)

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG�
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://issues.apache.org/bugzilla/show_bug.cgi?id=40841>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND�
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=40841

           Summary: mod_proxy_ftp segfaults on IPv4 requests to hosts with
                    DNS AAAA records
           Product: Apache httpd-2
           Version: 2.3-HEAD
          Platform: All
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P2
         Component: mod_proxy
        AssignedTo: bugs@httpd.apache.org
        ReportedBy: arjones@simultan.dyndns.org


On an IPv6-enabled host with an IPv6-enabled Apache, but only IPv4 connectivity
to the Internet, proxy requests for FTP data from FTP servers that have an IPv6
(and IPv4) entry in DNS cause the assigned Apache worker process to crash with a
SIGSEGV. There are two reasons for this. The first is that apr_socket_connect()
doesn't check its input parameters to see if they are NULL before dereferencing
them. The second is that proxy_ftp_handler() first does a lookup with
apr_sockaddr_info_get(), which primarily returns the AAAA record, and family ==
AF_INET6. Later, i assume during ap_proxy_acquire_connection(),
ap_proxy_connect_backend(), or ap_proxy_connection_create(), something is
intelligent enough to figure out that the IPv6 address cannot be reached, and
uses the IPv4 address for the control connection. Over the control connection,
the EPSV command is issued. After the result is returned (assuming the server
supports EPSV), apr_sockaddr_info_get() is called with connect_addr->family as
the family parameter, and data_ip as the address. connect_addr->family still has
AF_INET6, but data_ip has the IPv4 address of the server. This causes glibc to
return EAI_ADDRFAMILY, and epsv_addr is left NULL. That is passed to
apr_socket_connect(), and we know what happens after that.

In addition, there is the potential for a *slight* performance improvement. On
line 1235 of mod_proxy_ftp.c apr_sockaddr_info_get() is called with flags == 0.
Since, as far as i can determine, these flags are passed to getaddrinfo(), if
flags is set to at least AI_NUMERICHOST (this is guarunteed by the code above),
some coding and/or DNS lookups could be avoided. The 0 can't simply be replaced
with AI_NUMERICHOST, because the proper header file (netdb.h on Linux) is not
included.

I am attaching a patch to fix both problems. I realize that the first problem is
in APR, and not in Apache, but i ran across both as part of my attempt to fix my
problem.

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

---------------------------------------------------------------------
To unsubscribe, e-mail: bugs-unsubscribe@httpd.apache.org
For additional commands, e-mail: bugs-help@httpd.apache.org