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-188.8.131.52 > Vulnerability Report for Ruby Gem cap-strap-0.1.5 > Vulnerability Report for Ruby Gem codders-dataset-184.108.40.206 > 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.
Powered by Openwall GNU/*/Linux - Powered by OpenVZ