Date: Thu, 29 May 2014 21:57:28 +0300 From: Dolev Farhi <dolev@...nflare.org> To: oss-security <oss-security@...ts.openwall.com> Subject: Re: CVE request: sos: /etc/fstab collected by sosreport, possibly containing passwords I tend to agree with most of this actually, but since sosreport is there to collect information for troubleshooting issues only, then there is no actual reason not to remove the pw field of a mount in fstab, even though the file is world readable in the first place. I do agree that this widens the scope from Red Hats side especially while most of the time it would be close to impossible to prevent password disclosures in configuration files, especially when it depends on the random way a sysadmin alters config files. Best practice is to use the credentials option and point fstab to read the mount username and password from a file but there are multiple ways to achieve the same goal. I am not sure regarding the necessity of a CVE here, though I dont see much of a difference between this to any other password disclosures (such as grub.conf) discovered in sosreport in the past, except that fstab is world readable. On both cases the problem is that this file is handled by 3rd parties. Thanks -- Dolev Farhi 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
Powered by blists - more mailing lists
Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.