Repository navigation
Nmap "system routes" error as root on FreeBSD (nping too) #2379
Description
Describe the bug
Running Nmap as root, or using sudo, on FreeBSD returns the following error:
[ben@bepratt-dev ~]$ sudo nmap localhost
Starting Nmap 7.92SVN ( https://nmap.org ) at 2021-10-11 10:34 CDT
route_dst_generic: Failed to obtain system routes: getsysroutes_dnet: route_open() failed
To Reproduce
- Install fresh version of FreeBSD 12.2 or FreeBSD 13.0
- Update to latest build using freebsd-update
- Install git, gmake, and autoconf using pkg utility
- clone latest Nmap code from https://github.com/nmap/nmap.git
- $ ./configure
- $ gmake
- # gmake install
- $ gmake clean
- $ nmap localhost
- # nmap localhost
Expected behavior
The expected behavior is to have Nmap port scan the local system.
Version info (please complete the following information):
- OS: FreeBSD 13.0-RELEASE-p4, FreeBSD 12.2-RELEASE, and FreeBSD 12.2-RELEASE-p10 with "pkg upgrade" having system fully current
- Output of
nmap --version:
[ben@SCSUbsd1 ~]$ sudo nmap --version
Nmap version 7.92SVN ( https://nmap.org )
Platform: x86_64-unknown-freebsd13.0
Compiled with: nmap-liblua-5.3.5 openssl-1.1.1k-freebsd libssh2-1.9.0 libz-1.2.11 libpcre-8.45 libpcap-1.9.1 nmap-libdnet-1.12 ipv6
Compiled without:
Available nsock engines: kqueue poll select
- Output of
nmap --iflist
[ben@SCSUbsd1 ~]$ nmap --iflist
Starting Nmap 7.92SVN ( https://nmap.org ) at 2021-10-11 18:49 UTC
************************INTERFACES************************
DEV (SHORT) IP/MASK TYPE UP MTU MAC
em0 (em0) 10.50.51.75/16 ethernet up 1500 00:50:56:8A:7F:2A
em0 (em0) fe80:1::250:56ff:fe8a:7f2a/128 ethernet up 1500 00:50:56:8A:7F:2A
lo0 (lo0) 127.0.0.1/8 loopback up 16384
lo0 (lo0) ::1/128 loopback up 16384
lo0 (lo0) fe80:2::1/128 loopback up 16384
ROUTES: NONE FOUND(!)
[ben@SCSUbsd1 ~]$ sudo nmap --iflist
Starting Nmap 7.92SVN ( https://nmap.org ) at 2021-10-11 18:49 UTC
************************INTERFACES************************
DEV (SHORT) IP/MASK TYPE UP MTU MAC
em0 (em0) 10.50.51.75/16 ethernet up 1500 00:50:56:8A:7F:2A
em0 (em0) fe80:1::250:56ff:fe8a:7f2a/128 ethernet up 1500 00:50:56:8A:7F:2A
lo0 (lo0) 127.0.0.1/8 loopback up 16384
lo0 (lo0) ::1/128 loopback up 16384
lo0 (lo0) fe80:2::1/128 loopback up 16384
ROUTES: NONE FOUND(!)
Additional context
Running Nmap as a standard user successfully runs a port scan of the local machine.
Running Nmap as root returns an error stating "route_dst_generic: Failed to obtain system routes: getsysroutes_dnet: route_open() failed".
Running "nmap -sT localhost" returns the same error. I tried this because the default scan for a root user may be different than a standard user.
I believe I was able to run an Nmap port scan as root on FreeBSD 12.2 in early 2021 but FreeBSD 12.2-RELEASE now fails. I'm sorry but I'm not sure when this began failing but I believe it was sometime in the April 2021 timeframe.
Activity
benpratt commentedon Nov 23, 2021
It looks like a big Nmap update came out today and still having the root system route issue.
Also of note, IPv6 is also having the routing issue:
[ben@SCSUbsd1 ~]$ nmap -6 ::1
Starting Nmap 7.92SVN ( https://nmap.org ) at 2021-11-23 20:32 UTC
Nmap scan report for localhost (::1)
Host is up (0.00011s latency).
Not shown: 997 closed tcp ports (conn-refused)
PORT STATE SERVICE
22/tcp open ssh
80/tcp open http
3128/tcp open squid-http
Nmap done: 1 IP address (1 host up) scanned in 6.29 seconds
[ben@SCSUbsd1 ~]$ sudo nmap -6 ::1
Starting Nmap 7.92SVN ( https://nmap.org ) at 2021-11-23 20:32 UTC
route_dst_generic: Failed to obtain system routes: getsysroutes_dnet: route_open() failed
benpratt commentedon Jan 4, 2022
I just tried nping and had the same issue:
root@SCSUbsd1:~ # nping google.com
route_dst_generic: Failed to obtain system routes: getsysroutes_dnet: route_open() failed
root@SCSUbsd1:~ # nping -V
Nping version 0.7.92SVN ( https://nmap.org/nping )
root@SCSUbsd1:~ #
[-]Nmap "system routes" error as root on FreeBSD[/-][+]Nmap "system routes" error as root on FreeBSD (nping too)[/+]benpratt commentedon Feb 15, 2022
After some more digging I've determined that the commit of libdnet-stripped code on 2020-10-13 in revision 38110 appears to be what broke root's ability to run Nmap on FreeBSD. Running 'svn up -r38109' then compiling allows root to run 'nmap localhost' but 'svn up -r38110' results in the error previously mentioned.
Here's the info on the commit:
[ben@freebsd13 ~/nmap]$ svn up -r38110
Updating '.':
U libdnet-stripped/acconfig.h
U libdnet-stripped/libdnet-stripped.vcxproj
U libdnet-stripped/configure
U libdnet-stripped/include/config.h.in
U libdnet-stripped/include/dnet_winconfig.h
U libdnet-stripped/configure.in
D libdnet-stripped/src/strlcat.c
U libdnet-stripped/src/Makefile.in
Updated to revision 38110.
[ben@freebsd13 ~/nmap]$ svn info
Path: .
Working Copy Root Path: /usr/home/ben/nmap
URL: https://svn.nmap.org/nmap
Relative URL: ^/nmap
Repository Root: https://svn.nmap.org
Repository UUID: e0a8ed71-7df4-0310-8962-fdc924857419
Revision: 38110
Node Kind: directory
Schedule: normal
Last Changed Author: dmiller
Last Changed Rev: 38110
Last Changed Date: 2020-10-13 15:13:38 -0500 (Tue, 13 Oct 2020)
dmiller-nmap commentedon Feb 17, 2022
Thanks for hunting this down. The commit ID on github is a5cca6f and it removes an implementation of
strlcatthat I believed to be unused in the source. We'll look into it.benpratt commentedon Mar 23, 2022
I've been able to do a bit more digging, and a lot of learning, and have created a patch which appears to resolve the issue. I am unsure what the consequences of this patch are but applying the attached diff file (attached as a .txt) to libdnet-stripped/configure allows me to run Nmap as root.
2379-Patch.txt
Edit: After a bit more digging it looks like the patch adds back some code that is documented a manual on gnu.org so I'm guessing adding it back should have little negative consequences.
nnposter commentedon Mar 24, 2022
Here is my quick guess about what is going on:
#ifdef HAVE_SYS_TYPES_Hfromlibdnet-stripped/configure. It merely regenerated the file fromlibdnet-stripped/configure.in, which did not include this code even before this commit.#ifdef HAVE_SYS_TYPES_Hand the adjacent#ifdef HAVE_SYS_SOCKET_Hwere added tolibdnet-stripped/configure, but only the latter was added tolibdnet-stripped/configure.in.In summary, the fix could be to retrofit
libdnet-stripped/configure.inaccordingly, which seems safe to do:Or, perhaps even cleaner, would be to leverage AC_INCLUDES_DEFAULT instead:
Either of these two patches should rectify the issue.
nnposter commentedon Mar 24, 2022
@benpratt I do not have a FreeBSD environment readily available. Could you please test the second patch, the one with AC_INCLUDES_DEFAULT? (Do not forget to regenerate
libdnet-stripped/configurebefore running it.)benpratt commentedon Mar 24, 2022
I certainly can. How do I regenerate 'libdnet-stripped/configure'? Is there a command I can run?
nnposter commentedon Mar 24, 2022
Just running
autoconfin that directory should do it.benpratt commentedon Mar 25, 2022
I'm sorry for the delayed response. The second patch appears to have worked. To ensure I did everything properly my process was:
patch nmap/libdnet-stripped/configure.in < patch.diffIn nmap/libdnet-stripped run autoconf. This did produce a warning about me using a different version of autoconf but appeared to finish successfully.
In nmap/ run .configure, gmake, sudo gmake install.
Test with 'sudo nmap localhost'.
Thank you @nnposter for your help in developing this patch.
nnposter commentedon Mar 27, 2022
This patch will be committed after April 15 unless concerns are raised.
The full scope of the update will be:
libdnet-stripped/configure.inlibdnet-stripped/NMAP_MODIFICATIONSlibdnet-stripped/configurennposter commentedon Apr 20, 2022
The fix has been committed as r38374. Thank you for reporting the issue and tracking down the root cause.
Add missing includes to route.h test for FreeBSD. Fixes nmap#2379