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

Follow @Openwall on Twitter for new release announcements and other news

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAHVLS-cg7ODiz=FYx=KAD4qS-UrX7RpqAXhRMUcCbBs-zF03ZQ@mail.gmail.com>
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

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.