Re: Plan to make NPcap available for Wireshark

[Yang Luo <hsluoyb () gmail com>]

On Tue, Jul 7, 2015 at 11:56 PM, Joerg Mayer <jmayer () loplof de> 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?
>
> Actually there's not much diverging between WinPcap and Npcap in API
level. They share the same DLLs and their exported functions. The only
problem is the path. Using which is decided by which DLLs Wireshark is
trying to load. Wireshark can determine its DLL loading order itself, or
provide a way to let the user decide.


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

My solution is a "enable both" solution, you decide which to use by DLL
path. I don't see why we need a compile option, cause a user won't compile
the source code, right? I think I'm talking about the trunk, AKA the
official Wireshark release.


> Ciao
>    Joerg
>
> --
> Joerg Mayer                                           <jmayer () loplof de>
> We are stuck with technology when what we really want is just stuff that
> works. Some say that should read Microsoft instead of technology.
> ___________________________________________________________________________
> 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