RE: nmap issue

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

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


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