RE: Suggestion for Docs

["Rob Nicholls" <robert () robnicholls co uk>]

I'm surprised Fyodor was able to run Nmap/Zenmap correctly with the startup
option unchecked, but I think I've identified a few bugs in the WinPcap
installer :-S (I've only done a quick code review, I've not run the
installer):

Bug #1: It looks like a silent install runs the autoStartWinPcap section,
which sets the registry key to 2 (automatic) and starts the service, when I
think it was agreed that a silent install should not be started/start at
boot.

Bug #2: If the GUI installer is used and the user unchecks the box to start
WinPcap at startup it will skip the next option and won't start npf as
potentially requested.

Bug #3: We only set the registry key to 2, we never set it to 1. This
*might* mean that the key is never changed from 2 if the user has previously
installed WinPcap, despite unchecking the box in our installer during later
installations.

Nmap (or Zenmap, or Wireshark) only needs to be run once as an Administrator
after Windows has started in order for it to start WinPcap (assuming WinPcap
hasn't already been started by something else). It wouldn't be best practice
to regularly run such tools as an Administrator as it doesn't really need
that level of access, and in the unlikely event that there was some kind of
remote code execution vulnerability in Nmap, it might run as Admin rather
than a low privileged user.

As long as WinPcap has been started - such as when the system starts, as
this doesn't require the user to do any special/extra steps - you can always
run Nmap (and Zenmap, and Wireshark) as a standard user. This is why the
WinPcap installer recommends that Vista and Windows 7 users allow WinPcap to
start automatically by default.

If the user decides to uncheck the box during WinPcap's installation then we
must assume that they know what they're doing when they go against the
recommendations. It is possible that the user sees WinPcap as "yet another
unnecessary program that wants to run something at startup" and unchecks it
for the wrong reasons, in which case a better error message from Nmap might
help.

The recommendation to fix the issue, however, might be more complicated as
there are several ways of doing it: run Nmap/Zenmap at least once using Run
as Administrator, or modify a registry key and reboot, or run the command
"net start npf" using an elevated Command Prompt. I wouldn't like to
recommend that people always run Nmap/Zenmap as Administrator.

I quite like the idea of some kind of warning from Nmap if Windows users try
to run Nmap and WinPcap is present on the system but the npf service hasn't
been started. That would have saved some confusion when we discovered this
issue 3+ years ago when Vista introduced UAC. I suspect, as some people will
have skipped Vista for a variety of reasons, some people will experience
this issue in Windows 7 for the first time.

For more information on possible registry key settings for WinPcap, see
their FAQ:
http://www.winpcap.org/misc/faq.htm#Q-18

The reason that silent installs shouldn't start Nmap at system startup is
because this is what was requested around 3 years ago when we made changes
to improve the Nmap user experience with Vista (perhaps it's worth taking
another poll and/or seeing if Nmap/WinPcap can accept an additional
argument). System administrators rolling Nmap out as a silent install can
use group policy (or whatever tools they're using to install Nmap) to
subsequently change the registry key if required, and many administrators
probably don't want standard users being able to use Nmap (it may be
installed for Admin users only, who plan on stopping the npf service after a
scan has finished). Seeing as no one has complained about bug #1, perhaps
letting WinPcap run automatically after a silent install isn't an issue (and
in some cases possibly desirable)?

I'll try and create (and test) a patch this weekend to fix the bugs I've
identified in the WinPcap installer. I'll also try and look into the 2008 R2
issue that Brian encountered, which I think could potentially be a race
condition if a version of WinPcap was already present (or it could be
something else entirely).

Rob

-----Original Message-----
From: nmap-dev-bounces () insecure org [mailto:nmap-dev-bounces () insecure org]
On Behalf Of Fyodor
Sent: 13 January 2010 21:18
To: Richards, Toby
Cc: nmap-dev () insecure org
Subject: Re: Suggestion for Docs

On Tue, Jan 05, 2010 at 11:56:53AM -0800, Richards, Toby wrote:
> I humbly suggest that the "Executing Nmap on Windows" section of your web
> site (http://nmap.org/book/inst-windows.html#inst-win-exec ) include the
> following information: If on Windows 7, you must right-click the Zenmap
> icon, and select "Run as Administrator" even if you are logged on as an
> administrator. Similarly, to run Nmap on Windows 7, you must open the
> command prompt with administrator privileges. While there are multiple
ways
> to do this, one way is to right-click the command prompt shortcut, and
> select "Run as Administrator." Even if you already are logged in as an
> administrator, failing to follow these instructions will result in an
error
> that Nmap cannot identify the Ethernet interface.

Hi Toby.  Thanks for your suggestion.  I would like to figure out what
is causing this issue, as I don't need to follow these steps on my
Windows 7 system (Home Premium X64 running under VMWare).  I tried
Nmap 5.10BETA2 with the default install options, and with the "start
NPF on system startup" option unchecked.  I tried both Zenmap and
command-line Nmap, with reboots between them to insure that Winpcap
loaded from an earlier run doesn't affect a later run.

There must be something different in our Windows 7 configurations.
Can you post the exact error message you receive when running Nmap
without taking these extra steps?  While adjusting the documentation
is important, it is even better if Nmap itself can detect the error
and tell users what to do.

Has anyone else here experienced this issue?

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


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