It was reported that sosreport collected and stored "/etc/fstab" in the resulting archive of debugging information. This may contain plain text passwords (or a link to the file containing them), for example, credentials for Samba mounts. This could leak passwords to an attacker who is able to access the archive. Sensitive information in "/etc/fstab" should be sanitized before being stored by sosreport. Note that "/etc/fstab" is world-readable, so local attackers should not be a concern (they can read the file anyway). This could be an issue when the sosreport is sent to other parties. Acknowledgements: Red Hat would like to thank Dolev Farhi of F5 Networks for reporting this issue.
Created sos tracking bugs for this issue: Affects: fedora-all [bug 1102640]
CVE request: http://www.openwall.com/lists/oss-security/2014/05/29/6
I don't think it's ever been advised to store password in /etc/fstab, so if you trust local users enough to view that file, then whatever sosreport stores in /tmp is probably just as "safe". sosreport is run manually by an administrator, and the resultant archive is stored in /tmp (/var/tmp in Fedora), but the administrator actually has to send this archive to someone. sosreport also has this warning before it even runs (except on Red Hat Enterprise Linux 5): "The generated archive may contain data considered sensitive and its content should be reviewed by the originating organization before being passed to any third party." Because sosreport makes no claims to not collecting private data (and explicitly indicates that it might), and the point of it is to collect pertinent system data (excluding some obvious things like kerberos keys or files with known sensitive information that does not aid in diagnostic process), I don't know if this can actually be considered a flaw. After all, random sysadmin might decide to put anything in any file that sosreport collects that we could never "teach" sosreport to ignore or scrub (you could try to do pattern-based matching on contents of files but you'll never catch everything).
I agree - these types of problems (although we consider them bugs) really don't seem to meet the requirements for a 'vulnerability' in the CVE sense of the term. An 'attacker' can only benefit from the information if an authorized user makes it available to them (the claim that files are left world-readable in /tmp in one of the recent bugs is false). They are a privacy concern for users who do not adequately review the data collected from their own systems and ignore the disclaimer text and we maintain the password scrubbing features as a convenience to minimize the manual review effort required. We've never tried to imply that the scrubbing is perfect and went through several rounds of legal review last year to tighten up the wording presented in the UI to make this clear. > After all, random sysadmin might decide to put anything in any file that > sosreport collects Right; and this does happen, particularly in the context of support cases (the primary use of sos). A typo in a shell redirection or cp command can spray unexpected content around in ways that are impossible to predict or automatically detect. > except on Red Hat Enterprise Linux 5 Due to be fixed in 5.11 via bug 1065468 - it was the first el5 release available after we'd completed reviews. I'd much rather we kept CVEs and the full security process for problems like bug 1099151 (insecure temp files in el5's sos) where a local user can actually cause real harm.
Fixed upstream: commit 7b46d34654735d925bcb2a3e4b27b65dce994519 Author: Bryn M. Reeves <bmr> Date: Fri May 30 14:41:42 2014 +0100 Add postprocessing for /etc/fstab passwords Signed-off-by: Bryn M. Reeves <bmr> Results in e.g.: # cat sosreport-localhost.localdomain-20140530143824/etc/fstab # # /etc/fstab # Created by anaconda on Tue Mar 4 12:25:18 2014 # # Accessible filesystems, by reference, are maintained under '/dev/disk' # See man pages fstab(5), findfs(8), mount(8) and/or blkid(8) for more info # /dev/vg_hex/lv_root / ext4 defaults 1 1 UUID=8bfc0989-fa8f-466c-8c91-0cd80ff28024 /boot ext4 defaults 1 2 /dev/mapper/luks-79733921-3f68-4c92-9eb7-d0aca4c6ba3e /home ext4 defaults,x-systemd.device-timeout=0 1 2 /dev/vg_hex/lv_swap swap swap defaults 0 0 /dev/vg_hex/lv_images /var/lib/libvirt/images xfs defaults 1 2 //server/share cifs user=auser,password=******** 0 0
There was a CVE assignment by MITRE: http://www.openwall.com/lists/oss-security/2014/05/30/3 However, that is for the language used in Red Hat Enterprise Linux 5 versus that used in Red Hat Enterprise Linux 6 and later, which was noted in comment #4 as planning to be fixed. I'll file a bug for that CVE. This one is not a security bug (the fstab contents) and will not be treated as such. Seeing it fixed upstream is sufficient. Thanks for that info, Bryn.