Re: Plan to make NPcap available for Wireshark

[Yang Luo <hsluoyb () gmail com>]

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.

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.

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.


Cheers,
Yang


On Mon, Jul 6, 2015 at 3:15 AM, Graham Bloice <graham.bloice () trihedral com>
wrote:

> As WinPcap and NPcap seem to be diverging, in the short-term at least,
> should the dll's be named differently?
>
> The following is just an observation, not intended as any criticism.
>
> As NPCap has chosen to co-exist with WinPCap by using a (non-standard)
> Windows directory, although that (currently) doesn't seem to have any
> ill-effects, a similar co-existence choice would be to name the binaries
> differently and then use the standard directories.  This would also enable
> using apps to not to have to hard-code the non-standard directory in any
> LoadLibrary() call to check at runtime for either version.
>
>
> On 5 July 2015 at 18:06, Yang Luo <hsluoyb () gmail com> wrote:
>
> > Good question, Graham. This is simply because WinPcap has taken the System32\SysWow64
> > dirs and NPcap wants to coexist with WinPcap. As NPcap has the same file
> > names (wpcap.dll and packet.dll) for compatibility, we just can't put the
> > the-same-name files in the same folder with WinPcap. Though I personally
> > prefer the way to "Make NPcap and WinPcap mutually exclusive" (this needs
> > user softwares like Wireshark and Nmap nothing to change),  coexisting way
> > has also its benefits, and finally we chose the latter.
> >
> > Cheers,
> > Yang
> >
> > On Sun, Jul 5, 2015 at 1:28 AM, Graham Bloice <
> > graham.bloice () trihedral com> wrote:
> >
> > > Out of interest why does NPcap not place its DLL's in System32\SysWow64
> > > as that is on the standard DLL search path?
> > >
> > >
> > >
> > > On 4 July 2015 at 17:28, Yang Luo <hsluoyb () gmail com> wrote:
> > >
> > > > Hi Pascal, I hold the same opinion with you, because a user installing
> > > > NPcap implies that he wants to use it, I think I will make it this way:)
> > > >
> > > > Cheers,
> > > > Yang
> > > >
> > > > On Sat, Jul 4, 2015 at 6:07 PM, Pascal Quantin <
> > > > pascal.quantin () gmail com> wrote:
> > > >
> > > > > Le 4 juil. 2015 4:26 AM, "Yang Luo" <hsluoyb () gmail com> a écrit :
> > > > > > Hi list,
> > > > > >
> > > > > > Given that current Wireshark can't make use of NPcap because of the
> > > > > DLL search path problem mentioned in
> > > > > https://www.wireshark.org/lists/wireshark-dev/201506/msg00030.html,
> > > > > I'd like to make a patch for Wireshark. As it is a security consideration
> > > > > that Wireshark don't want to search the DLLs in the Windows way. My plan is
> > > > > to explicitly add the NPcap path to Wireshark's DLL search logic. NPcap
> > > > > uses the "C:\Windows\System32\NPcap" and "C:\Windows\SysWow64\NPcap" to
> > > > > store its DLLs (WinPcap uses "C:\Windows\System32" and
> > > > > "C:\Windows\SysWow64" directly). As it is a sub directory of System32
> > > > > folder. Its access control policy is the same with System32, and there
> > > > > should be no security problem I think. The second question is if WinPcap
> > > > > and NPcap are both available in a system, which will be loaded first? I'd
> > > > > like to hear your opinions:)
> > > > > > Cheers,
> > > > > > Yang
> > > > >
> > > > > Hi Yang,
> > > > >
> > > > > As WinPcap is older and could be installed for other programs, on my
> > > > > side I would consider NPcap has having higher precedence and be loaded
> > > > > first.
> > > > >
> > > > > Best regards,
> > > > > Pascal.
> > > > >
> > > > >
> > > > > ___________________________________________________________________________
> > > > > 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
> > >
> > >
> > >
> > > --
> > > Graham Bloice
> > > Software Developer
> > > Trihedral UK Limited
> > >
> > >
> > > ___________________________________________________________________________
> > > 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
>
>
>
> --
> Graham Bloice
> Software Developer
> Trihedral UK Limited
>
> ___________________________________________________________________________
> 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