AW: Nmap/Nping bug on udp checksum calculation

["Michael Weber" <post () michaelweber biz>]

Hi,
A frame with a 0x0000 checksum will still be processed by the target
machine.
But an all zero checksum tells the receiving machine that no checksum was
calculated by the sender.
This may result in not recognizing erroneous received frames as faulty.
Wireshark, if checksum calculation for UDP is enabled, will not mark a
captured packet as checksum good/bad
as it handles an all zero checksum as if the sender did not include a
checksum.

Michael Weber


-----Ursprüngliche Nachricht-----
Von: David Fifield [mailto:david () bamsoftware com] 
Gesendet: Montag, 4. November 2013 23:57
An: Daniel Miller
Cc: Michael Weber; dev () nmap org
Betreff: Re: Nmap/Nping bug on udp checksum calculation

On Mon, Nov 04, 2013 at 04:15:52PM -0600, Daniel Miller wrote:
> On 11/02/2013 05:38 PM, Michael Weber wrote:
> > Sending UDP data can contain but must not contain a checksum. The 
> > checksum, must be transmitted as all ones if the calculated value is 
> > all zero. An all zero value denotes that no checksum has been 
> > calculated (see rfc 768) In Nmap the checksum is calculated in 
> > netutil.cc (ipv4_pseudoheader_cksum) called from within UDPHeader.cc 
> > (UDPHeader::setSum) as a quick search in the sources revealed.
> > I think the return value must be checked for zero like it's done in 
> > ipv6_pseudoheader_cksum before it is returned or, if that will lead 
> > to some trouble for TCP  checksum calculation, must be checked in 
> > UDPHeader::setSum before the method returns.
> Michael,
>
> Thanks for catching this! I wrote some crappy test code to check how 
> often this would occur. Given an empty UDP packet from my machine to 
> scanme.nmap.org with random source and destination ports, a 0x0000 
> checksum was generated 0.001527% of the time (1 in 65488 chance, so 
> I'm guessing overall it's closer to 1:65535).
>
> The patch below should fix this. I did a check for everywhere in the 
> Nmap source that a UDP header's uh_sum attribute was set, and they all 
> stemmed from ipv6_pseudoheader_cksum and ipv4_pseudoheader_cksum, so I 
> just copied the check code over. I also moved the call to 
> ip_cksum_carry() to before the check in both cases, since that alters 
> the value before the check for +/-0 should be done.
>
> Please check the code below and let me know if it looks safe to 
> commit. I'm looking forward to killing this bug!

The patch looks right to me.

What was the effect of sometimes sending a checksum of 0x0000? I assume the
packets were being marked in Wireshark somehow. Were they also being ignored
by targets?

David Fifield

_______________________________________________
Sent through the dev mailing list
http://nmap.org/mailman/listinfo/dev
Archived at http://seclists.org/nmap-dev/