Re: Npcap 0.01 call for test (2nd)

[Graham Bloice <graham.bloice () trihedral com>]

On 22 July 2015 at 22:13, 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.
DuplicateHandle() works for file handles.


> > 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?
There's no built-in ssh server in Win 10 yet, see
http://blogs.msdn.com/b/powershell/archive/2015/06/03/looking-forward-microsoft-support-for-secure-shell-ssh.aspx

I'll have to check what happens if I remote in using PowerShell.  Normally
at work I do that with Domain Admin creds so I don't get UAC requests.  I
suspect it won't work, and is the part of the reason for the PowerShell
Invoke-Command (https://technet.microsoft.com/en-us/library/hh849719.aspx)
that allows the user to supply credentials for the command(s) to be invoked.


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

On Windows all pipes are named, even if the name is somewhat obscure.  From
the CreatePipe function reference (
https://msdn.microsoft.com/en-us/library/windows/desktop/aa365152(v=vs.85).aspx
)

Anonymous pipes are implemented using a named pipe with a unique name.
Therefore, you can often pass a handle to an anonymous pipe to a function
that requires a handle to a named pipe.

I hadn't actually checked the code, only used ProcessExplorer to check for
the pipe between Wireshark and dumpcap which shows the "named" pipe.


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

It sounds as though the work done in NPCap (see the follow-up email from
Yang),  is going down that path.

-- 
Graham Bloice

___________________________________________________________________________
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