Description of problem:
Recently I had to start wireshark to look at a log file sent to me by somebody
else. Prudence requires that I look at the files without wireshark having any
privileges. But since I have shortly before started another application which
required privileges this funky privilege storing took over and I ended up with
automatically and to the inexperienced person unnoticeable using privileges.
That's a security problem. What if the log contains an exploit for a buffer
overflow in wireshark itself?
wireshark should always at startup ask whether privileges are wanted. If they
are wanted and the privileges are stored, no password needs to be entered. But
the decision to use them must be made at every startup.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1.store privileges by starting an application which adds them (potentially
wireshark itself). If the latter, leave wireshark again.
no dialog asking whether privileges should be used
dialog asking whether privileges should be used.
This is a correct consolehelper behavior. Consolehelper stores your password for
certain time, so all applications which requires root access can be started with
prompting for root pswd in this time frame. You can see the "shield" icon in
your taskbar. If you open it's menu, there's a "drop privilegies" option which
immediately forgets the root pswd.
I realize the this is what you expect for applications which *always* require
privileges. It's definitely the correct behaviour for them.
But wireshark is special. It does not always have to use privileges. It only
needs privileges if you want to record data. But if you replay data you
definitely do not want the privileges. Already recorded data can be malformed
and perhaps be malicious. It could be used to exploit a bug in wireshark and
with privileges the entire machine can be taken over.
I.e., programs which *optionally* in some situations need privileges should ask
the user on startup whether available privileges should be used or not.
Anything else is a security problem.
I agree with Ulrich. NVD set the severity of Wireshark issues to be moderate
and low because best practice is to not examine untrusted recorded packets as
root. This interaction with consolehelper will mean we have to increase the
severity of Wireshark security issues (of which there are many and frequent).
Is there some better way to deal with this (have it drop privileges again when
not needing the interface?)
The easiest way to fix this is to simply drop the pam_timestamp from wireshark
PAM configuration - that means with current Fedoras to copy
/etc/pam.d/config-util to /etc/pam.d/wireshark and remove all pam_timestamp.so
lines from there.
The proposed change will cause consolehelper to always require password before
launching wireshark, so the wireshark will not get started with root privileges
pam.d/wireshark could possibly continue including config-util for account and
session, but will require auth specification without pam_timestamp.
For wireshark packages in Red Hat Enterprise Linux 2.1, 3 and 4, lines with
pam_timestamp.so should be removed from pam.d/wireshark.
This is already fixed in Fedora. I'll include this fix into RHEL variants in next update.
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on therefore solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.