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.
> 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.
Ciao
Joerg
--
Joerg Mayer <jma...@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-requ...@wireshark.org?subject=unsubscribe
