Re: Limit WinPcap use by unprivileged users

["Gianluca Varenni" <gianluca.varenni () gmail com>]

--------------------------------------------------
From: "Patrik Karlsson" <patrik () cqure net>
Sent: Saturday, September 25, 2010 2:17 AM
To: "David Fifield" <david () bamsoftware com>
Cc: <nmap-dev () insecure org>; "DePriest, Jason R." <jrdepriest () gmail com>
Subject: Re: Limit WinPcap use by unprivileged users

> On 25 sep 2010, at 03.30, David Fifield wrote:
>
> > On Fri, Sep 24, 2010 at 08:23:46PM -0500, DePriest, Jason R. wrote:
> > > Wouldn't stopping npf would also prevent regular users from using
> > > anything else that uses winpcap like Wireshark / tshark / windump.
> >
> > Yes but that's the point of the TODO: to see if it's possible to limit
> > sniffing to certain users as is possible on other operating systems. I
> > don't think that stopping NPF is a good solution but it's the best I've
> > been able to think of.
>
> Taken from the Wireshark FAQ [1]
>
> "
> Q-7: Do I need to be Administrator in order to execute programs based on 
> WinPcap on Windows NT/2000/XP?
>
> A: Yes/no. The security model of WinPcap is quite poor, and we plan to 
> work on it in the future. At the moment, if you execute a WinPcap-based 
> application for the first time since the last reboot, you must be 
> administrator. At the first execution, the driver will be dynamically 
> installed in the system, and from that moment every user will be able to 
> use WinPcap to sniff the packets.
> "
>
> If I stop NPF and then run Wireshark it's started again, but Wireshark 
> does not stop it when I exit the application.
> This is expected behavior to me at least and I wouldn't want Wireshark or 
> Nmap to stop NPF upon completion.
> The foremost reason being that there could be other "legitimate" process 
> running that make use of it.
> I don't know if this would actually be a problem or not as attempting to 
> stop NPF during the time Wireshark is running gives me:
> "The NetGroup Packet Filter Driver service could not be stopped."
>
> Anyway, even if Nmap would attempt to stop NPF when it quits, any user 
> would be able to run a sniffer during the entire time of the scan.
> In my opinion this problem needs to be addressed in WinPcap rather than in 
> Nmap.

Definitely true. It's a design flaw in WinPcap, and the issue has been on 
the WinPcap todo list for a long time (years). Technically, it all boils 
down to applying the proper DACLs to the device objects 
(\\device\NPF_{GUID}) when they are created by the driver, so that only the 
admin users are allowed to read/write from such devices, and provide some 
sort of tool to add/remove users/groups allowed to access the devices (in 
practice work like the /dev/bpf devices under BSD and probably something 
similar to Linux). The main issue from my point of view is backward 
compatibility. There is a huge number of applications (and users) that rely 
on the fact that you don't need administrative privileges to run a 
WinPcap-based application. Modify the current (and surely unsecure) behavior 
of WinPcap, and I will have a lot of angry users. A possibility could be to 
have a registry key that enables/disables the "restrictions" on WinPcap 
devices, registry key that can only be modified by an admin and is 
configured at WinPcap installation time (by default restrictions would be 
on, can switch it off with a checkbox in the installer). I'm not sure if the 
WinPcap users would even read that additional checkbox in the installer and 
would just send an angry email to winpcap-bugs () winpcap org complaining that 
WinPcap does not work...

Have a nice day
GV


> > David Fifield
> > _______________________________________________
> > Sent through the nmap-dev mailing list
> > http://cgi.insecure.org/mailman/listinfo/nmap-dev
> > Archived at http://seclists.org/nmap-dev/
>
>
> //Patrik
>
> [1] http://www.winpcap.org/misc/faq.htm
> --
> Patrik Karlsson
> http://www.cqure.net
> http://www.twitter.com/nevdull77
>
>
>
>
>
> _______________________________________________
> 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/