Re: Npcap 0.01 call for test (2nd)

[Yang Luo <hsluoyb () gmail com>]

Hi Guy,

If I am understanding right, what you asked is exactly what Npcap has
implemented for "Admin-only Mode". If you install Npcap in "Admin-only
Mode", the driver npf.sys will be protected with Admin rights. Softwares
(like Wireshark) loading Npcap's packet.dll will start a daemon named
"NPcapHelper.exe" in Admin privilege (here a UAC prompt shows for user to
decide). NPcapHelper.exe communicate with Wireshark using Named Pipes and
will open adapter devices (\Device\NPF_{XXX}) for Wireshark. Opened handles
will be copied using DuplicateHandle and sent back to Wireshark using Named
Pipes.

Currently this mechanism is all transparent to user softwares, and I have
tested on Nmap and Wireshark. One issue about this "Admin-only Mode" to
Wireshark is, when opening Wireshark UI, UAC window will be prompted
multiple times. As "NPcapHelper.exe" daemon only terminates itself when
packet.dll is unloaded, I guess this is because Wireshark has loaded and
unloaded packet.dll multiple times. I haven't looked into this issue, as
there's not many people using this feature in Wireshark yet.

Also I think service start code (like net start npf) should be done in the
DLL level, because this code needs Admin right, so it can be taken care by
"NPcapHelper.exe" daemon too. If Wireshark is started with no Admin right
and needs to start the service, this invocation will simply fail. However,
there is not such an startDriverService() API in original WinPcap. So it is
kind of hard for Npcap to provide it without patching all user softwares.

Some codes can be found here:

Daemon (providing handles)
https://github.com/nmap/npcap/tree/master/packetWin7/Helper

Packet.dll (requesting handles)
https://github.com/nmap/npcap/tree/master/packetWin7/Dll


Cheers,
Yang


On Thu, Jul 23, 2015 at 5:13 AM, Guy Harris <guy () alum mit edu> wrote:

> On Jul 22, 2015, at 1:49 PM, Graham Bloice <graham.bloice () trihedral com>
> wrote:
>
> > On 22 July 2015 at 18:37, Guy Harris <guy () alum mit edu> wrote:
> >
> > > On Jul 22, 2015, at 9:37 AM, Graham Bloice <graham.bloice () trihedral com>
> wrote:
> > > > Most, if not all, will be running Wireshark unelevated, as this is a
> basic tenet of Wireshark use. There are millions of lines of code in
> Wireshark dissectors and they really shouldn't be given admin privs.
> > > Does anybody know whether there exists, in Windows:
> > >
> > >         1) an inter-process communications mechanism, either documented
> or reverse-engineered *and* likely to remain intact and usable from release
> to release and in future releases, over which a HANDLE can be passed;
> > DuplicateHandle -
> https://msdn.microsoft.com/en-us/library/windows/desktop/ms724251(v=vs.85).aspx
>
> OK, so that's more than just UN*X dup()/dup2(), as it takes process
> handles and can affect another process's handles.
>
> It says
>
>         If the process that calls DuplicateHandle is not also the target
> process, the source process must use interprocess communication to pass the
> value of the duplicate handle to the target process.
>
> which is the other part of this.
>
> > A HANDLE to what though, the handle types that can be duplicated with
> that call are limited?
> > If it's a socket HANDLE, then WSADuplicateSocket (
> https://msdn.microsoft.com/en-us/library/windows/desktop/ms741565(v=vs.85).aspx)
> is used.  This creates a structure that can be handed off to the target
> process by some IPC mechanism.
>
> Nope, it's a handle to something opened with CreateFile(), although the
> path is a \\.\xxx symbolic link (in the Windows NT sense) to a device, the
> device in question being the one provided by the WinPcap driver.  See
> PacketOpenAdapterNPF() in packetNtx\Dll\Packet32.c in the WinPcap source.
>
> > The IPC Mechanisms supported by Windows are listed here:
> https://msdn.microsoft.com/en-us/library/windows/desktop/aa365574(v=vs.85).aspx,
> pipes are commonly used.  I don't think there are issues with pipes between
> a non-elevated process and an elevated one, but I haven't personally tried
> that.
>
> Sounds good (on UN*X, UNIX-domain sockets include functionality that's
> sort of the equivalent of DuplicateHandle() with the source process being
> the sending process and the target process being the receiving process).
>
> > >         2) a mechanism by which a non-privileged process can request
> that a subprocess be run with elevated privileges - presumably requiring
> either user consent or something else to indicate trust - with such an IPC
> channel established between the non-privileged process and the privileged
> process?
> > A way to elevate a subprocess is via a call to ShellExecuteEx() setting
> the lpVerb in the passed in SHELLEXECUTEINFO structure to "runas".  See
> http://blogs.msdn.com/b/vistacompatteam/archive/2006/09/25/771232.aspx.
> > This will invoke UAC if enabled (a it should be).
>
> Just out of curiosity:
>
>         What happens if something you run from a command prompt in Windows
> invokes UAC - does it pop up a dialog in the GUI?
>
>         If you were to ssh into a Windows box (using third-party ssh or
> Windows 10 ssh:
>
>
> http://arstechnica.com/information-technology/2015/06/microsoft-bringing-ssh-to-windows-and-powershell/
>
>         ) are you running in a session with any access to the GUI and, if
> not, what happens with UAC?
>
> > > UN*Xes that support libpcap generally have 1) in the form of
> UNIX-domain sockets (or, in newer versions of OS X, Mach messages, over
> which those newer versions of OS X support passing file descriptors), and
> probably have 2) in the form of, if nothing else, sudo or some GUI
> equivalent.
> > > The idea here is to have libpcap - and WinPcap, if the answers to those
> questions are both "yes" - invoke a *small* helper process to do what work
> needs elevated privileges to open capture devices, turn on monitor mode,
> change channels, etc., so that programs using those libraries do not
> *themselves* require elevated privileges.
> > > If the answer for the first question is "no", then do we have some way
> to run dumpcap with elevated privileges and have a pipe between it and
> Wireshark/TShark?
> > That's what currently happens on Windows using a named pipe, without the
> elevation though.
>
> That's what currently happens on all platforms, using anonymous pipes on
> UN*X (are you certain the pipes are named on Windows?  They're created with
> CreatePipe() - see the code in capchild/capture_sync.c).  On at least some
> UN*Xes, dumpcap's privileges are elevated, but not by virtue of a "run with
> elevated privileges" call; the executable image is marked as getting
> elevated privileges (set-UID root, set-GID to the appropriate group, or
> appropriate individual capabilities).
>
> I'm trying to see whether I can, ultimately, get rid of the need to run
> dumpcap, as well as the need for as much code as there is in dumpcap ever
> running with elevated privileges.
> ___________________________________________________________________________
> Sent via:    Wireshark-dev mailing list <wireshark-dev () wireshark org>
> Archives:    https://www.wireshark.org/lists/wireshark-dev
> Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
>              mailto:wireshark-dev-request () wireshark org
> ?subject=unsubscribe
___________________________________________________________________________
Sent via:    Wireshark-dev mailing list <wireshark-dev () wireshark org>
Archives:    https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
             mailto:wireshark-dev-request () wireshark org?subject=unsubscribe