Nmap Development mailing list archives
AW: Nmap/Nping bug on udp checksum calculation
From: "Michael Weber" <post () michaelweber biz>
Date: Tue, 5 Nov 2013 09:49:11 +0100
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/
Current thread:
- Nmap/Nping bug on udp checksum calculation Michael Weber (Nov 02)
- Re: Nmap/Nping bug on udp checksum calculation Luis MartinGarcia. (Nov 03)
- Re: Nmap/Nping bug on udp checksum calculation Luis MartinGarcia. (Nov 03)
- Re: Nmap/Nping bug on udp checksum calculation David Fifield (Nov 10)
- Re: Nmap/Nping bug on udp checksum calculation Daniel Miller (Nov 04)
- Re: Nmap/Nping bug on udp checksum calculation David Fifield (Nov 04)
- AW: Nmap/Nping bug on udp checksum calculation Michael Weber (Nov 05)
- Re: Nmap/Nping bug on udp checksum calculation Luis MartinGarcia (Nov 05)
- Re: Nmap/Nping bug on udp checksum calculation Daniel Miller (Nov 05)
- Re: Nmap/Nping bug on udp checksum calculation David Fifield (Nov 04)