Re: nmap-5.20 on x86_64 Segmentation fault

[Gunnar Lindberg <Gunnar.Lindberg () chalmers se>]

Thanks for the idea of /etc/resolv.conf - we're one step forward:

    search cdg.chalmers.se nomad.chalmers.se chalmers.se
    nameserver 129.16.1.53
    nameserver 129.16.2.53
    nameserver 2001:6b0:2:1::53
    nameserver 2001:6b0:2:2::53

If I comment out the two IPv6 resolver addresses nmap-5.20 works OK.

> > My 0.01 SEK is that something goes wrong when trying to make use of
> >     struct sockaddr_storage *
> > in get_dns_servers() and that that later on leads to corrupt data.

I'm not entirely sure, but I think "sockaddr_storage" is some kind if
"generic data struckture for all IP".

nmap-5.00/nmap_dns.cc:
    get_dns_servers()
    ...
    serverList.push_back(inet_ntoa((*servI)->addr.sin_addr))

nmap-5.20/nmap_dns.cc:
    get_dns_servers()
    ...
    serverList.push_back(inet_socktop((struct sockaddr_storage *) &(*servI)->addr));

And, NB, it's an x86_64 machine, 64 bit. These seem to turn several
things upside down - I've been hit several times when porting
ancient network software.

Maybe RedHat missed things in some x86_64 include file (I installed
g++ via "yum install gcc-c++" and got

    Installed:            gcc-c++.x86_64 0:4.1.2-46.el5_4.2
    Dependency Installed: libstdc++-devel.x86_64 0:4.1.2-46.el5_4.2

    g++ (GCC) 4.1.2 20080704 (Red Hat 4.1.2-46)

Or just that nmap-5.20 needs to include another file that will help
instruct that "sizeof(int) > 32".

I'll see to the valgring thing in a few days - RedHat don't provide
that by default so I probably have to install it myself.

        Gunnar

> From bmenrigh () ucsd edu Sun Jan 24 11:30:36 2010
> From: Brandon Enright <bmenrigh () ucsd edu>
> To: Gunnar Lindberg <gunnar.lindberg () chalmers se>
> CC: "nmap-dev () insecure org" <nmap-dev () insecure org>
> Date: Sun, 24 Jan 2010 11:31:09 +0100
> Subject: Re: nmap-5.20 on x86_64 Segmentation fault
> Message-ID: <20100124103109.4e79133a () spoke wan>
> References: <201001221632.o0MGWA9U018170 () grunert cdg chalmers se>
>       <20100124101503.0f902ce1 () spoke wan>
> In-Reply-To: <20100124101503.0f902ce1 () spoke wan>

> On Sun, 24 Jan 2010 10:15:03 +0000 or thereabouts Brandon Enright
> <bmenrigh () ucsd edu> wrote:
> > On Fri, 22 Jan 2010 17:32:10 +0100 (MET) or thereabouts Gunnar
> > Lindberg <Gunnar.Lindberg () chalmers se> wrote:
> >
> > > ./nmap 129.16.x.y
> > > Starting Nmap 5.20
> > > Segmentation fault
> [...snip...]

> > Hi Gunnar,
> >
> > I have not been able to reproduce this issue.  I have tried having
> [...snip...]

> Gunnar,

> It just occurred to me that this maybe be a completely different
> issue.  In the past we've had some issues with make not catching some
> changes in libraries like changes the included dnet that cause strange
> issues like this.  It looks like you're working out of a directory you
> compiled from source.

> Go ahead and do a "make distclean" and then a "./configure" and then
> "make" to see if the issue is resolved.

> Brandon

> From bmenrigh () ucsd edu Sun Jan 24 11:14:32 2010
> From: Brandon Enright <bmenrigh () ucsd edu>
> To: Gunnar Lindberg <gunnar.lindberg () chalmers se>
> CC: "nmap-dev () insecure org" <nmap-dev () insecure org>, "bmenrigh () ucsd edu"
>       <bmenrigh () ucsd edu>
> Date: Sun, 24 Jan 2010 11:15:03 +0100
> Subject: Re: nmap-5.20 on x86_64 Segmentation fault
> Message-ID: <20100124101503.0f902ce1 () spoke wan>
> References: <201001221632.o0MGWA9U018170 () grunert cdg chalmers se>
> In-Reply-To: <201001221632.o0MGWA9U018170 () grunert cdg chalmers se>

> On Fri, 22 Jan 2010 17:32:10 +0100 (MET) or thereabouts Gunnar Lindberg
> <Gunnar.Lindberg () chalmers se> wrote:

> > ./nmap 129.16.x.y
> > Starting Nmap 5.20
> > Segmentation fault
> >
> > ./nmap -n 129.16.x.y
> > OK
> >
> > # uname -a
> > Linux wilfer.cdg.chalmers.se 2.6.18-164.10.1.el5 #1 SMP Wed Dec 30
> > 18:35:28 EST 2009 x86_64 x86_64 x86_64 GNU/Linux Red Hat Enterprise
> > Linux Client release 5.4 (Tikanga)
> >
> > gdb backtrace
> > #0  0x00000000004692dd in nmap_mass_rdns_core (targets=0x1742ac00,
> >     num_targets=1) at nmap_dns.cc:1160
> > #1  0x0000000000469e06 in nmap_mass_rdns (targets=0x1742acc0,
> > num_targets=1) at nmap_dns.cc:1315
> > #2  0x00000000004232d6 in nexthost (hs=0x1742a820, exclude_group=0x0,
> >     ports=0x7fffb07dfa70, pingtype=122) at targets.cc:582
> > #3  0x000000000041ec29 in nmap_main (argc=2, argv=0x7fffb07e2e38)
> >     at nmap.cc:1720
> > #4  0x000000000041a799 in main (argc=2, argv=0x7fffb07e2e38) at
> > main.cc:205 I added some printf()
> >
> > nmap-5.20/nmap_dns.cc:
> > static void nmap_mass_rdns_core(Target **targets, int num_targets) {
> > ...
> > fprintf(stderr, "1a *targets=<%X>\n",*targets);
> >   init_servs();
> > fprintf(stderr, "1b *targets=<%X>\n",*targets);
> > ...
> >
> > Result:
> > 1a *targets=<135A5CD0>
> > 1b *targets=<0>
> >
> > My 0.01 SEK is that something goes wrong when trying to make use of
> >     struct sockaddr_storage *
> > in get_dns_servers() and that that later on leads to corrupt data.
> >
> >      Gunnar Lindberg, Chalmers University of Technology


> Hi Gunnar,

> I have not been able to reproduce this issue.  I have tried having Nmap
> lookup a few hundred thousand random IPs.  I then switched to looking
> up all the names in your 129.16.0.0/16 but that worked several times
> using several different nameservers too.

> I even ran in valgrind to check for memory and other issues:

> $ sudo valgrind -v --gen-suppressions=all --db-attach=yes ./nmap --noninteractive -sL -v -d --dns-servers 
> ns1.chalmers.se 129.16.0.0/16

> Are you able to reproduce the error?  If so, what is in
> your /etc/resolve.conf?

> If you can, run Nmap in valgrind to see if that reports anything
> interesting.

> Regards,

> Brandon

_______________________________________________
Sent through the nmap-dev mailing list
http://cgi.insecure.org/mailman/listinfo/nmap-dev
Archived at http://seclists.org/nmap-dev/