[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date: Wed, 16 Jul 2014 06:43:38 -0400
From: Larry Cashdollar <larry0@...com>
To: "oss-security@...ts.openwall.com" <oss-security@...ts.openwall.com>
Subject: Re: Re: Vulnerability Report for Ruby Gem
kompanee-recipes-0.1.4
> On Jul 16, 2014, at 2:12 AM, cve-assign@...re.org wrote:
>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
>> is it possible that this Gem wasn't ever intended to be used in the
>> context of a Rails application?
>
That is possible yes.
> We haven't seen any response to this yet. (At least from our
> perspective, this is completely fine -- sending a message here
> containing "CVE:Please Assign" doesn't mean that the person is
> required to respond to questions from us.)
>
Sorry I must have missed this in the previous message. My apologies.
> Just to clarify: we are aware of the full set of messages:
>
> Vulnerability Report for Ruby Gem codders-dataset-1.3.2.1
> Vulnerability Report for Ruby Gem cap-strap-0.1.5
> Vulnerability Report for Ruby Gem codders-dataset-1.3.2.1
> Vulnerability Report for Ruby Gem backup-agoddard-3.0.28
> Vulnerability Report for Ruby Gem backup_checksum-3.0.23
> Vulnerability Report for Ruby Gem gyazo-1.0.0
> Vulnerability Report for Ruby Gem VladTheEnterprising-0.2
> Vulnerability Report for Ruby Gem gnms-2.1.1
> Vulnerability Report for Ruby Gem point-cli-0.0.1
> Vulnerability Report for Ruby Gem kompanee-recipes-0.1.4
> Vulnerability Report for Ruby Gem lean-ruport-0.3.8
> Vulnerability Report for Ruby Gem kajam-1.0.3.rc2
> Vulnerability Report for Ruby Gem lawn-login-0.0.7
> Vulnerability Report for Ruby Gem kcapifony-2.1.6
> Vulnerability Report for Ruby Gem karo-2.3.8
> Vulnerability Report for Ruby Gem lynx-0.2.0
> Vulnerability Report for Ruby Gem ciborg-3.0.0
> Vulnerabilities in Ruby Gem brbackup-0.1.1
>
> and we have not yet assigned any CVE IDs. What we think might be the
> best option is to disregard any vulnerability-related observations
> that are qualified with a phrase such as "if this gem is used in the
> context of a rails application." As far as we know, existence of a Gem
> only implies a choice of a packaging mechanism for a piece of Ruby
> code. Existence of a Gem doesn't, as far as we know, imply that the
> author is claiming that the code will operate safely in cases where
> its input arrives from an untrusted source in a way that crosses
> privilege boundaries. This option would result in approximately 20
> CVEs for other types of issues such as:
> - "expose the password to the process table" (e.g., an attacker can
> obtain sensitive information by running the ps program at the
> right time)
>
> - symlink attacks
>
> but no CVEs for issues involving shell metacharacters in variable
> names. The shell-metacharacter CVE IDs could be assigned later if
> anyone identifies a product that actually uses one of the applicable
> Gems unsafely within a Rails application.
>
I understand, this makes sense to me thank you!
-larry
> - --
> 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)
>
> iQEcBAEBAgAGBQJTxhclAAoJEKllVAevmvmscfgH/0QiThSi/wjrMepw3hpuFF/K
> 8+2nHFlPfVEt3AIoATECqshGYIbft3JDMsFgi545jdQ2uzVsETABA+IyhYAoqwmD
> twRLhcCOzQVs9KP4/omdKlOV33m4Xf/blRqSUD6luDSJDdvQtSeQZGDwvkPGmqzb
> eO4JoeF19MZhF5jnDt8F5mukf0TbW4859GtFbEd3jU7dYMEMWCL0UCy71SU/rfoU
> cEuNPp83O1EIJ8bcTS9tz8nILrMEf7n6zbJmtM3cdyD0pHxaiei9gdWZ74XWALcp
> AAsn+SHOSsffZ5htsFJZSqlsyD2dTm3zaEdhzAKn9lqZuPQE0TJ2/5AtNsI0/m8=
> =3GVP
> -----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.
