On 7 July 2015 at 16:56, Joerg Mayer <jma...@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? > > > 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
___________________________________________________________________________ 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
