Re: Re: Vulnerability Report for Ruby Gem kompanee-recipes-0.1.4

[Larry Cashdollar <larry0 () me com>]

> On Jul 16, 2014, at 2:12 AM, cve-assign () mitre 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-----