Add support for editing of Ruby language (non-RubyGem) advisories in GHSA database

[jasnow]

Add support for editing of Ruby language (non-RubyGem) advisories in GHSA database.

 * jruby: https://github.com/advisories?query=jruby+ (23)
 * mruby: https://github.com/advisories?query=mruby  (40)
 * ruby-lang: https://github.com/advisories?query=ruby-lang (86)
TOTAL: 143

Looks like their is 5 non-rubygems, non-ruby-language advisories, 
but we can deal with them separately.
 * Unreviewed "ruby: https://github.com/advisories?query=ruby+type%3Aunreviewed (148)

I tried to add missing information to some of them lately and was blocked
by not having an "ECOSYSTEM" value for them.

I propose something similar to "Ruby Languages" or "Rubies" be added
as a possible "ECOSYSTEM" value.

The "PACKAGE" value could be ["ruby-lang", "jruby", "mruby", "rbx/rubinius", "truffleruby", etc].

A good reference for other possible "PACKAGE" values at https://github.com/codicoscepticos/ruby-implementations
Thanks.

[jasnow]

Another reason to do this addition is to support the "Security advisories • Enabled
associated with ruby-related repos, such as: https://github.com/jruby/jruby/security which is currently empty.

[joshbuker]

See also: https://github.com/rubysec/ruby-advisory-db/tree/master/rubies

[oliverchang]

Hey @jasnow, thanks for reaching out!

Adding a "Rubies" ecosystem certainly is an option, but there's a complexity there in that we have to define the set of valid versions for these.

However one of the key motivations for the OSV schema here is ensuring consistency in formatting, while avoiding building a custom registry where we can (instead deferring to existing open source ecosystems).

I also proposed a more generic approach in #94 (comment): thoughts on this as a more general approach that will generalise to all programs?

[oliverchang]

Another alternative is just leveraging the existing GIT metadata fields for identifying these, since it can be hard to define consistent rules for version numbers and naming.

e.g. GSD already does this for the Linux kernel:

https://github.com/cloudsecurityalliance/gsd-database/blob/150921f63987cabdc5e2924a7f255554a3f13bf6/2023/1000xxx/GSD-2023-1000890.json#L46

Would that work for the ruby cases here?

[oliverchang]

More examples here from OSS-Fuzz:

https://github.com/google/oss-fuzz-vulns/blob/main/vulns/mruby/OSV-2020-744.yaml

(Note the "package" field is completely optional, despite these examples having them).

id: OSV-2020-744
summary: Heap-double-free in mrb_default_allocf
details: ...
modified: '2022-04-13T03:04:39.780694Z'
published: '2020-07-04T00:00:01.948828Z'
references:
- type: REPORT
  url: https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=23801
affected:
  ranges:
  - type: GIT
    repo: https://github.com/mruby/mruby
    events:
    - introduced: 9cdf439db52b66447b4e37c61179d54fad6c8f33
    - fixed: 97319697c8f9f6ff27b32589947e1918e3015503
  versions:
  - 2.1.2
  - 2.1.2-rc
  - 2.1.2-rc2
  ecosystem_specific:
    severity: HIGH

[joshbuker]

I wonder if @reedloden or @postmodern would have any thoughts on the best way to identify Ruby binaries?

[jasnow]

The focus of this specific issue is no one can currently edit the "unreviewed" non-RubyGems advisories
in the GHSA database because there is no appropriate value to select under "Ecosystem".

Here is my first try to ask for GHSA to help me help them.
github/advisory-database#1796

[jasnow]

OSV-2020-744

Is there any linkage to a CVE number for these records?

[jasnow]

I wonder if @reedloden or @postmodern would have any thoughts on the best way to identify Ruby binaries?

My guess at an answer would be:

Given ["cve-", "ghsa-", "osvdb-"] numbers as linkage and
    GHSA-Ecosystem                        RAD
.........................................................................................
    RubyGems                     then directory would be "gems" and "gems:" field would be  <gem-name>
    NEWRUBYLANGS                 then directory would be "rubies" and "engine:" field would be  <lang-name>
    
Else currently unsupported in RAD (ruby-advisory-db)

More details at: https://github.com/rubysec/ruby-advisory-db/blob/master/lib/github_advisory_sync.rb

[postmodern]

@joshbuker From reading the original issue, I feel like "Ecosystem" is being used to describe things such as npmjs.com and rubygems.org. Software such as ruby, mruby, jruby, rbenv, etc, should be considered standalone pieces of software that can be installed directly or via apt/brew/etc. I feel like the whole point of "Ecosystem" is really to help distinguish between an npm package from a non-npm package, if they happen to share the same name. Therefor, I think "Ecosystem" should not be a required by GHSA for MRI/CRuby, jruby, truffleruby, mruby advisories when suggesting edits.

mruby might be an in-between case, since while it does come with it's own set of builtin mrbgems which are compiled into the resulting mruby static library, you can also add 3rd party mrbgems which there are a few. So maybe an additional ecosystem of mrbgems as opposed to rubygems might be necessary for advisories for specific mrbgems libraries (read: not mruby itself).

[kurtseifried]

This also relates to what is our upstream policy?

CloudSecurityAlliance/gsd-tools#178

E.g. should we extend the list of ecosystems to provide better coverage, ideally getting it into OSV, but forking it if needed?

[joshbuker]

@postmodern

I feel like the whole point of "Ecosystem" is really to help distinguish between an npm package from a non-npm package, if they happen to share the same name.

This is a good point; Ecosystem is more for avoiding namespace issues than anything else.

Is there a way we could represent what ruby-advisory-database does with its custom schema in OSV? Ideally, in a way that scales for other ecosystem equivalents as well.

Perhaps an Ecosystem of Standalone or Binary would be appropriate? And the package name could be either jruby and/or the direct URL to the project/git repo, for example.

Mostly thinking aloud.

[kurtseifried]

So my understanding of Ecosystem is that it is used to separate namespaces (e.g. npm and Wordpress and perl all have packages called "Security" and so on). So "Binary" doesn't adequately represent something, e.g. it's just a name, or? Some things that are unique, AND meta (including many different things):

DNS - put primary domain for that thing, e.g. "ruby-lang.org"
GitHub - for open source, e.g. "ruby" or "ruby/ruby" (to represent "https://github.com/ruby/ruby")

[oliverchang]

Indeed -- we are defining namespaces here, ideally delegating to existing well defined namespaces where possible. We've picked canonical ecosystems for these where possible to avoid overlap and inconsistencies.

We have shied away from catchalls like "generic", "standalone", "binary", because they're impossible to guarantee consistency for. e.g. is it "node", or "Node", or "node.js", or "Node.js" or some other variation?

For this issue specifically, I think there are two main things to unpack:

• How do we represent software that doesn't really belong to a canonical ecosystem? One approach is to leverage git/VCS URLs (which I don't see any objections against?). @postmodern -- you mentioned in Add support for editing of Ruby language (non-RubyGem) advisories in GHSA database #123 (comment) that "Ecosystem" should be optional. I totally agree, and I believe this is already what my example in Add support for editing of Ruby language (non-RubyGem) advisories in GHSA database #123 (comment) shows -- there is no specified package, just a git repo to identify the affected ranges. There may just need to be a small tweak here to support cases where we don't know the actual GIT hashes.

• How do we enable advisory editing on GitHub for these? I this would fall on GitHub once we have an agreement on how to identify these. CC @darakian @KateCatlin we've discussed this in the past. Thoughts on using git/other VCS URLs as the mechanism for identifying them?

[joshbuker]

Using a URI to identify these seems reasonably sane and avoids the consistency issue.

Should this live exclusively in the ranges, or should it be replicated to the package as an alternative to the name/ecosystem combo?

I could see it being worth doing that just so it's explicit and easier to parse if you're looking for the package to identify whether you care about an ID without needing to enumerate the ranges as well. It also solves the problem of "did you forget?" - either you have name/ecosystem, OR you have uri. Also avoids the issue where you know what's affected but might not know any version ranges yet.

Using the above example:

id: OSV-2020-744
summary: Heap-double-free in mrb_default_allocf
details: ...
modified: '2022-04-13T03:04:39.780694Z'
published: '2020-07-04T00:00:01.948828Z'
references:
- type: REPORT
  url: https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=23801
affected:
  package:
    uri: https://github.com/mruby/mruby
  ranges:
  - type: GIT
    repo: https://github.com/mruby/mruby
    events:
    - introduced: 9cdf439db52b66447b4e37c61179d54fad6c8f33
    - fixed: 97319697c8f9f6ff27b32589947e1918e3015503
  versions:
  - 2.1.2
  - 2.1.2-rc
  - 2.1.2-rc2
  ecosystem_specific:
    severity: HIGH

[jasnow]

OSV-2020-744

Is there any linkage to a CVE number for these records?

Also CVSS_V# field is missing.

[kurtseifried]

OSV-2020-744

Is there any linkage to a CVE number for these records?

Also CVSS_V# field is missing.

To be clear that is not our data. You'll want to talk to upstream, this data is originally from https://github.com/google/oss-fuzz-vulns/blob/main/vulns/mruby/OSV-2020-744.yaml and you can file issues there.

As per our discussion CloudSecurityAlliance/gsd-tools#178 the GSD is basically going with "upstream first" so please try to work with them, if it fails then we can talk about modifying/updating the data on our end as needed.

[darakian]

How do we enable advisory editing on GitHub for these? I this would fall on GitHub once we have an agreement on how to identify these. We've discussed this in the past. Thoughts on using git/other VCS URLs as the mechanism for identifying them?

The issue is identifying an appropriate ecosystem I think. Doing a source rather than package based ecosystem could certainly be an interesting thing to explore (git/vcs/whatever), but a complication I'd like to bring up is that build systems can affect any given vulnerability in a deployed binary.

ex. CVE-2021-3177 for the python runtime which leads to a crash on redhat releases and to remote code execution on debian.

@jasnow and I discussed some of this over here github/advisory-database#1796 and tl;dr we do not have the capacity to handle this sort of request.

[kurtseifried]

DNS - put primary domain for that thing, e.g. "ruby-lang.org"

Actually this is wrong, it should be:

URL - a URL that identifies this project, e.g. ruby-lang.org, https://ruby-lang.org, https://github.com/ruby/ruby

this is not ideal as it requires mapping and normalization in the long term, but at least it lets us map things and provide the data which is better than no entry at all.

[jasnow]

Just received this:

We've just released Ruby 3.2.2, 3.1.4, 3.0.6 and 2.7.8. How to download and details:

* [Ruby 3.2.2 Released](https://www.ruby-lang.org/en/news/2023/03/30/ruby-3-2-2-released/)
* [Ruby 3.1.4 Released](https://www.ruby-lang.org/en/news/2023/03/30/ruby-3-1-4-released/)
* [Ruby 3.0.6 Released](https://www.ruby-lang.org/en/news/2023/03/30/ruby-3-0-6-released/)
* [Ruby 2.7.8 Released](https://www.ruby-lang.org/en/news/2023/03/30/ruby-2-7-8-released/)

They includes secuirty fixes.
You can check details:

* [CVE-2023-28755: ReDoS vulnerability in URI](https://www.ruby-lang.org/en/news/2023/03/28/redos-in-uri-cve-2023-28755/)
* [CVE-2023-28756: ReDoS vulnerability in Time](https://www.ruby-lang.org/en/news/2023/03/30/redos-in-time-cve-2023-28756/)

We strongly recommend to upgrade your ruby installations as soon as possible.

Note:
After this release, Ruby 2.7 reaches EOL. In other words, this is expected to be the last release of Ruby 2.7 series.
And also, we end the normal maintenance phase of Ruby 3.0, and Ruby 3.0 enters the security maintenance phase.
Therefore, we recommend to start migration to Ruby 3.2 or 3.1.

[jasnow]

Here's the release of the new Ruby parser: https://github.com/Shopify/ruby-lsp

[jasnow]

This issue is not progressing so I am going to close it.