IPv6 mass_dns and nsock_connect_udp

[jah <jah () zadkiel plus com>]

Hi folks,

I'm making some progress with a little project to allow mass_rdns to do
lookups for IPv6 addresses (async code rather than the system resolver)
and to connect to an IPv6 socket on dns servers - I'm using MS Visual
C++ EE.

I've changed a member of the struct dns_server_s from sockaddr_in to
sockaddr_storage and hit a snag after connect_dns_servers() calls
nsock_connect_udp().

Previously, connect_dns_servers passed a reference to a dns_server_s
sockaddr_in casted to a pointer to a sockaddr along with sizeof(struct
sockaddr) which are defined as saddr and sslen respectively in
nsock_connect_udp.
saddr is then casted to pointer to a sockaddr_storage, but sslen remains
unchanged:

nsock_event_id nsock_connect_udp(nsock_pool nsp, nsock_iod nsiod,
                 nsock_ev_handler handler, void *userdata,
                 struct sockaddr *saddr, size_t sslen,
                 unsigned short port) {

msiod *nsi = (msiod *) nsiod;
mspool *ms = (mspool *) nsp;
msevent *nse;
struct sockaddr_storage *ss = (struct sockaddr_storage *) saddr;


This doesn't seem to have any disastrous effects upon any code which
then uses sslen unless you want to connect to an IPv6 socket.
In this case sslen is too small and a call to inet_ntop_ez(ss, sslen)
which returns NULL instead of a pointer to a const char holding a
printable IP address for debug output.  A subsequent call to
nsock_connect_internal() results in a socket error 10014 - Bad address
("occurs if an application passes an invalid pointer value, or if the
length of the buffer is too small").

So my question is whether sslen should be reinitialised after casting
saddr to sockaddr_storage * ?
Something like: sslen = sizeof(*ss);

Obviously I've tried this in the context of a connection to a random
IPv6 dns server:

mass_rdns: Using DNS server 2001:a88:0:fffa::1
NSOCK (19.4220s) msevent_new (IOD #1) (EID #8)
NSOCK (19.4220s) UDP connection requested to 2001:a88:0:fffa::1:53 (IOD
#1) EID8
NSOCK (19.4220s) msevent_new (IOD #1) (EID #18)
NSOCK (19.4220s) Read request from IOD #1 [2001:a88:0:fffa::1:53]
(timeout: -1ms) EID 18
Initiating Parallel DNS resolution of 1 host. at 00:07
mass_rdns: TRANSMITTING for <2001:838:1:1:210:dcff:fe20:7c7c> (server
<2001:a88:0:fffa::1>)
NSOCK (19.4220s) msevent_new (IOD #1) (EID #27)
NSOCK (19.4220s) Write request for 90 bytes to IOD #1 EID 27
[2001:a88:0:fffa::1:53]
NSOCK (19.4220s) nsock_loop() started (timeout=500ms). 3 events pending
NSOCK (19.4220s) wait_for_events
NSOCK (19.4220s) Callback: CONNECT SUCCESS for EID 8 [2001:a88:0:fffa::1:53]
NSOCK (19.4220s) msevent_delete (IOD #1) (EID #8)
NSOCK (19.4220s) Callback: WRITE SUCCESS for EID 27 [2001:a88:0:fffa::1:53]
NSOCK (19.4220s) msevent_delete (IOD #1) (EID #27)
NSOCK (19.4220s) wait_for_events
NSOCK (19.9220s) nsock_loop() started (timeout=500ms). 1 events pending
NSOCK (19.9220s) wait_for_events
NSOCK (20.4220s) nsock_loop() started (timeout=500ms). 1 events pending
NSOCK (20.4220s) wait_for_events
NSOCK (20.8120s) Callback: READ SUCCESS for EID 18
[2001:a88:0:fffa::1:53] (90 bytes)

and as you can see we successfully wrote to and read from the socket.

This same situation seems to exist for nsock_connect_tcp and ssl too and
I am rather unsure whether this change would be proper or desirable,
whether it's just a Windows thing and whether that old adage "a little
learning is a dangerous thing" applies here.

Regards,

jah



_______________________________________________
Sent through the nmap-dev mailing list
http://cgi.insecure.org/mailman/listinfo/nmap-dev
Archived at http://SecLists.Org