On 22 July 2015 at 22:13, Guy Harris <g...@alum.mit.edu> wrote: > > On Jul 22, 2015, at 1:49 PM, Graham Bloice <graham.blo...@trihedral.com> > wrote: > > > > > > > On 22 July 2015 at 18:37, Guy Harris <g...@alum.mit.edu> wrote: > > > >> On Jul 22, 2015, at 9:37 AM, Graham Bloice <graham.blo...@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-requ...@wireshark.org?subject=unsubscribe
