Re: U1 probe RUD test question

[David Fifield <david () bamsoftware com>]

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