[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <201405301638.s4UGc1Vj002391@linus.mitre.org>
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.
