Home page logo
/

nmap-dev logo Nmap Development mailing list archives

Re: U1 probe RUD test question
From: David Fifield <david () bamsoftware com>
Date: Tue, 7 Apr 2009 12:47:38 -0600

On Thu, Apr 02, 2009 at 08:13:12PM -0600, David Fifield wrote:
On Thu, Apr 02, 2009 at 05:29:51PM -0600, David Fifield wrote:
On Thu, Apr 02, 2009 at 02:52:42PM -0400, Thomas Tavaris J (Tavaris) wrote:
I'm still looking at the quality of the tests that nmap sends and I have
a question regarding the U1,RUD test. Why is this test producing a G
value when wireshark, tshark, and tcpdump data shows no UDP data  (from
the probe) is contained in the encapsulated ICMP port unreachable
packet? This is especially prevalent when scanning Cisco routers. The
nmap-os-db file says Cisco IOS should report G for the RUD test. From my
(limited) observations this hasn't been the case.

Thanks for bringing this up. There is a bug in the code that handles the
U1.RUD test. Instead of checking that the payload is 300 bytes long and
consists only of the character 'C', it only checks that every byte in
the payload is 'C' without checking the length. So the test passes even
for an empty payload.

I'm going to fix this, which will cause some OS matches to break. We'll
have to get new submissions to populate the database with correct values
for the test.

I looked into this more deeply. I ran the command

hping2 -V --rand-dest --udp -d 300 --fast --interface eth0 x.x.x.x -n

and captured all the ICMP packets that came back to me. Some of them
returned the full 300-byte payload, some of them truncated it to 120
bytes, and some truncated it to 0 bytes. However, all of them had the
length in the encapsulated UDP header set to 308 bytes. (I captured
about 50 packets.)

This is relevant to the recently removed U1.RUL test, which measured the
length of returned UDP packets. It was based on the UDP header value,
not on the overall IP packet length. That explains why it showed so
little variation even though I was able to find variation in a matter of
minutes.

The U1.RUD test actually makes sense the way it is written now, when
combined with U1.RUL as it should be written. One test checks the number
of bytes and the other checks their value.

We should reinstate the U1.RUL test and fix it to be based on the IP
packet length, not the supposed encapsulated UDP length. I don't know
what to do about the database entries. We could set them all back to G
and wait for correct submissions to come in and replace them.

On third thought, making RUD depend on the length of the packet would
make it partially redundant with U1.RIPL, the total length of the
returned IP packet. If RUD depended also on the length, and the payload
was truncated, then RUD would always be "I" regardless of whether what
was left of the payload had the expected contents. That would make the
test less useful. I'm just going to update the documentation to say that
RUD checks for the presence of all 'C' bytes, no matter how many there
are.

David Fifield

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


  By Date           By Thread  

Current thread:
[ Nmap | Sec Tools | Mailing Lists | Site News | About/Contact | Advertising | Privacy ]
AlienVault