Wireshark · Wireshark-bugs: [Wireshark-bugs] [Bug 6402] New: Wireshark installer creates group using poor choice of GID

[bugzilla-daemon@xxxxxxxxxxxxx]

https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=6402

           Summary: Wireshark installer creates group using poor choice of
                    GID
           Product: Wireshark
           Version: 1.6.2
          Platform: x86-64
        OS/Version: Mac OS X 10.6
            Status: NEW
          Severity: Normal
          Priority: Low
         Component: Extras
        AssignedTo: bugzilla-admin@xxxxxxxxxxxxx
        ReportedBy: mschmitt@xxxxxxx


Build Information:
Version 1.6.2 (SVN Rev 38931 from /trunk-1.6)
--
Overview: Wireshark 1.6.2 installer changes group on large number of
non-Wireshark files.

Steps to Reproduce:  Install Wireshark 1.6.2 on a machine that did not
previously contain the access_bpf group.  It is OK if the machine has a
previous version of Wireshark installed.

Enter terminal command: sudo find -x / -group access_bpf -ls

Actual Results: 

1. Go to System Preferences > Accounts. Notice that the current user now
belongs to a strange "access_bpf" group.

2. Enter terminal command: sudo find -x / -group access_bpf -ls

A list of files will be displayed as belonging to Wireshark's access_bpf group.
In my case there are 890 files, in varied locations as:

/Applications/Remote Desktop Connection.app
/System/Library/CoreServices/.diagnostics
/usr/local/bin
/usr/local/lib
/usr/local/libexec
/usr/local/share

Expected Results:

1. The access_bpf group should be a hidden group.

2. The group on existing files should not change.

Explanation:

Wireshark bug 5756 "Wireshark probably should have an Installer package rather
than be drag-install" made a change to the ChmodBPF installer: "t has been
modified to grant access to the "access_bpf" group (modeled after
com.apple.access_*). A postinstall script creates access_bpf and adds the
current user to the group."   

The installer is creating the group using dseditgroup: dseditgroup -q -o create
access_bpf

Since it is not providing the group number to create (-i nnn) it defaults to
creating the next group number higher than 500.  On my machine it created GID
501.

This has two effects.

The first is that it is a *visible* group.  Note that the bug text quoted above
said they were intending to model it after com.apple.access_*, which is an
invisible group, by virtue of them being lower group numbers.

I don't see any reason why the membership in access_bpf should be visible to
the user.

The 2nd effect is worse.  The problem is that 501 happens to be the same as the
default UID for the first user on the machine.  And for whatever reason(s),
there are files on the machine that have UIDs as the group.

Before Wireshark is installed, these files would show as owner = username,
group = 501.  After Wireshark is installed, they all appear as owner=username,
group=access_bpf.

Then the user starts to wonder what the implications are. Does this mean that
security is compromised?  Is this related to ChmodBPF? Since ChmodBPF is doing
setsuid, are we now granting access to files that we shouldn't? 

It just looks real bad.


Suggested fix:

What we want to do is create the access_bpf group with a GID < 500, but it
needs to be a GID that isn't already in use.

As far as I can tell, neither dscl nor dseditgroup can do this directly.

I can think of three approaches:

1. Keep trying to create the group with specific group numbers (incrementing
each time) until it works.

2. Iterate through group numbers, testing to see if it already exists, until a
number is found that does not exist.  (e.g. dscl . -search /Groups gid nnn)

3. Get the list of group numbers in use (e.g. dscl . readall /Groups
PrimaryGroupID) then look through the list for one that doesn't already exist.

I've seen some code on the web, but I'm not sure if it is the most efficient
way to do it: http://codesnippets.joyent.com/posts/show/1405

Repairing the damage:

Fixing the installer to assign group < 500 won't fix existing machines, unless
we had logic like this:

   if access_bpf group exists and its gid > 500
      delete the group
   end if
   create group using new logic ...


Note: I'm not a shell script expert but I might be able to take a shot at it if
no one else volunteers.

-- 
Configure bugmail: https://bugs.wireshark.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching all bug changes.