Wireshark-dev: Re: [Wireshark-dev] Npcap 0.01 call for test (2nd)
From: Graham Bloice <[email protected]>
Date: Wed, 22 Jul 2015 22:05:33 +0100


On 22 July 2015 at 21:49, Graham Bloice <[email protected]> wrote:


On 22 July 2015 at 18:37, Guy Harris <[email protected]> wrote:

On Jul 22, 2015, at 9:37 AM, Graham Bloice <[email protected]> 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;



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.

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.


        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).

 

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.



An interesting article on process elevation and IPC using named pipes between process with different security levels: http://www.codeproject.com/Articles/19165/Vista-UAC-The-Definitive-Guide

--
Graham Bloice