On platforms supporting sa_len, NEXTIFR would skip over sa_len bytes
starting at the beginning of ifr_addr, and assume that was the end of
the struct. (The idea being that a large address such as a sockaddr_in6
could overflow the nominal struct boundary.) This logic was wrong when
there was something else in the union bigger than sa_len; we would
increment into somewhere in the middle of the same struct.
This exhibited itself on NetBSD, where struct ifreq has a
sockaddr_storage member in its internal union:
struct ifreq {
char ifr_name[IFNAMSIZ]; /* if name, e.g. "en0" */
union {
struct sockaddr ifru_addr;
struct sockaddr ifru_dstaddr;
struct sockaddr ifru_broadaddr;
struct sockaddr_storage ifru_space;
No, we skip over sa_len bytes, or to the nominal end of the struct,
whichever is larger.
Unix Network Programming gets this wrong too; in figure 17.8 they do
ptr += sizeof(ifr->ifr_name) + max(sizeof(struct sockaddr), ifr->ifr_addr.sa_len);
John Spencer reported that musl libc doesn't automatically include
<stdlib.h>, as Glibc does, so the configure check was wrongly failing.
conftest.c: In function 'main':
conftest.c:35:5: error: implicit declaration of function 'exit'
smb.get_os already returns something that is fairly well structured, so
basically return that. Keep the "os" and "lanmanager" fields separate,
though they are combined as "os (lanmanager)" for normal output. Combine
"time" and "timezone" into a single "date" output.
This takes a broken-down date table, as produced by os.date("*t"), and
converts it into an integer number of seconds since the epoch UTC,
interpreting it as a time in a given time zone. Simply passing a date
table to os.time is not good enough, because os.time always assumes the
date table represents a local time; i.e., you will get different results
from running os.time({year=2012,month=1,day=1,hour=12,min=0,sec=0})
depending on what time zone you run it in.
The new version improves the detection mechanism to cover PHP environments with .htaccess files and adds spidering to locate password protected resources automatically.
This happens on Windows when two sockets bind to the same local port and
connect to the same remote port on a remote host. I tried this on Linux;
Linux prevents the second bind from succeeding.
http://seclists.org/nmap-dev/2012/q2/513
Otherwise WinSock error numbers are not understood; you get "Unknown
error" instead of "Only one usage of each socket address
(protocol/network address/port) is normally permitted." for example.
It is possible to send so quickly that we start getting EAGAIN on sends.
In listen mode, this means that some sends can get lost. This patch,
adapted from one by Alex Weber, makes sockets blocking for the duration
of the send. This is not as nice as retrying the send through an event
mechanism, but should at least be correct.
http://seclists.org/nmap-dev/2012/q3/670
Compare a similar patch in r13552, which applied to --exec mode.
Using o.magic_port, which is usually used for our source address, or
otherwise is somewhat randomly generated, doesn't make sense here.
Instead, use the same destination ports that we use for host discovery:
80 for TCP and SCTP, and 40125 for UDP.
http://seclists.org/nmap-dev/2012/q3/663
If we get a reply that doesn't pass the simple comparison using the
current value of USI->seqmask, then ignore it. Previously we emitted the
message "Bad Sequence number from host %s.\n" and allowed the reply to
match any probe. This only matters when using -g because otherwise we
encode that information in the source port. I think we have addressed
what was mentioned in the TODO comment in r15986. Allowing promiscuous
matching, as was done before, causes the same spurious closed port issue
that was addressed in r29686.
