Re: CVE request: sos: /etc/fstab collected by sosreport, possibly containing passwords

["Vincent Danen" <vdanen () redhat com>]

On 05/29/2014, at 5:03 AM, Murray McAllister wrote:

> Good morning,
>
> From <https://bugzilla.redhat.com/show_bug.cgi?id=1102633>:
>
> 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.
>
> I think it should have a CVE, but I am less sure due to "/etc/fstab" being world-readable, so I have not assigned one.

Just going to note here what I put as a comment in the bug in case anyone feels differently.  I'm of the frame of mind 
that this shouldn't get a CVE for the reasons noted below:


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).



-- 
Vincent Danen / Red Hat Product Security

Attachment: signature.asc
Description: OpenPGP digital signature