Skip to content

Nmap "system routes" error as root on FreeBSD (nping too) #2379

Closed

Description

@benpratt

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

  1. Install fresh version of FreeBSD 12.2 or FreeBSD 13.0
  2. Update to latest build using freebsd-update
  3. Install git, gmake, and autoconf using pkg utility
  4. clone latest Nmap code from https://github.com/nmap/nmap.git
  5. $ ./configure
  6. $ gmake
  7. # gmake install
  8. $ gmake clean
  9. $ nmap localhost
  10. # 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

  1. benpratt commented on Nov 23, 2021

    @benpratt
    Author

    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

  2. benpratt commented on Jan 4, 2022

    @benpratt
    Author

    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:~ #

  3. changed the title [-]Nmap "system routes" error as root on FreeBSD[/-] [+]Nmap "system routes" error as root on FreeBSD (nping too)[/+] on Jan 4, 2022
  4. benpratt commented on Feb 15, 2022

    @benpratt
    Author

    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)

  5. dmiller-nmap commented on Feb 17, 2022

    @dmiller-nmap

    Thanks for hunting this down. The commit ID on github is a5cca6f and it removes an implementation of strlcat that I believed to be unused in the source. We'll look into it.

  6. benpratt commented on Mar 23, 2022

    @benpratt
    Author

    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.

  7. nnposter commented on Mar 24, 2022

    @nnposter

    Here is my quick guess about what is going on:

    • Commit a5cca6f did not intentionally/explicitly remove #ifdef HAVE_SYS_TYPES_H from libdnet-stripped/configure. It merely regenerated the file from libdnet-stripped/configure.in, which did not include this code even before this commit.
    • The real issue comes from a much earlier commit, 4c3450c, which somehow pushed inconsistent code, where both #ifdef HAVE_SYS_TYPES_H and the adjacent #ifdef HAVE_SYS_SOCKET_H were added to libdnet-stripped/configure, but only the latter was added to libdnet-stripped/configure.in.

    In summary, the fix could be to retrofit libdnet-stripped/configure.in accordingly, which seems safe to do:

    --- a/libdnet-stripped/configure.in	2020-10-14 21:08:09.275534843 -0600
    +++ b/libdnet-stripped/configure.in	2022-03-23 18:02:44.842111434 -0600
    @@ -177,6 +177,9 @@
     	AC_CHECK_HEADERS(hpsecurity.h stropts.h)
     	AC_CHECK_HEADERS(net/route.h, [], [],
        [
    +#ifdef HAVE_SYS_TYPES_H
    +#include <sys/types.h>
    +#endif
     #ifdef HAVE_SYS_SOCKET_H
     #include <sys/socket.h>
     #endif

    Or, perhaps even cleaner, would be to leverage AC_INCLUDES_DEFAULT instead:

    --- a/libdnet-stripped/configure.in	2020-10-14 21:08:09.275534843 -0600
    +++ b/libdnet-stripped/configure.in	2022-03-23 18:02:44.842111434 -0600
    @@ -177,6 +177,7 @@
     	AC_CHECK_HEADERS(hpsecurity.h stropts.h)
     	AC_CHECK_HEADERS(net/route.h, [], [],
        [
    +AC_INCLUDES_DEFAULT
     #ifdef HAVE_SYS_SOCKET_H
     #include <sys/socket.h>
     #endif

    Either of these two patches should rectify the issue.

  8. nnposter commented on Mar 24, 2022

    @nnposter

    @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/configure before running it.)

  9. benpratt commented on Mar 24, 2022

    @benpratt
    Author

    @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/configure before running it.)

    I certainly can. How do I regenerate 'libdnet-stripped/configure'? Is there a command I can run?

  10. nnposter commented on Mar 24, 2022

    @nnposter

    Just running autoconf in that directory should do it.

  11. benpratt commented on Mar 25, 2022

    @benpratt
    Author

    I'm sorry for the delayed response. The second patch appears to have worked. To ensure I did everything properly my process was:

    1. Create a file called patch.diff with the following code:

    --- a/libdnet-stripped/configure.in 2020-10-14 21:08:09.275534843 -0600
    +++ b/libdnet-stripped/configure.in 2022-03-23 18:02:44.842111434 -0600
    @@ -177,6 +177,7 @@
    AC_CHECK_HEADERS(hpsecurity.h stropts.h)
    AC_CHECK_HEADERS(net/route.h, [], [],
    [
    +AC_INCLUDES_DEFAULT
    #ifdef HAVE_SYS_SOCKET_H
    #include <sys/socket.h>
    #endif

    1. Patch the file

    patch nmap/libdnet-stripped/configure.in < patch.diff

    1. In nmap/libdnet-stripped run autoconf. This did produce a warning about me using a different version of autoconf but appeared to finish successfully.

    2. In nmap/ run .configure, gmake, sudo gmake install.

    3. Test with 'sudo nmap localhost'.

    Thank you @nnposter for your help in developing this patch.

  12. nnposter commented on Mar 27, 2022

    @nnposter

    This patch will be committed after April 15 unless concerns are raised.

    The full scope of the update will be:

    • Applying the second patch from above to libdnet-stripped/configure.in
    • Adding the change to tracking file libdnet-stripped/NMAP_MODIFICATIONS
    • Regenerating libdnet-stripped/configure
  13. self-assigned this
    on Mar 27, 2022
  14. deleted a comment from on Apr 11, 2022
  15. nnposter commented on Apr 20, 2022

    @nnposter

    The fix has been committed as r38374. Thank you for reporting the issue and tracking down the root cause.

  16. added a commit that references this issue on Mar 4, 2024
    db39ee0
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Type

No type

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions