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): wireshark-1.0.0-2.fc9 How reproducible: always Steps to Reproduce: 1.store privileges by starting an application which adds them (potentially wireshark itself). If the latter, leave wireshark again. 2.start wireshark 3. Actual results: no dialog asking whether privileges should be used Expected results: dialog asking whether privileges should be used. Additional info:
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.
Thanks Tomas! The proposed change will cause consolehelper to always require password before launching wireshark, so the wireshark will not get started with root privileges by accident. 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. http://rhn.redhat.com/errata/RHSA-2008-0890.html