Re: [Wireshark-dev] Wireshark on Kali linux

[João Valverde]

On 06/02/19 17:31, Guy Harris wrote:

On Feb 6, 2019, at 5:06 AM, Peter Wu  wrote:


On Wed, Feb 06, 2019 at 12:46:20PM +, João Valverde wrote:


I have some doubts about the effectiveness and usefulness of this Lua
sandbox. I didn't investigate in depth but it seems enabling/disabling the
Lua runtime instead would be better, as dictated by policy (whatever that
policy is).


Setting "enable_lua = false" (formerly "disable_lua = true") already
prevents further Lua code from being executed. Likewise when
"run_user_scripts_when_superuser" is false and when started as root.

I also question the utility of disabling the API, hence these patches:

wslua: do not load console.lua when run as root
https://code.wireshark.org/review/31912

wslua: do not partially disable the Lua API when run as root
https://code.wireshark.org/review/31913

The first patch can be safely be backported and should fix the issue
raised by Kali Linux users. Worst-case, it disables the GUI menu option,
but it has no effect otherwise.

The second patch removes the security theatre, but depends on the first
patch to effectively restrict execution of arbitrary user-supplied code.
It enables arbitrary execution of user-supplied code by default since
those who execute "tshark -Xlua_script:foo.lua" as root user (or via
sudo) will expect it to work.

Finally, note that "started_with_special_privs()" also returns TRUE even
if the current user has no more privileges. Even if the Wireshark or
tshark executables were setuid root, these root privileges have already
been dropped via "relinquish_special_privs_perm()", long before it ever
gets to the Lua code.


OK, so Wireshark and TShark are normally run in some form of user session, 
whether it's a GUI session or not; in those sessions, there's normally 
credentials (user and groups) for the logged-in user.


(...)


So the question is whether we should print/pop up a message if TShark/Wireshark 
is running as root - and, if we do, whether we should have a compile or 
configuration option to disable that, so it can be disabled on Kali Linux or 
other OSes where you don't have much of a choice about whether to run them as 
root.



I think a warning for "running Wireshark/tshark as root is dangerous" is 
very appropriate. There is a legitimate discussion to be had on whether 
it should be more or less forceful and what to do about Kali.


But throwing a Lua runtime exception for root is not such a warning. 
That's just a bug in my opinion.


Furthermore if a user builds Wireshark without Lua no warning is emitted.
___
Sent via:Wireshark-dev mailing list 
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] Wireshark on Kali linux

[Graham Bloice]

On Wed, 6 Feb 2019 at 17:32, Guy Harris  wrote:

>
> 
>
> So the question is whether we should print/pop up a message if
> TShark/Wireshark is running as root - and, if we do, whether we should have
> a compile or configuration option to disable that, so it can be disabled on
> Kali Linux or other OSes where you don't have much of a choice about
> whether to run them as root.
>
>
+1 for this.  I haven't entirely followed the preceding technical
discussion as it's mostly about platforms I have little knowledge about,
but this in general seems to be a fair approach.  Of course there will be
those who have no need to run as "root", who will ignore the advice and
disable the warning and continue to run as "root" on the way to ruin.  So
be it, we will have tried.

-- 
Graham Bloice
___
Sent via:Wireshark-dev mailing list 
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] Edit access to the Wiki

[Gerald Combs]

Done.

On 2/6/19 9:07 AM, Mike Lugo (milugo) via Wireshark-dev wrote:
> My username is “MikeLugo”.
> 
>  
> 
> --Mike
> 
>  
> 
> https://www.cisco.com/c/dam/m/en_us/signaturetool/images/banners/standard/08_standard_graphic.png
> 
>   
> 
> *Mike Lugo*
> 
> TECHNICAL LEADER.SERVICES
> 
> mil...@cisco.com 
> 
> Tel: *+1 919 392 9445*
> 
>  
> 
>  
> 
>  
> 
>  
> 
>   
> 
> Cisco Systems, Inc.
> 
> 7200-12 Kit Creek Road PO Box 14987
> 
> RESEARCH TRIANGLE PARK
> 
> 27709-4987
> 
> United States
> 
> cisco.com
> 
> http://www.cisco.com/assets/swa/img/thinkbeforeyouprint.gif
> 
>   
> 
> Think before you print.
> 
> This email may contain confidential and privileged material for the sole
> use of the intended recipient. Any review, use, distribution or disclosure
> by others is strictly prohibited. If you are not the intended recipient (or
> authorized to receive for the recipient), please contact the sender by
> reply email and delete all copies of this message.
> 
> Please click here
> 
> for Company Registration Information.
> 
>   
> 
>  
> 
>  
> 
> *From:* Mike Lugo (milugo)
> *Sent:* Wednesday, February 6, 2019 12:06 PM
> *To:* wireshark-dev@wireshark.org
> *Subject:* Edit access to the Wiki
> 
>  
> 
> Wireshark-Dev,
> 
>  
> 
> Would like to get edit access to the site that contains this page:
> 
>  
> 
> https://wiki.wireshark.org/Mate/GettingStarted
> 
>  
> 
> The MATE configuration is available at “Preferences > Protocols > MATE” not
> “Preferences > MATE”.
> 
>  
> 
> By the way, this page is correct: 
> https://www.wireshark.org/docs/wsug_html_chunked/ChMateGettingStarted.html
> 
>  
> 
> Thanks,
> 
> Mike
> 
>  
> 
> https://www.cisco.com/c/dam/m/en_us/signaturetool/images/banners/standard/08_standard_graphic.png
> 
>   
> 
> *Mike Lugo*
> 
> TECHNICAL LEADER.SERVICES
> 
> mil...@cisco.com 
> 
> Tel: *+1 919 392 9445*
> 
>  
> 
>  
> 
>  
> 
>  
> 
>   
> 
> Cisco Systems, Inc.
> 
> 7200-12 Kit Creek Road PO Box 14987
> 
> RESEARCH TRIANGLE PARK
> 
> 27709-4987
> 
> United States
> 
> cisco.com
> 
> http://www.cisco.com/assets/swa/img/thinkbeforeyouprint.gif
> 
>   
> 
> Think before you print.
> 
> This email may contain confidential and privileged material for the sole
> use of the intended recipient. Any review, use, distribution or disclosure
> by others is strictly prohibited. If you are not the intended recipient (or
> authorized to receive for the recipient), please contact the sender by
> reply email and delete all copies of this message.
> 
> Please click here
> 
> for Company Registration Information.
> 
>   
> 
>  
> 
>  
> 
> 
> ___
> Sent via:Wireshark-dev mailing list 
> Archives:https://www.wireshark.org/lists/wireshark-dev
> Unsubscribe: https://www.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://www.wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] Wireshark on Kali linux

[Guy Harris]

On Feb 6, 2019, at 5:06 AM, Peter Wu  wrote:

> On Wed, Feb 06, 2019 at 12:46:20PM +, João Valverde wrote:
> 
>> I have some doubts about the effectiveness and usefulness of this Lua
>> sandbox. I didn't investigate in depth but it seems enabling/disabling the
>> Lua runtime instead would be better, as dictated by policy (whatever that
>> policy is).
> 
> Setting "enable_lua = false" (formerly "disable_lua = true") already
> prevents further Lua code from being executed. Likewise when
> "run_user_scripts_when_superuser" is false and when started as root.
> 
> I also question the utility of disabling the API, hence these patches:
> 
> wslua: do not load console.lua when run as root
> https://code.wireshark.org/review/31912
> 
> wslua: do not partially disable the Lua API when run as root
> https://code.wireshark.org/review/31913
> 
> The first patch can be safely be backported and should fix the issue
> raised by Kali Linux users. Worst-case, it disables the GUI menu option,
> but it has no effect otherwise.
> 
> The second patch removes the security theatre, but depends on the first
> patch to effectively restrict execution of arbitrary user-supplied code.
> It enables arbitrary execution of user-supplied code by default since
> those who execute "tshark -Xlua_script:foo.lua" as root user (or via
> sudo) will expect it to work.
> 
> Finally, note that "started_with_special_privs()" also returns TRUE even
> if the current user has no more privileges. Even if the Wireshark or
> tshark executables were setuid root, these root privileges have already
> been dropped via "relinquish_special_privs_perm()", long before it ever
> gets to the Lua code.

OK, so Wireshark and TShark are normally run in some form of user session, 
whether it's a GUI session or not; in those sessions, there's normally 
credentials (user and groups) for the logged-in user.

If Wireshark or TShark is running with the credentials of the logged-in user, 
it's not running with elevated (or reduced) privileges.  It's still not 
necessarily secure - bugs attackable by maliciously crafted packets, malicious 
plugins, etc. may still cause it to perform actions, with the logged-in user's 
privileges, that the user wouldn't want done - but that's a separate issue.

In that case, I see no reason to limit where Wireshark looks for plugins, or 
whether a Lua read-evaluate-print loop (REPL loop), such as Tools > Lua > 
Evaluate, can be run.

On Kali Linux, "the logged-in user" is, apparently, root.  Therefore, I don't 
think we should have a hard policy of "if Wireshark is running with an 
effective user ID of root, we won't allow a Lua REPL", or "if Wireshark is 
running with a real user ID of root, we won't allow a Lua REPL".

If Wireshark or TShark is *not* running with the credentials of the logged-in 
user, it's probably running with elevated privileges - although it could 
conceivably be running with *reduced* privileges, if it's set-UID or set-GID to 
a user or group with fewer privileges than the logged-in user.  I don't think 
there's an easy way to determine whether you're running with elevated or 
reduced privileges, unless the credentials you're running with are root on UN*X 
or an administrator on Windows, in which case the privileges are (almost?) 
certainly elevated.

If it's running set-UID or set-GID on UN*X - I'm not sure Windows has an 
equivalent - there's no guarantee that the user has an inherent right to 
perform arbitrary actions with the credentials under which Wireshark or TShark 
is running; set-UID/set-GID is intended to allow a user to perform *those 
actions that the set-UID/set-GID program permits the user to perform* with 
those credentials.

As such, if Wireshark or TShark is running set-UID or set-GID:

it mustn't be allowed to load shared libraries from directories that 
the user specifies by, for example, setting an environment variable;

it mustn't be allowed to load shared libraries from any directory into 
which the user can put files;

it mustn't be allowed to load shared libraries that the user can modify;

it mustn't be allowed to preload special shared libraries or replace 
individual shared libraries that the user specifies by, for example, setting an 
environment variable;

it mustn't be allowed to run programs from directories that the user 
specifies by, for example, setting an environment variable;

it mustn't be allowed to run programs from any directory into which the 
user can put files;

it mustn't be allowed to run programs that the user can modify;

it mustn't be allowed to load compiled plugins or Lua scripts from 
directories that the user specifies by, for example, setting an environment 
variable;

it mustn't be allowed to load compiled plugins or Lua scripts from any 
directory into which the user can put files;

it mustn't be allowed to load compiled plugins or Lua scripts that the 
user can modify;

etc., 

Re: [Wireshark-dev] Edit access to the Wiki

[Mike Lugo (milugo) via Wireshark-dev]

My username is "MikeLugo".

--Mike

[https://www.cisco.com/c/dam/m/en_us/signaturetool/images/banners/standard/08_standard_graphic.png]




Mike Lugo
TECHNICAL LEADER.SERVICES
mil...@cisco.com
Tel: +1 919 392 9445










Cisco Systems, Inc.
7200-12 Kit Creek Road PO Box 14987
RESEARCH TRIANGLE PARK
27709-4987
United States
cisco.com



[http://www.cisco.com/assets/swa/img/thinkbeforeyouprint.gif]

Think before you print.

This email may contain confidential and privileged material for the sole use of 
the intended recipient. Any review, use, distribution or disclosure by others 
is strictly prohibited. If you are not the intended recipient (or authorized to 
receive for the recipient), please contact the sender by reply email and delete 
all copies of this message.
Please click 
here
 for Company Registration Information.







From: Mike Lugo (milugo)
Sent: Wednesday, February 6, 2019 12:06 PM
To: wireshark-dev@wireshark.org
Subject: Edit access to the Wiki

Wireshark-Dev,

Would like to get edit access to the site that contains this page:

https://wiki.wireshark.org/Mate/GettingStarted

The MATE configuration is available at "Preferences > Protocols > MATE" not 
"Preferences > MATE".

By the way, this page is correct:  
https://www.wireshark.org/docs/wsug_html_chunked/ChMateGettingStarted.html

Thanks,
Mike

[https://www.cisco.com/c/dam/m/en_us/signaturetool/images/banners/standard/08_standard_graphic.png]




Mike Lugo
TECHNICAL LEADER.SERVICES
mil...@cisco.com
Tel: +1 919 392 9445










Cisco Systems, Inc.
7200-12 Kit Creek Road PO Box 14987
RESEARCH TRIANGLE PARK
27709-4987
United States
cisco.com



[http://www.cisco.com/assets/swa/img/thinkbeforeyouprint.gif]

Think before you print.

This email may contain confidential and privileged material for the sole use of 
the intended recipient. Any review, use, distribution or disclosure by others 
is strictly prohibited. If you are not the intended recipient (or authorized to 
receive for the recipient), please contact the sender by reply email and delete 
all copies of this message.
Please click 
here
 for Company Registration Information.







___
Sent via:Wireshark-dev mailing list 
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

[Wireshark-dev] Edit access to the Wiki

[Mike Lugo (milugo) via Wireshark-dev]

Wireshark-Dev,

Would like to get edit access to the site that contains this page:

https://wiki.wireshark.org/Mate/GettingStarted

The MATE configuration is available at "Preferences > Protocols > MATE" not 
"Preferences > MATE".

By the way, this page is correct:  
https://www.wireshark.org/docs/wsug_html_chunked/ChMateGettingStarted.html

Thanks,
Mike

[https://www.cisco.com/c/dam/m/en_us/signaturetool/images/banners/standard/08_standard_graphic.png]




Mike Lugo
TECHNICAL LEADER.SERVICES
mil...@cisco.com
Tel: +1 919 392 9445










Cisco Systems, Inc.
7200-12 Kit Creek Road PO Box 14987
RESEARCH TRIANGLE PARK
27709-4987
United States
cisco.com



[http://www.cisco.com/assets/swa/img/thinkbeforeyouprint.gif]

Think before you print.

This email may contain confidential and privileged material for the sole use of 
the intended recipient. Any review, use, distribution or disclosure by others 
is strictly prohibited. If you are not the intended recipient (or authorized to 
receive for the recipient), please contact the sender by reply email and delete 
all copies of this message.
Please click 
here
 for Company Registration Information.







___
Sent via:Wireshark-dev mailing list 
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] Wireshark on Kali linux

[Peter Wu]

On Wed, Feb 06, 2019 at 12:46:20PM +, João Valverde wrote:
> 
> 
> On 06/02/19 09:08, Dario Lombardo wrote:
> >  > This would mean that they'd have to build Wireshark differently from
> > the default way it's built, using the "package for systems that run
> > everything as root" option.  That means a standard Debian package, built
> > to run on a system where you *don't* run everything as root, so that you
> > can leave the safety checks in place, won't be appropriate for Kali.
> > 
> > I was thinking to something like maintaining a list of debian derivative
> > that have just the root account (the version checked with lsb_release)
> > and run something on them during the installation phase.
> > 
> >  > - use something else other than error() when disabling dofile()
> >  > (something that won't generate such a disruptive dialog window for
> > example).
> > 
> > That was my first try. Something like error -> warning, but I didn't
> > find anything useful. Are you aware of something?
> > 
> 
> I'm not aware of anything out-of-the-box. It would probably require some UX
> work in Qt to make this notification more user-friendly.

Any dialog would be equally annoying. Perhaps there is a way to push a
statusbar message, but honestly I don't think Lua is the appropriate
place to warn about some stupid behavior.

So tshark already prints a warning when started as (setuid) root. The
GUI does not. It could be modified to show a dialog, but it should
probably also present a "Do not mention this again" checkbox for systems
like Kali Linux where running everything as root is the norm.

> I have some doubts about the effectiveness and usefulness of this Lua
> sandbox. I didn't investigate in depth but it seems enabling/disabling the
> Lua runtime instead would be better, as dictated by policy (whatever that
> policy is).

Setting "enable_lua = false" (formerly "disable_lua = true") already
prevents further Lua code from being executed. Likewise when
"run_user_scripts_when_superuser" is false and when started as root.

I also question the utility of disabling the API, hence these patches:

wslua: do not load console.lua when run as root
https://code.wireshark.org/review/31912

wslua: do not partially disable the Lua API when run as root
https://code.wireshark.org/review/31913

The first patch can be safely be backported and should fix the issue
raised by Kali Linux users. Worst-case, it disables the GUI menu option,
but it has no effect otherwise.

The second patch removes the security theatre, but depends on the first
patch to effectively restrict execution of arbitrary user-supplied code.
It enables arbitrary execution of user-supplied code by default since
those who execute "tshark -Xlua_script:foo.lua" as root user (or via
sudo) will expect it to work.

Finally, note that "started_with_special_privs()" also returns TRUE even
if the current user has no more privileges. Even if the Wireshark or
tshark executables were setuid root, these root privileges have already
been dropped via "relinquish_special_privs_perm()", long before it ever
gets to the Lua code.
-- 
Kind regards,
Peter Wu
https://lekensteyn.nl
___
Sent via:Wireshark-dev mailing list 
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] Wireshark on Kali linux

[João Valverde]

On 06/02/19 09:08, Dario Lombardo wrote:
 > This would mean that they'd have to build Wireshark differently from 
the default way it's built, using the "package for systems that run 
everything as root" option.  That means a standard Debian package, built 
to run on a system where you *don't* run everything as root, so that you 
can leave the safety checks in place, won't be appropriate for Kali.


I was thinking to something like maintaining a list of debian derivative 
that have just the root account (the version checked with lsb_release) 
and run something on them during the installation phase.


 > - use something else other than error() when disabling dofile()
 > (something that won't generate such a disruptive dialog window for 
example).


That was my first try. Something like error -> warning, but I didn't 
find anything useful. Are you aware of something?




I'm not aware of anything out-of-the-box. It would probably require some 
UX work in Qt to make this notification more user-friendly.


I have some doubts about the effectiveness and usefulness of this Lua 
sandbox. I didn't investigate in depth but it seems enabling/disabling 
the Lua runtime instead would be better, as dictated by policy (whatever 
that policy is).

___
Sent via:Wireshark-dev mailing list 
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] Lua error while running Wireshark as root (was: Re: Wireshark on Kali linux)

[Peter Wu]

On Tue, Feb 05, 2019 at 03:47:47PM -0800, Guy Harris wrote:
> 
> On Feb 5, 2019, at 2:38 PM, Peter Wu  wrote:
> 
> > On Tue, Feb 05, 2019 at 02:25:58PM -0800, Guy Harris wrote:
> >> On Feb 5, 2019, at 2:07 PM, Peter Wu  wrote:
> >> 
> >>> The last option would permit *users* to invoke arbitrary commands as
> >>> root if they run Wireshark with sudo or as root user. I think that might
> >>> not be a bad idea after all:
> >> 
> >>[existing reasons elided]
> >> 
> >> - They shouldn't be running *Wireshark* as root unless they're on a
> >> system such as Kali where everything runs as root; if they need root
> >> privileges in order to capture, they should make dumpcap set-UID root.
> > 
> > I agree, a warning is already printed by tshark when running it as root.
> 
> Depending on whether you have issetugid() or not.
> 
> On UN*X, started_with_special_privs() is:
> 
> /*
>  * "Started with special privileges" means "started out set-UID or set-GID",
>  * or run as the root user or group.
>  */
> gboolean
> started_with_special_privs(void)
> {
>   g_assert(init_process_policies_called);
> #ifdef HAVE_ISSETUGID
>   return issetugid();
> #else
>   return (ruid != euid || rgid != egid || ruid == 0 || rgid == 0);
> #endif
> }
> 
> If you have issetugid(), it just returns what that returns; it's a system 
> call that never fails.  In recent macOS, the comment for the kernel routine is
> 
>  * Notes:   A process is considered tainted if it was created as a retult
>  *  of an execve call from an imnage that had either the SUID or
>  *  SGID bit set on the executable, or if it has changed any of 
> its
>  *  real, effective, or saved user or group IDs since beginning  
>  *  execution.
> 
> and it returns 1 if the process is "tainted" and 0 if it isn't (it just 
> checks a flag set elsewhere).  Other *BSD-flavored OSes may do the check 
> differently; macOS has a comment that
> 
>   /*
>* Note: OpenBSD sets a P_SUGIDEXEC flag set at execve() time,
>* we use P_SUGID because we consider changing the owners as
>* "tainting" as well.
>* This is significant for procs that start as root and "become"
>* a user without an exec - programs cannot know *everything*
>* that libc *might* have put in their data segment.
>*/
> 
> I think OpenBSD was the system that introduced issetugid(); all the *BSDs, 
> and macOS, have it.
> 
> I'm not sure whether any Linux distributions have issetugid(); I'm not seeing 
> a symbol "issetugid" in Glibc 2.23 or the 4.20.3 kernel.  Solaris might have 
> it.

Linux does not have issetugid() to detect whether the user was *ever*
changed.

> If you log in as root (the Kali Linux case), should *every program you
> run* be deemed as "started with special privileges"?  If not, how do
> you distinguish that from "run with sudo"?

These situations are equivalent, the real and (saved) effective UIDs are
root (uid 0) in all cases. Since relinquish_special_privs_perm cannot
drop to a lower-privileged uid, Wireshark will continue running with
more privileges than necessary.

> Should we consider "running as root" to be "running with elevated
> privileges" even if issetuid() returns 0 (because your program didn't
> get its privileges from set-UID), and issue a UI warning in that case?

issetugid returning 0 is not relevant for (Kali) Linux. Nevertheless,
given that:

 - We recommend dumpcap to be configured with capabilities or setuid.
 - We want to avoid users to run tshark/wireshark as privileged user
   (using any of sudo / setuid / login as root) to reduce the attack
   vector.

then starting wireshark as root probably deserves a warning.
-- 
Kind regards,
Peter Wu
https://lekensteyn.nl
___
Sent via:Wireshark-dev mailing list 
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] Wireshark on Kali linux

[Dario Lombardo]

> This would mean that they'd have to build Wireshark differently from the
default way it's built, using the "package for systems that run everything
as root" option.  That means a standard Debian package, built to run on a
system where you *don't* run everything as root, so that you can leave the
safety checks in place, won't be appropriate for Kali.

I was thinking to something like maintaining a list of debian derivative
that have just the root account (the version checked with lsb_release) and
run something on them during the installation phase.

> - use something else other than error() when disabling dofile()
> (something that won't generate such a disruptive dialog window for
example).

That was my first try. Something like error -> warning, but I didn't find
anything useful. Are you aware of something?
___
Sent via:Wireshark-dev mailing list 
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe