Nmap Development mailing list archives
Re: Bug in nmap 5.20 (nsock_core.c:516: handle_write_result)
From: David Fifield <david () bamsoftware com>
Date: Thu, 21 Jan 2010 13:28:07 -0700
On Wed, Jan 20, 2010 at 11:23:35PM -0700, David Fifield wrote:
On Wed, Jan 20, 2010 at 10:57:13PM +0200, pyllyukko wrote:So I downloaded the brand new nmap 5.20 and set off to scan my lan. nmap suddenly crashed stating: "nmap: nsock_core.c:516: handle_write_result: Assertion `bytesleft > 0' failed". I briefly tried to debug it, and narrowed down the cause. Here's the exact command used, it's 100% reproducible (on my system, that is): nmap -sS --script http-userdir-enum.nse --script-args=unsafe=1 - --script-trace -PR -T 4 -p80 -oA 192.168.0.2-%Y%m%d%R-debug -d9 - --log-errors --reason -R 192.168.0.2 Here's the last few lines of the debug output: NSOCK (0.1860s) Write request for 149 bytes to IOD #3 EID 91 [192.168.0.2:80] NSOCK (0.1860s) nsock_loop() started (timeout=50ms). 1 events pending NSOCK (0.1860s) Callback: WRITE SUCCESS for EID 91 [192.168.0.2:80] NSE: TCP 192.168.0.35:37821 > 192.168.0.2:80 | CLOSE NSE: Received only 0 of 1 expected reponses. Decreasing max pipelined requests to 0. NSOCK (0.1870s) TCP connection requested to 192.168.0.2:80 (IOD #4) EID 96 NSOCK (0.1870s) nsock_loop() started (timeout=50ms). 1 events pending NSOCK (0.1870s) Callback: CONNECT SUCCESS for EID 96 [192.168.0.2:80] NSE: TCP 192.168.0.35:37822 > 192.168.0.2:80 | CONNECT NSE: TCP 192.168.0.35:37822 > 192.168.0.2:80 | NSOCK (0.1870s) Write request for 0 bytes to IOD #4 EID 107 [192.168.0.2:80]: nmap: nsock_core.c:516: handle_write_result: Assertion `bytesleft > 0' failed. NSOCK (0.1880s) nsock_loop() started (timeout=50ms). 1 events pending Now what?-)Thanks. Brandon Enright found this bug today too. It has to do with recent changes to the http library. What's happening is there is an error getting the first pipeline response, and so the code erroneously reduces the pipeline capacity to 0, when it really should bail out. It then tries to do a zero-byte write, which causes the assertion failure.
I think this is solved now. There were a few related problems. First, the HTTP server was sending a body in response to a HEAD request, which violates the protocol standard. Of course that shouldn't cause Nmap to crash, but this won't happen against servers that handle HEAD properly. A second problem was that the HTTP pipeline code didn't handle its first round of pipelining properly. When it determined that a server didn't support pipelining, it would set its pipeline limit to 1, but it didn't check this limit until once through the loop, so it would send 2 requests on the first connection. (It was off by one in all cases; for example it would send 41 requests the first time if the server advertised 40, but the case of 1 had the worst result.) This interacted badly with another bug, which I think was my fault, where the pipeline limit could be adjusted down to 0. In this case the code would try to do a zero-byte write, which tripped an assertion falure in Nsock. (Which is a separate issue.) David Fifield _______________________________________________ Sent through the nmap-dev mailing list http://cgi.insecure.org/mailman/listinfo/nmap-dev Archived at http://seclists.org/nmap-dev/
Current thread:
- Bug in nmap 5.20 (nsock_core.c:516: handle_write_result) pyllyukko (Jan 20)
- Re: Bug in nmap 5.20 (nsock_core.c:516: handle_write_result) David Fifield (Jan 20)
- Re: Bug in nmap 5.20 (nsock_core.c:516: handle_write_result) David Fifield (Jan 21)
- Re: Bug in nmap 5.20 (nsock_core.c:516: handle_write_result) David Fifield (Jan 20)