Re: OS X 10.6 Problems with privileged scans

[David Fifield <david () bamsoftware com>]

On Thu, Oct 15, 2009 at 07:10:49PM -0500, Tom Sellers wrote:
> 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.

Every online source I've found also seems to indicate that this is an
Apple bug rleated to the permissions of the bpf devices. The libpcap
README.macosx says:

http://github.com/mcr/libpcap/commit/bb8cce59686f4ebba5aeee3073fb9322ec9ef6f9#L0R70
"(NOTE: due to a bug in Snow Leopard, if you change the permissions not
to grant write permission to everybody who should be allowed to capture
traffic, non-root users who cannot open the BPF devices for writing will
not be able to capture outgoing packets.)"

The Wireshark bug report above says
"The workaround is to give the users in question write permission as
well - for example, if "ls -l /dev/bpf*' reports something such as
crw-r-----  1 root  admin   23,   0 Sep  3 18:45 /dev/bpf0
do "sudo chmod g+w /dev/bpf*" so that the admin group gets write
permission as well."

The Wireshark bug report also says that this bug is known by Apple under
the numbers 6944871 and 7210378.

What is the output of "ls -l /dev/bpf*"? Does the problem go away after
changing the permissions with "sudo chmod u+w /dev/bpf*"?

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