Date: Fri, 30 May 2014 12:38:01 -0400 (EDT) From: cve-assign@...re.org To: oss-security@...ts.openwall.com Cc: cve-assign@...re.org, mmcallis@...hat.com, kseifried@...hat.com, vdanen@...hat.com Subject: Re: CVE request: sos: /etc/fstab collected by sosreport, possibly containing passwords -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 > From: Kurt Seifried <kseifried@...hat.com> > Date: Thu, 29 May 2014 13:20:11 -0600 > > /etc/fstab is world readable, within that system. The file is then > being exported to Red Hat, we don't really need or want the password, > we also make an effort to sanitize the data sent, so if nothing else > this falls into the "intended/advertised security feature that failed" > https://bugzilla.redhat.com/show_bug.cgi?id=1102633#c3 > > 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." > https://access.redhat.com/site/solutions/3592 > > collect system log files, configuration details and system information > > If sosreport fails due to "No space left on device" for the device > https://bugzilla.redhat.com/show_bug.cgi?id=1102633#c4 > > 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 ... > > They are a privacy concern for users who do not adequately review the > data collected from their own systems and ignore the disclaimer text ... > > I'd much rather we kept CVEs and the full security process for > problems ... where a local user can actually cause real harm. Use CVE-2014-3925 for this vulnerability in (only) Red Hat Enterprise Linux 5. The points we considered from our perspective (not necessarily in order of importance) are: - deciding whether an issue is within, or outside, the scope of CVE can depend on practices of other vendors, not the change process that is used by a specific vendor Related to this, Red Hat could decide to not recognize the CVD ID within its change process, A few years ago, Red Hat had been doing this through the NVD Vendor Comments mechanism, for example: see "Official Statement from Red Hat" under http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2010-1130 and https://bugzilla.redhat.com/show_bug.cgi?id=577578 - from the perspective of an arbitrary end user, the https://access.redhat.com/site/solutions/3592 document doesn't really seem to imply that the sosreport data would commonly need to be reviewed, because there is no discussion of potentially sensitive information - the "No space left on device" discussion seems to imply that there's a big file in some cases, and people might reasonably decline to review a big file unless told to do so - on Red Hat Enterprise Linux 5 (only), nobody is telling them to do so - although it's completely true that "An 'attacker' can only benefit from the information if an authorized user makes it available to them," making it available is the common and intended purpose of using the sosreport feature - it's reasonable for an organization to have an internal security policy that no password may be sent to the Technical Support branch of any vendor - in a typical large enterprise, there may be dozens of software products that have "prepare/send debugging information to Technical Support" features, and often (because of the nature of other software products), there is no possibility of sending a password - thus, for Red Hat Enterprise Linux 5 (only), the potential presence of a password, coupled with the lack of warning, seems to sometimes violate reasonable expectations, and some end users would probably make use of a CVE ID to track this - -- CVE assignment team, MITRE CVE Numbering Authority M/S M300 202 Burlington Road, Bedford, MA 01730 USA [ PGP key available through http://cve.mitre.org/cve/request_id.html ] -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.14 (SunOS) iQEcBAEBAgAGBQJTiLMtAAoJEKllVAevmvmsXFAH/jvylFABW8T9eh774Ae7Yeil GPqI/C9P+K0G9S0+VR9dLoAzI5Dcw7qshNUOGdI4Q1PdkcXMfjJYc9/BThsFr1N+ yGD2FM5VwlyfxDPJaG6lXQNXFMVooaCYEKbIOjEZwXe3vhDplG0LswpHdixvPoil e1J8gYR99ljfmbXgitByAgx4e2xSxbXjIW6ARX3iCbTlqm5Qa/S290nS4as/SYPb MkSfgedn4MdVsmXyzaUI/o2RSGQ3tFk8df3ZQDWBhsYF6ukFnGaNgkCOQ4h7U7S+ iqAtPHkp1jvdZbd4ibqPXIN+oQcDyukmfDoSHtiBijwY64BCqD7ctSvQlPFYrA4= =tDOk -----END PGP SIGNATURE-----
Powered by blists - more mailing lists
Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.
Powered by Openwall GNU/*/Linux - Powered by OpenVZ