hostcmp is documented to determine whether "a and b are considered the
same hostnames." But what it's really doing is testing whether a
contains b. This isn't even symmetric, so I think it's wrong.
Previously it was hardcoded to be sockaddr_in, which is obviously wrong
for IPv6. This was only used to filter out packets from other than the
host we are scanning. It may have still been succeeding by accident if
part of the IPv6 address had the bytes 00000000, because for me the port
number is at the same offset in sockaddr_in and sockaddr_in6, and
target->v4host().s_addr returns 00000000 for an IPv6 host.
For each rtattr we add to the netlink message, we were adding
RTA_LENGTH(rtattr->rta_len) to the length of the netlink message. But
rtattr->rta_len was already calculated as RTA_LENGTH of something, and
doing RTA_LENGTH twice made the length 4 bytes longer than it should be.
This caused a log in dmesg:
netlink: 4 bytes leftover after parsing attributes.
or
netlink: 8 bytes leftover after parsing attributes.
if there was an IPv6 scope ID (because that causes two rtattrs instead
of one).
The new code is consistent with the rtnetlink(3) man page, which does
rta->rta_len = sizeof(unsigned int);
req.n.nlmsg_len = NLMSG_ALIGN(req.n.nlmsg_len) + RTA_LENGTH(sizeof(unsigned int));
We do the equivalent
rta->rta_len = sizeof(unsigned int);
req.n.nlmsg_len = NLMSG_ALIGN(req.n.nlmsg_len) + rta->rta_len;
status code text when the variable status is not
nil. This mimics the behavior of start_session_extended.
This should provide more reliable results to smb-brute
concerning the nature of login failure reasons.
More detail has been sent to the mailing list.
The packet construction had a bug that made it more effective in at
least one case for me. Weilin had supplied a 16-byte destination options
buffer, including some random bytes from a packet capture. But the
length of buffer was set incorrectly in the packet, making it look like
it was 8 bytes instead of 16. Therefore the expected ICMPv6 packet
started in the middle of the buffer, making it appear to have a
type/code of 254/24 instead of 128/0 as expected.
I tried setting the proper length, while keeping the invalid destination
option, but then stopped getting a Parameter Problem response. I also
tried setting a proper destination options buffer with no invalid
options, followed by ICMPv6 with type/code of 128/0, and again got no
response. It appears that I get a response only when both of these
conditions are satisfied: 1) an invalid destination option exists, and
2) the ICMPv6 type is unknown. This is against OS X.
The probe was being effective by accident, but now I've simplified it
and documented these strange conditions.
This breaks any hosts that might have ignored the invalid destination
option (which they shouldn't do) and replied to the echo request. But we
have targets-ipv6-multicast-echo for that.
