Bug 1262826

Summary: ncat: Assertion `0' failed. on ICMP type 12 (Parameter problem)
Product: Red Hat Enterprise Linux 7 Reporter: Jiri Jaburek <jjaburek>
Component: nmapAssignee: Pavel Zhukov <pzhukov>
Status: CLOSED ERRATA QA Contact: Jaroslav Aster <jaster>
Severity: medium Docs Contact:
Priority: medium    
Version: 7.2CC: dmiller, jaster, thozza
Target Milestone: rcKeywords: EasyFix, FastFix, Patch
Target Release: ---   
Hardware: Unspecified   
OS: Linux   
Whiteboard:
Fixed In Version: nmap-6.40-12.el7 Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2018-04-10 08:36:10 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Jiri Jaburek 2015-09-14 12:27:04 UTC
Description of problem:

When nc receives ICMP type 12 (any code) as a result of a connection attempt, it aborts with

$ nc 1.2.3.4 1234
Strange connect error from 1.2.3.4 (71): Protocol errornc: nsock_core.c:368: handle_connect_result: Assertion `0' failed.
Aborted

Reproducer:

On a remote machine (server), not loopback, may be network namespace:

-----------------------8<-------------------------
#!/usr/bin/python

from scapy.all import *

iface = "eth0"

def callback(p):
    if not p.haslayer(Ether):
        return
    r = Ether(src=p[Ether].dst,dst=p[Ether].src)/IP(dst=p[IP].src)/ICMP(type=12,code=1)/p[IP]
    sendp(r, iface=iface)

sniff(prn=callback, iface=iface, filter="tcp dst port 1234", store=0)
-----------------------8<-------------------------

and try connecting from the local machine as shown above.


Version-Release number of selected component (if applicable):
nmap-ncat-6.40-7.el7.x86_64

How reproducible:
always

Actual results:
nc aborts with Assertion failed

Expected results:
nc reports a connection error without abort

Additional info:
This seems to be fixed on my nmap-ncat-6.47-2.fc22.x86_64:
$ nc 1.2.3.4 1234
Strange connect error from 1.2.3.4 (71): Protocol error

Comment 1 Jiri Jaburek 2015-09-14 16:02:14 UTC
Forgot to mention - the remote machine must ignore the TCP SYN and let the scapy script reply, something like 

iptables -I INPUT -p tcp -m tcp --dport 1234 -j DROP

should be sufficient.

Comment 2 Daniel Miller 2017-03-17 20:35:25 UTC
This is a bug in the underlying Nsock library (same codebase), so it also affects Nmap and possibly Nping. The immediate fix is easy: add EPROTO to the list of errors handled. But I'm soliciting comments on potentially treating all non-success cases the same, eliminating this problem in the future, should some other platform or kernel version choose to return yet another error number. Discussion thread: http://seclists.org/nmap-dev/2017/q1/216

Regardless of approach, this will be fixed in the next upstream Ncat release. Here's the quick patch that solves this particular issue if Red Hat needs it sooner:

diff --git a/nsock/src/nsock_core.c b/nsock/src/nsock_core.c
index b8aa352..567f1e9 100644
--- a/nsock/src/nsock_core.c
+++ b/nsock/src/nsock_core.c
@@ -359,6 +359,7 @@ void handle_connect_result(struct npool *ms, struct nevent *nse, enum nse_status
       case ETIMEDOUT:
       case EHOSTDOWN:
       case ECONNRESET:
+      case EPROTO:
 #ifdef WIN32
       case WSAEADDRINUSE:
       case WSAEADDRNOTAVAIL:

Comment 3 Daniel Miller 2017-03-20 17:22:36 UTC
Complete error handling was added in upstream r36653.

Comment 12 errata-xmlrpc 2018-04-10 08:36:10 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHBA-2018:0661