Home page logo
/

nmap-dev logo Nmap Development mailing list archives

Re: nmap issue
From: bensonk () acm wwu edu
Date: Sat, 17 May 2008 22:07:50 -0700

Thanks for the thorough explanation.  :-)  I agree with your analysis.
I think loading the winpcap driver by default but with a checkbox to
disable it will make the user experience best, and the winpcap driver
shouldn't be *that* much overhead, so it's not a huge deal.  

Benson

On Sun, May 18, 2008 at 01:38:22AM +0100, Rob Nicholls wrote:
Hi Benson,

Sorry if I didn't make it a bit clearer amidst all the background info. My
suggestion was basically that we add a question to the Nmap Windows
Installer, similar to how it's presented in the Wireshark installer (checked
by default on Vista, but not checked on older versions of Windows?) that
gives the user a choice and hopefully raises awareness of the issue we're
all discussing. I think Gianluca's email was a lot more concise :) although
he presented us with different options rather than suggesting an opinion or
going over the pros and cons of each method.

The issue is that certain users are struggling to get Zenmap/Nmap to work on
Vista (because Administrators on a default installation of Vista - i.e. with
UAC enabled - launch processes as a "standard user", unless the user
specifically runs it elevated) and this is not really an Nmap problem, or a
WinPcap problem; it's partly/mostly user education. Unfortunately the dnet
error message that people get is quite cryptic (and can appear for a variety
of reasons), so even if users are slightly technical (and not all of them
are) they'll probably fail to get Zenmap/Nmap to work. It shouldn't be naive
or foolish of them to expect a default install of Nmap to work on a default
install of Vista.

I was hoping we could try and be a bit more proactive and try to improve the
end-user experience by making some minor changes to the installer (so the
default installs simply work). Even if we change the registry key, users
will still initially have problems unless they use an elevated command
prompt/elevated Zenmap or reboot the computer, as nothing has loaded the
driver yet, which is why I'm open to ideas, such as getting the Nmap Windows
installer (that is already elevated) to run "net start npf" once it's
finished (or perhaps something more elegant, such as a question at the end
asking if the user wants to load the WinPcap driver?).

Unless people are in the habit of rebooting computers or running "net stop
npf" to stop the NetGroup Packet Filter Driver service, it won't actually
make that much of a difference if the WinPcap driver runs at startup instead
of using the default setting (SERVICE_DEMAND_START). It does technically
increases the risk of a vulnerability in WinPcap being exploited, as the
driver runs immediately instead of on demand; however, it (typically, unless
users manually stop it using an elevated command prompt to run "net stop
npf" as it's not present in services.msc) remains resident, and WinPcap has
a decent track record.

Because Nmap is a command line program that takes in a bunch of arguments,
executes them, then exits, embedding a manifest in the Nmap executable to
ask for privilege elevation just so Nmap can load WinPcap if necessary could
be very annoying for certain users, which is why I don't think we should do
it (Fyodor's first suggestion) for nmap.exe. 

This would be especially annoying if Administrators had set computers up so
WinPcap loads at startup so scans could be performed by "standard users"
(and non-Admin users on older versions of Windows) without the standard
users having to supply Administrator credentials (which they might not even
have/be allowed!).

Sticking with Fyodor's first suggestion, I think Zenmap could contain an
embedded manifest, as it stays open between scans and I presume (although I
don't know as I normally use the WinPcap registry key trick) it invokes
multiple instances of Nmap using the elevated credentials, so the user only
gets to see the elevation prompt once every time they launch Zenmap (which
might still be once more than necessary if the user has already done the
registry key trick, or the driver has already been loaded by an elevated
Wireshark or previously run elevated Zenmap/Nmap etc.).

I like Fyodor's other suggestion of checking if the Windows user has proper
admin privileges; however, as mentioned above, you don't need to be running
as admin if you've already loaded the WinPcap driver. At least I haven't
spotted any problems or limitations running Nmap as a standard user/with UAC
enabled.

And just for completeness, the other options I can think of to try and avoid
this issue would be:
 - disable UAC (not a good thing, and doesn't allow standard users to run
Nmap) 
 - embed a manifest and change group policy settings to elevate without
prompting (also not a good thing, and doesn't allow standard users to run
Nmap).

I do agree that in general it's not a good idea to make unnecessary things
load at startup on Windows as it can slow down the system and use up system
resources, but I don't think I've ever considered WinPcap to be a major
performance problem. Which is why I think the least painful way of avoiding
this issue would be to present Vista users with a checkbox (like in
Wireshark's installer) that's checked by default to run WinPcap at startup,
and knowledgeable users that want to use WinPcap's default setting or want
to reduce the number of things that run at startup have the option of
unchecking that box. It'd also allow standard users to run Nmap/Zenmap.

Apologies for the lengthy email!

Rob


-----Original Message-----
From: nmap-dev-bounces () insecure org [mailto:nmap-dev-
bounces () insecure org] On Behalf Of bensonk () acm wwu edu
Sent: 17 May 2008 18:20
To: Rob Nicholls
Subject: Re: nmap issue

I really don't like the idea of having nmap start something that runs
as
a service by default.  It's that kind of thing that makes windows
machines all slow and obnoxious after you've installed a few dozen
things.  Maybe that's not what you're proposing, but if it is, I
disagree.  If it isn't, I apologize for misinterpreting what you said.

Benson

On Sat, May 17, 2008 at 03:32:46PM +0100, Rob Nicholls wrote:
-----Original Message-----
From: Gianluca Varenni [mailto:gianluca.varenni () gmail com]
Sent: 17 May 2008 00:16
To: Brandon Enright; Mike pattrick
Cc: nmap-dev () insecure org; bmenrigh () ucsd edu
Subject: Re: nmap issue
<snip>
if you set the driver npf.sys to start at boot time,
you solve the issue, as the driver is already up and running when
nmap needs even with non fully elevated privileges (and I think
this is what Wireshark does upon installation on Vista).

I've suggested this before when people have come across this issue,
as it's
what I generally do when I've installed Nmap on Vista (as I like to
keep UAC
enabled):

http://seclists.org/nmap-dev/2007/q4/0548.html

As Gianluca points out, this means you can run Nmap as a standard
user
rather than restricting access to Administrators (or UAC nagging
every time
Nmap is invoked), which I think is a lot nicer/cleaner.

I've previously suggested using the installer (which runs elevated)
to set
the registry key to start WinPcap at bootup and then somehow
(ideas??) load
the driver so that it's already up and running (to save the user from
having
to restart their PC or run Nmap/Zenmap elevated in order to load the
driver
immediately after installation):

http://seclists.org/nmap-dev/2007/q4/0553.html

I believe Wireshark uses the official WinPcap installer, but allows
the user
to check a box to change the default registry key (presumably set
once
WinPcap has installed itself with the default key value):


http://www.everythingeverything.co.uk/files/winpcap_services_checkbox.p
ng

I quite like this option, perhaps this question could be added to the
Nmap
Windows installer? I would hope that people using the zip file
version of
Nmap either already have WinPcap installed or are sufficiently
technical to
know about UAC/elevation/the registry setting.


Rob



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


Attachment: _bin
Description:


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

  By Date           By Thread  

Current thread:
[ Nmap | Sec Tools | Mailing Lists | Site News | About/Contact | Advertising | Privacy ]