Bug 1102633

Summary: sos: /etc/fstab collected by sosreport, possibly containing passwords
Product: [Other] Security Response Reporter: Murray McAllister <mmcallis>
Component: vulnerabilityAssignee: Red Hat Product Security <security-response-team>
Status: CLOSED NOTABUG QA Contact:
Severity: low Docs Contact:
Priority: low    
Version: unspecifiedCC: agk, bmr, dolev, gavin, jkurik, kroberts, vdanen
Target Milestone: ---Keywords: Security
Target Release: ---   
Hardware: All   
OS: Linux   
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2014-05-30 18:05:06 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Bug Depends On: 1102640    
Bug Blocks: 1101415    

Description Murray McAllister 2014-05-29 11:01:06 UTC
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.


Red Hat would like to thank Dolev Farhi of F5 Networks for reporting this issue.

Comment 1 Murray McAllister 2014-05-29 11:15:27 UTC
Created sos tracking bugs for this issue:

Affects: fedora-all [bug 1102640]

Comment 2 Murray McAllister 2014-05-29 11:16:57 UTC
CVE request: http://www.openwall.com/lists/oss-security/2014/05/29/6

Comment 3 Vincent Danen 2014-05-29 16:39:25 UTC
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).

Comment 4 Bryn M. Reeves 2014-05-30 10:55:57 UTC
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.

Comment 5 Bryn M. Reeves 2014-05-30 13:44:03 UTC
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

Comment 6 Vincent Danen 2014-05-30 18:05:06 UTC
There was a CVE assignment by MITRE:


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.