Re: hope to support NPcap by improving WinPcap's DLL searching logic

[Gerald Combs <gerald () wireshark org>]

On 6/10/15 7:43 AM, Alexis La Goutte wrote:
> On Wed, Jun 10, 2015 at 4:34 PM, Pascal Quantin <pascal.quantin () gmail com
> <mailto:pascal.quantin () gmail com>> wrote:
>
>     2015-06-05 19:24 GMT+02:00 Yang Luo <hsluoyb () gmail com
>     <mailto:hsluoyb () gmail com>>:
>
>         Hi list,
>
>         I'm developing NPcap, an alternative to original WinPcap but with
>         more features like NDIS 6 support and others. NPcap is supposed to
>         support Nmap, Wireshark and so on just like WinPcap did and follow
>         the same DLL interface with WinPcap. NPcap can coexist with
>         WinPcap, so we decide to install NPcap's DLLs (also wpcap.dll and
>         packet.dll) to another directory than system32 (which is used by
>         WinPcap) and let PATH environment variable point to it. However,
>         after I did some research I found that Wireshark seems to search
>         wpcap.dll only in 1) its installation folder; 2) system32. As it
>         is, NPcap's DLLs can't be found by Wireshark. I wonder if Wireshark
>         could just use LoadLibrary() to load wpcap.dll without specifying
>         its path? So that Windows DLL loader could automatically target
>         NPcap's wpcap.dll by searching PATH when WinPcap is unavailable.
>         And then the end user will have another choice besides WinPcap when
>         using Wireshark. Thanks!
>
>         NPcap is currently hosted at github as belows for your information:
>         https://github.com/nmap/npcap
>
>
>     Hi Yang,
>
>     thanks for resurrecting WinPcap development and for the efforts you
>     have already put during your previous GSoC for porting the code from
>     NDIS5 to NDIS6.
>     The switch from LoadLibrary() to ws_load_library() helper was done on
>     purpose by Gerald in 2010:
>     https://code.wireshark.org/review/gitweb?p=wireshark.git;a=commit;h=607b228df6f1f754bf9bda6cfa21563913b1e7ff
>     I was not much involved in Wireshark development by that time (only
>     contributing to a few dissectors) so I do not know what was the intent
>     of this change, or the issue it was solving.
>     Gerald, do you remember why you purposely restricted the dll search
>     path to Wireshark installation and system directory?
>
> Hi Pascal,
> To fast ! (i have start to write my e-mail...)
>
> It is for security stuff, for avoid "DLL Hijacking" (
> https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=5133 )

That's correct. In general I would prefer to be cautious when loading
shared code. As far as Yang's issue goes, there are a few ways to fix the
problem:

Make NPcap official. Integrate NPcap into the official WinPcap source code.
This presumes that we can create properly signed drivers and installers at
some point.

Make NPcap mutually exclusive. At installation time, if WinPcap is
installed, uninstall it and install the NPcap DLLs in the system directory.

Make NPcap obviously separate. Give it a separate name and modify Wireshark
to try to load it first.

I'm concerned that having different things named "wpcap.dll" will cause
problems, or at least confusion. This was recently an issue with the Qt DLLs:

https://www.wireshark.org/lists/wireshark-commits/201501/msg00797.html
___________________________________________________________________________
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