[Graham Bloice <graham.bloice@xxxxxxxxxxxxx>]

On 7 July 2015 at 16:56, Joerg Mayer <jmayer@xxxxxxxxx> wrote:

On Mon, Jul 06, 2015 at 10:42:50AM +0800, Yang Luo wrote:
> The first reason is causing more efforts for apps. Nearly all apps I know
> have hard-coded the DLL file name, wpcap.dll by implicitly linking the .lib
> or LoadLibrary call. If I changed this name, all apps will need
> modification for NPcap. LoadLibrary is easy to change, just add another
> file name for its argument, but changing the implicit linking to NPcap will
> be much more pain, needs changing the SDK, changing the SDK means to give
> up WinPcap, and even NPcap don't have a SDK yet, he has to compile with
> NPcap from source. I don't see any softwares except Wireshark and nmap
> would like to do this for NPcap. Because as you said, WinPcap can still
> work under Win10, there's no indispensable reason for other apps to do that
> much for NPcap.

While I understand the logic behind our argument, I don't agree with it:
With the possibility of winpcap and npcap diverging, that may at one point
in time mean diverging and incompatible APIs. Also, what happens if a user
wants to use Wireshark with winpcap and also wants to use npcap? Does your
proposal have a solution to this?

> Second reason is that from what I see, most apps use the Windows DLL search
> order, while I didn't test much, but at least nmap and WinDump does. Only
> Wireshark has hard-coded DLL folder for now. Perhaps system32 is a
> "standard" way we know to put DLLs, however using another DLL path and
> adding it to Environment Variable %PATH% is also a "standard" way, it's not
> less secure than system32 way because a user needs Administrator right to
> modify machine-wide options in Environment Variable. You may think that a
> malicious user can mess with his own user-wide options, adding some
> malicious path to his own %PATH%, but in that condition Wireshark will
> probably also run under that user (Non-administrator right). So still no
> harm to the Administrator-protected resources. Of course, if the malicious
> user is an Administrator, he can do whatever he wants, including modifying
> Environment Variable and messing with system32.

I never understood the nature of the security vulnerability in detail, but
hopefully someone who understands it can comment on that argument - my gut
feeling is that you are missing something, otherwise Gerald wouldn't have
made the effort to fix this the way he did.

The security vulnerability is DLL hijacking. See http://resources.infosecinstitute.com/dll-hijacking/ for one explanation.  Basically apps should ensure they are loading DLL's from absolute "known" paths, i.e. the app directory (or below) and the system paths.

> BTW, I found that apps all like to hard-coded some names in WinPcap. Nmap
> and Wireshark hard-coded the "npf.sys" driver name, Wireshark even
> hard-coded the adapter binding name (like "\Device\NPF_{XXXX}", but we have
> changed it to "\Device\NPCAP_{XXXX}"). I have changed this adapter binding
> name back to "NPF" for compatibility, but the driver name NPcap uses is
> "npcap.sys" and cannot be changed back to "npf.sys", because driver names
> are system-global. So I think the logic checking "npf.sys" in Wireshark
> also needs some change.

IMO using NPCAP or winpcap should be a compile time option with the possiblity
to enable both options at the same time (in which case there should be an option
to select preference). So I really think that npcap should start using different
binary names and use standard directories instead of the non-standard solution
you are using right now.

The Wireshark suite doesn't hard-code npf.sys per se, it just uses the Service Control Manager (SCM) to check the state of the "npf" service.  To allow co-existence of both WinPCap and NPcap on the same machine that service name should be different for the two libraries.

Arguably that check is a user convenience type of thing, because users have, in the past, stopped the service and been unable to capture.

--

Graham Bloice