Nmap Development

Re: [nmap-svn] r16159 - nmap/nselib

Fri, 20 Nov 2009 17:06:58 GMT

Posted by Ron on Nov 20

Sorry, I committed some extra code in this one that I didn't mean to
(should have 'svn diff'ed.. oops).

The code is simply functions that aren't called from anywhere (yet), so,
unless somebody minds, I'm just going to leave it.

commit-mailer () insecure org wrote:

Pushed in my changes

Fri, 20 Nov 2009 16:17:32 GMT

Posted by Ron on Nov 20

Nobody had any issues with smb-enum-groups or my updated output, so I
committed the changes into the main trunk. This'll be the last of my
changes for a little while, since I'm sort of out of ideas. I didn't
want to leave stuff sitting my branch, though.

I added smb-enum-groups.nse to the CHANGELOG, but not the updated output
(I didn't want to mess with it too much while Fyodor was updating it).

As for the updated output, I went with...

Re: Removing email addresses from NSE script author field

Fri, 20 Nov 2009 13:42:38 GMT

Posted by Ron on Nov 20

Fyodor wrote:

Someone should stop that guy!

Ultimately, I don't care. Whenever I put my email address somewhere, I'm
always aware of the spam risk, so I wasn't too worried. But it's
probably a good idea to get rid of it.

Ron

Re: Removing email addresses from NSE script author field

Fri, 20 Nov 2009 04:14:13 GMT

Posted by DePriest, Jason R. on Nov 19

I never thought about them being used to fuel SPAM.

Keeping the names and removing the email addresses should be okay
since anyone who is actively maintaining a script will likely be
reading the nmap-dev list.

Perhaps put information about subscribing to or contacting nmap-dev
instead of individual email addresses?

-Jason

Removing email addresses from NSE script author field

Fri, 20 Nov 2009 04:08:53 GMT

Posted by Fyodor on Nov 19

Hi folks. I've noticed NSE author fields in several formats,
including:

p2p-conficker.nse: author = "Ron Bowes (with research from Symantec Security Response)"

http-enum.nse: author = "Ron Bowes <ron () skullsecurity net>, Andrew Orr
<andrew () andreworr ca>, Rob Nicholls
<robert () everythingeverything co uk>"

smb-enum-sessions.nse: author = "Ron...

Nmap's memory use

Fri, 20 Nov 2009 01:05:12 GMT

Posted by David Fifield on Nov 19

Hi,

We've had some report recently about Nmap using a lot of memory.

"Port memory bloat"
http://seclists.org/nmap-dev/2009/q3/926
"nmap 5 memory usage"
http://seclists.org/nmap-dev/2009/q4/300

I started looking at ways to improve this. This note is to let you know
what I've found so far and to ask if anyone has tips on memory
profiling.

In the first link above, Pavel Kankovsky observed that it is the Port
class that is...

Re: Bug/Enhancement (ncat/nsock) - Recognize Winsock error codes

Thu, 19 Nov 2009 15:30:11 GMT

Posted by David Fifield on Nov 19

Hi Paul, thanks for your suggestion. The next release of Ncat will have
this. When Ncat has a connection error, it will print the error even
without -v, and it will interpret the Windows error codes.

The Nsock messages don't interpret the Windows codes, because as I
recall those strings can be long and contain newlines. Nsock tracing is
a low-level option; we wanted to make the information from common
connection errors visible without excessive...

Re: Scanning 255.255.255.255 from Windows

Thu, 19 Nov 2009 14:04:12 GMT

Posted by Jon Kibler on Nov 19

David Fifield wrote:

Although I cannot test right now to verify it, I seem to recall that (at least
for Linux) packets sent to 255.255.255.255/32 usually (always?) have a
destination MAC address of FF:FF:FF:FF:FF:FF. Maybe nmap should simply set the
MAC associated with 255.255.255.255/32 to FF:FF:FF:FF:FF:FF?

Jon

Bug/Enhancement (ncat/nsock) - Recognize Winsock error codes

Thu, 19 Nov 2009 11:33:28 GMT

Posted by Paul Milliken on Nov 19

Hi,

I've noticed that ncat doesn't interpret Windows Socket errors,
instead displaying them as "Unknown error". Contrast the following
outputs from Windows and Linux respectively:

C:\tools\nmap-5.00>ncat -v -v -v 10.10.130.140 8888
Ncat version 5.00 ( http://nmap.org/ncat )
NSOCK (0.0620s) TCP connection requested to 10.10.130.140:8888 (IOD #1) EID 8
NSOCK (1.0160s) Callback: CONNECT ERROR [Unknown error (10061)] for
EID 8...

Re: port order in 5.00-2

Thu, 19 Nov 2009 06:59:46 GMT

Posted by bensonk on Nov 18

You can also use netcat (not ncat, sadly) with the -z flag, which says
"do no IO, just connect". This might do what you want in a pretty small
package.

This raises the question -- why doesn't ncat support netcat's -z? Was
it decided that this sort of action should be taken by nmap or nping?

Benson

Re: Scanning 255.255.255.255 from Windows

Thu, 19 Nov 2009 05:00:43 GMT

Posted by David Fifield on Nov 18

I looked into this and I can reproduce it. I get the "Failed to
determine dst MAC address" message even without -e, though. I think I
know why: for some reason the routing table has the gateway for
255.255.255.255/32 set to the local IP address. This machine's IP
address is 192.168.0.190 and its Internet gateway is 192.168.0.1.

$ nmap --iflist

Starting Nmap 5.05BETA1 ( http://nmap.org ) at 2009-11-18 21:44 Mountain Standard Time...

Re: Segfault in latest SVN

Thu, 19 Nov 2009 03:47:53 GMT

Posted by David Fifield on Nov 18

Thanks, Ron. I think this was caused by my r16121, which changed how NSE
sockets are created. I've reverted it until I can investigate.

David Fifield

Segfault in latest SVN

Thu, 19 Nov 2009 01:21:36 GMT

Posted by Ron on Nov 18

I'm not sure when this was introduced, and I'm currently on the clock
and can't troubleshoot, but here's the output:

ron () carrot:~/tools/nmap$ gdb ./nmap
GNU gdb 6.8
Copyright (C) 2008 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later
<http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show...

Re: ncat: using UDP with --chat

Wed, 18 Nov 2009 21:40:05 GMT

Posted by clemens fischer on Nov 18

(Sorry for being late again, I am busy with something else.)

Sounds reasonable. But. Can brokering be made to work over unix local
sockets in reliable datagram mode, like TCP? What I mean is mentioned
in unix(7): "unix_socket = socket(AF_UNIX, type, 0);" where type would
preferably be SOCK_STREAM or even SOCK_SEQPACKET (portability?) and
allow nice tricks with passing SO_PASSCRED! I had experimented with
"socat" much...

Re: Deletion of obsolete script files before installation

Wed, 18 Nov 2009 20:54:10 GMT

Posted by Tom Sellers on Nov 18

Should we implement a subdirectory for custom scripts to reduce the
likelihood of running into this problem in the future?

Tom