[Wireshark-dev] Plan to make NPcap available for Wireshark
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 ___ Sent via:Wireshark-dev mailing list Archives:https://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] Plan to make NPcap available for Wireshark
Le 4 juil. 2015 4:26 AM, "Yang Luo" 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 Archives:https://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] Plan to make NPcap available for Wireshark
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 wrote: > > Le 4 juil. 2015 4:26 AM, "Yang Luo" 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 > Archives:https://www.wireshark.org/lists/wireshark-dev > Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev > mailto:wireshark-dev-requ...@wireshark.org > ?subject=unsubscribe > ___ Sent via:Wireshark-dev mailing list Archives:https://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] Plan to make NPcap available for Wireshark
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 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 > wrote: > >> >> Le 4 juil. 2015 4:26 AM, "Yang Luo" 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 >> Archives:https://www.wireshark.org/lists/wireshark-dev >> Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev >> mailto:wireshark-dev-requ...@wireshark.org >> ?subject=unsubscribe >> > > > ___ > Sent via:Wireshark-dev mailing list > Archives:https://www.wireshark.org/lists/wireshark-dev > Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev > mailto:wireshark-dev-requ...@wireshark.org > ?subject=unsubscribe > -- Graham Bloice Software Developer Trihedral UK Limited ___ Sent via:Wireshark-dev mailing list Archives:https://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] Plan to make NPcap available for Wireshark
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 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 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 >> wrote: >> >>> >>> Le 4 juil. 2015 4:26 AM, "Yang Luo" 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 >>> Archives:https://www.wireshark.org/lists/wireshark-dev >>> Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev >>> mailto:wireshark-dev-requ...@wireshark.org >>> ?subject=unsubscribe >>> >> >> >> >> ___ >> Sent via:Wireshark-dev mailing list >> Archives:https://www.wireshark.org/lists/wireshark-dev >> Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev >> mailto:wireshark-dev-requ...@wireshark.org >> ?subject=unsubscribe >> > > > > -- > Graham Bloice > Software Developer > Trihedral UK Limited > > ___ > Sent via:Wireshark-dev mailing list > Archives:https://www.wireshark.org/lists/wireshark-dev > Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev > mailto:wireshark-dev-requ...@wireshark.org > ?subject=unsubscribe > ___ Sent via:Wireshark-dev mailing list Archives:https://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] Plan to make NPcap available for Wireshark
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 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 > 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 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 >> > wrote: >>> Le 4 juil. 2015 4:26 AM, "Yang Luo" 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 Archives:https://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org ?subject=unsubscribe >>> >>> >>> >>> ___ >>> Sent via:Wireshark-dev mailing list >>> Archives:https://www.wireshark.org/lists/wireshark-dev >>> Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev >>> mailto:wireshark-dev-requ...@wireshark.org >>> ?subject=unsubscribe >>> >> >> >> >> -- >> Graham Bloice >> Software Developer >> Trihedral UK Limited >> >> >> ___ >> Sent via:Wireshark-dev mailing list >> Archives:https://www.wireshark.org/lists/wireshark-dev >> Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev >> mailto:wireshark-dev-requ...@wireshark.org >> ?subject=unsubscribe >> > > > ___ > Sent via:Wireshark-dev mailing list > Archives:https://www.wireshark.org/lists/wireshark-dev > Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev > mailto:wireshark-dev-requ...@wireshark.org > ?subject=unsubscribe > -- Graham Bloice Software Developer Trihedral UK Limited ___ Sent via:Wireshark-dev mailing list Archives:https://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] Plan to make NPcap available for Wireshark
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_{}", but we have
changed it to "\Device\NPCAP_{}"). 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
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 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.blo...@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 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.quan...@gmail.com> wrote:
>
> Le 4 juil. 2015 4:26 AM, "Yang Luo" 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 av
Re: [Wireshark-dev] Plan to make NPcap available for Wireshark
On Sat, Jul 04, 2015 at 10:26:13AM +0800, Yang Luo wrote: > 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:) If I remember correctly (and I may easily be mistaken here), Winpcap doesn't provide a mechanism to determine the library version at runtime. We need to make sure we know which version of wpcap we are using (wireshark/tshark -v). Thanks Joerg -- Joerg Mayer 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 Archives:https://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] Plan to make NPcap available for Wireshark
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_{}", but we have
> changed it to "\Device\NPCAP_{}"). 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
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
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] Plan to make NPcap available for Wireshark
On 7 July 2015 at 16:56, Joerg Mayer 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_{}", but we
> have
> > changed it to "\Device\NPCAP_{}"). 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
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] Plan to make NPcap available for Wireshark
On Jul 7, 2015, at 8:56 AM, Joerg Mayer wrote: > 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? I would hope that the long term plan is to incorporate NPcap's capabilities into WinPcap, now that the WinPcap development process is being opened up. That would presumably mean that, in the long term, there's only one library, with one API. (I'd also hope that the libpcap part of the code will just be taken from the libpcap tree, so that the only APIs *not* shared between libpcap and WinPcap would be the Windows-specific ones - although many of those are in the libpcap source - and whatever we export from Packet.dll, although Packet.dll explicitly does *not* offer a stable API.) ___ Sent via:Wireshark-dev mailing list Archives:https://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] Plan to make NPcap available for Wireshark
On Tue, Jul 07, 2015 at 09:56:24AM -0700, Guy Harris wrote: > > On Jul 7, 2015, at 8:56 AM, Joerg Mayer wrote: > > > 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? > I would hope that the long term plan is to incorporate NPcap's capabilities > into WinPcap, now that the WinPcap development process is being opened up. > That would presumably mean that, in the long term, there's only one library, > with one API. As long as that *is* the long term plan, then yes, this agrument is invalid and my objections should be ignored. Ciao Joerg -- Joerg Mayer 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 Archives:https://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] Plan to make NPcap available for Wireshark
On Tue, Jul 7, 2015 at 11:56 PM, Joerg Mayer 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_{}", but we
> have
> > changed it to "\Device\NPCAP_{}"). 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
> 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
> Archives:https://www.wireshark.org/lists/wireshark-dev
> Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
> mailto:wireshark-dev-requ...@wireshark.org
> ?subject=unsubscribe
>
___
Sent via:Wireshark-dev mailing list
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] Plan to make NPcap available for Wireshark
> 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. > > > I mean the "npf" service when I mentioned the driver name "npf.sys", usually the driver name and the service name are the same at most times. IMO this service status checking should be done in the wpcap.dll level. wpcap.dll will know what the service name is and do the job correctly. A good design is, the user software should not assume or invoke anything other than wpcap.dll. But this is what WinPcap has already been like, so no easy solution for this. ___ Sent via:Wireshark-dev mailing list Archives:https://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] Plan to make NPcap available for Wireshark
On Wed, Jul 8, 2015 at 12:56 AM, Guy Harris wrote: > > On Jul 7, 2015, at 8:56 AM, Joerg Mayer wrote: > > > 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? > > I would hope that the long term plan is to incorporate NPcap's > capabilities into WinPcap, now that the WinPcap development process is > being opened up. That would presumably mean that, in the long term, > there's only one library, with one API. > > There isn't a second API actually for now, if you mean the interface user software and WinPcap (Npcap) talks with each other. IMO the API is the wpcap.dll's name and functions. Actually Npcap didn't change one line of code in wpcap.dll source. So I think Npcap now is still sharing the same API with WinPcap. The problem that Npcap can't be used by Wireshark is just because some hard-coding things. The hard-coded paths, the hard-coded driver service name. These are not part of the API. The only API is the wpcap.dll's file name and its exported functions. Maybe WinPcap can unify the API interface in next release, so it will be easy for other alternatives like Npcap to follow. (I'd also hope that the libpcap part of the code will just be taken from > the libpcap tree, so that the only APIs *not* shared between libpcap and > WinPcap would be the Windows-specific ones - although many of those are in > the libpcap source - and whatever we export from Packet.dll, although > Packet.dll explicitly does *not* offer a stable API.) > ___ > Sent via:Wireshark-dev mailing list > Archives:https://www.wireshark.org/lists/wireshark-dev > Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev > mailto:wireshark-dev-requ...@wireshark.org > ?subject=unsubscribe > ___ Sent via:Wireshark-dev mailing list Archives:https://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
