Add RubyGems's vulnerabilities fixed by 2.6.13.

[sho-h]

Add RubyGems's CVEs fixed by 2.6.13. See http://blog.rubygems.org/2017/08/27/2.6.13-released.html
CVE numbers was referenced from https://www.ruby-lang.org/en/news/2017/08/29/multiple-vulnerabilities-in-rubygems/.

[thbar]

Well needed, thanks!

[reedloden]

Let's update the titles and descriptions for all of these to be aligned to the official CVE descriptions. These are not detailed enough based on our standards.

Use info from https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-0899 for this one, as an example.

[sho-h]

@reedloden like this?

---
library: rubygems
cve: 2017-0899
url: http://blog.rubygems.org/2017/08/27/2.6.13-released.html
title: |
  RubyGems version 2.6.12 and earlier is vulnerable to maliciously crafted gem specifications that include terminal escape characters. Printing the gem specification would execute terminal escape sequences.
date: 2017-08-27
description: |
  RubyGems version 2.6.12 and earlier is vulnerable to maliciously crafted gem specifications that include terminal escape characters. Printing the gem specification would execute terminal escape sequences.
patched_versions:
  - ">= 2.6.13"

Or, description needs more information?

[reedloden]

The title and description are two different things. Title should be pretty short, while description is where most of the information will go. See https://github.com/rubysec/ruby-advisory-db#format for an example.

For this one, perhaps "RubyGems Improper Neutralization of Escape Sequence" as title?

Also, please break the description on 80 chars and continue on next line.

[sho-h]

For this one, perhaps "RubyGems Improper Neutralization of Escape Sequence" as title?

Title should be pretty short, and different from description is OK.
But I want to use announced sentence like An ANSI escape sequence vulnerability., First sentence, ... This is because everyone can find easily.

Also, please break the description on 80 chars and continue on next line.

OK, I'll fix.

[postmodern]

Chiming in a little late here, but you should simply use the title from the original advisory. Description is often the first paragraph or a brief summary of the advisory.

[jrochkind]

It seems important to have this actually listed in the db and available for consumers of feeds, by this point 9 days later? More important than debating what the title should be?

[jrochkind]

(Also maybe someone from rubysec should suggest to rubygems maintenance team and Ruby Together that in the future they ought to have a rubysec entry (or a CVE!!!) prepared before they disclose a vulnerability?)

[jrochkind]

It looks like there are in fact CVE's filed now. Does that make it easier to (automatically?) get it into ruby-advisory-db?

This post is dated 29 August, but I'm pretty sure it didn't have CVE ids in it then, not sure when they were added.
https://www.ruby-lang.org/en/news/2017/08/29/multiple-vulnerabilities-in-rubygems/

https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-0899
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-0900
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-0901
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-0902

If you want rubysec.com to be useful as an alerting service, it would be good to figure out a way to get vulnerabilities listed sooner than two weeks past day 0!

[postmodern]

Went ahead and added the files myself in b2f7745.

[jrochkind]

Thank you @postmodern. Are there any workflow changes that should be considered to increase chances of CVE's getting in ruby-advisory-db sooner than 43 days after 0-day?

[postmodern]

It is the responsibility of upstream to obtain the CVE and publish the initial advisory. Once the initial advisory is published, it's just a matter of converting the CVE and advisory data into the ruby-advisory-db YAML format; also getting the CVSSv2 score from https://nvd.nist.gov/.

[jrochkind]

The CVE ids were referenced in this PR Aug 30. Was other data missing from upstream? Or what else went wrong resulting in 43 day lag?

[postmodern]

Not sure, I'm guessing it was contributor fatigue, where the contributor doesn't have time to meet all of the requirements for merging. Just because someone submits a PR doesn't mean they have infinite time to dedicate towards getting it merged. This isn't a commercial project and everyone (including me) are merely community members volunteering their time.

We might want to look into streamlining the guidelines for PRs. I'm personally in favor of copy/pasting the title/description for each individual CVE.

@jrochkind if you want faster turn-around time for ruby-advisory-db, you can always submit PRs as soon as you see a new big advisory go out.

[jrochkind]

Perhaps a tool that will automatically copy title and description for a CVE from mitre.org into the right format and make a PR? That might be something I would have time to work on, alternately it's a pretty self-contained and straightforward project for one of the people always posting on reddit looking for an open source project to contribute to. :)

I would have submitted a PR for this one, but I looked and saw one already existed, so I didn't. Perhaps I could/should have submitted a duplicate formatted differently?

[postmodern]

@jrochkind I like that idea. Like some script that queries/scrapes MITRE/NVD for some of the information and spits out a half-complete YAML file. There's PR #254 which is a bit more ambitious, but ruby-lang/rails specific.

[jrochkind]

It could hypothetically go beyond spitting out the yaml file, to literally actually making a github PR via github APIs. But yeah, along those lines.

Of course another course of action is encouraging all gem authors in the ruby eco system to prepare a PR here before/as they announce a vulnerability to their gem. That path might be eased by providing a web form somewhere (and/or an API) to generate a PR with the report, rather than requiring someone to do it 'manually' with git/github.