mirror of
https://github.com/nmap/nmap.git
synced 2026-08-27 03:48:14 +00:00
Simplify and document the invalid destination options header.
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.
This commit is contained in:
parent
64722d1b7b
commit
d8ce681711
1 changed files with 17 additions and 6 deletions
|
|
@ -56,10 +56,15 @@ end
|
|||
--- Build an IPv6 invalid extension header.
|
||||
-- @param nxt_hdr integer that stands for next header's type
|
||||
local function build_invalid_extension_header(nxt_hdr)
|
||||
local ex_invalid_opt = string.char(0x80,0x01,0xfe,0x18,0xfe,0x18,0xfe,0x18,0x0,0x0,0x0,0x0,0x0,0x0)
|
||||
-- RFC 2640, section 4.2 defines the TLV format of options headers.
|
||||
-- It is important that the first byte have 10 in the most significant
|
||||
-- bits; that instructs the receiver to send a Parameter Problem.
|
||||
-- Option type 0x80 is unallocated; see
|
||||
-- http://www.iana.org/assignments/ipv6-parameters/.
|
||||
local ex_invalid_opt = string.char(0x80,0x01,0x00,0x00,0x00,0x00)
|
||||
local ext_header =
|
||||
string.char(nxt_hdr) .. --next header
|
||||
string.char(#ex_invalid_opt/16) .. --length (16bytes)
|
||||
string.char(0) .. -- length 8
|
||||
ex_invalid_opt
|
||||
return ext_header
|
||||
end
|
||||
|
|
@ -92,10 +97,16 @@ action = function()
|
|||
probe.ip6_src = src_ip6
|
||||
probe.ip6_dst = dst_ip6
|
||||
|
||||
probe.echo_id = 5
|
||||
probe.echo_seq = 6
|
||||
probe.echo_data = "Nmap host discovery."
|
||||
probe:build_icmpv6_echo_request()
|
||||
-- In addition to setting an invalid option in
|
||||
-- build_invalid_extension_header, we set an unknown ICMPv6 type of
|
||||
-- 254. (See http://www.iana.org/assignments/icmpv6-parameters for
|
||||
-- allocations.) Mac OS X 10.6 appears to send a Parameter Problem
|
||||
-- response only if both of these conditions are met. In this we differ
|
||||
-- from the alive6 tool, which sends a proper echo request.
|
||||
probe.icmpv6_type = 254
|
||||
probe.icmpv6_code = 0
|
||||
-- Add a non-empty payload too.
|
||||
probe.icmpv6_payload = string.char(0x00, 0x00, 0x00, 0x00)
|
||||
probe:build_icmpv6_header()
|
||||
|
||||
probe.exheader = build_invalid_extension_header(packet.IPPROTO_ICMPV6)
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue