Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
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.

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.