Nmap Development mailing list archives

OS X 10.6 Problems with privileged scans


From: Tom Sellers <nmap () fadedcode net>
Date: Thu, 15 Oct 2009 19:10:49 -0500

I saw this while going through the TODO file:

o Potential OS X 10.6 problems.  There are two issues reported by the
  same user which may be related:
  http://seclists.org/nmap-dev/2009/q3/0936.html,
  http://seclists.org/nmap-dev/2009/q3/0996.html.  One is that Nmap
  hangs doing nothing and needs to be killed with Ctrl-C, and the
  other is that it dies after printing "Initiating UDP Scan".  Another
  reported the same problem at
  http://seclists.org/nmap-dev/2009/q3/0990.html, where it dies after
  the first ARP request is sent.  But Brandon has run Nmap on 10.6
  without problems.  It is a bit of a mystery. [David]


I have this problem on my Snow Leopard system.  Normal users can run
certain scans, but root cannot.  Even simple scans are affected..

sudo nmap -sP -d9 scanme.nmap.org   chokes here until I kill it:

**********************************************************************
Starting Nmap 5.05BETA1 ( http://nmap.org ) at 2009-10-15 19:04 CDT
The max # of sockets we are using is: 0
--------------- Timing report ---------------
  hostgroups: min 1, max 100000
  rtt-timeouts: init 1000, min 100, max 10000
  max-scan-delay: TCP 1000, UDP 1000, SCTP 1000
  parallelism: min 0, max 0
  max-retries: 10, host-timeout: 0
  min-rate: 0, max-rate: 0
---------------------------------------------
Initiating Ping Scan at 19:04
Scanning 64.13.134.52 [4 ports]
Pcap filter: dst host 192.168.200.77 and (icmp or ((tcp or udp or sctp) and (src host 64.13.134.52)))
Packet capture filter (device en1): dst host 192.168.200.77 and (icmp or ((tcp or udp or sctp) and (src host 
64.13.134.52)))
SENT (0.0040s) ICMP 192.168.200.77 > 64.13.134.52 echo request (type=8/code=0) ttl=51 id=6159 iplen=28
SENT (0.0040s) TCP 192.168.200.77:48278 > 64.13.134.52:443 S ttl=50 id=14485 iplen=44  seq=1618135438 win=3072 <mss 
1460>
SENT (0.0040s) TCP 192.168.200.77:48278 > 64.13.134.52:80 A ttl=53 id=3056 iplen=40  seq=1618135438 win=2048 
ack=3449250024
SENT (0.0040s) ICMP 192.168.200.77 > 64.13.134.52 Timestamp request (type=13/code=0) ttl=39 id=29241 iplen=40
**TIMING STATS** (0.0040s): IP, probes active/freshportsleft/retry_stack/outstanding/retranwait/onbench, 
cwnd/ssthresh/delay, timeout/srtt/rttvar/
   Groupstats (1/1 incomplete): 4/*/*/*/*/* 10.00/75/* 1000000/-1/-1
   64.13.134.52: 4/0/0/4/0/0 10.00/75/0 1000000/-1/-1
Current sending rates: 3988.04 packets / s, 151545.36 bytes / s.
Overall sending rates: 3988.04 packets / s, 151545.36 bytes / s.


**********************************************************************


This appears to be a change in behavior (BUG) introduced in Snow Leopard
and other projects are running into it as well.

Wireshark has a pretty informative open item:
        https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=3980

Basically it looks like the bpf interfaces are goofed and the only traffic
you cannot see is that which YOUR machine sent.  In my case, it is over a
wireless adapter which worked fine pre-upgrade as well as under Windows 7.

I will try digging into this some more, but I wanted to go ahead and throw
this data out there.

Tom




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


Current thread: