Data quality issue with 2016/2017 Ruby CVEs
The CVE ID CVE-2016-2336 CVE-2016-2337 CVE-2016-2338 CVE-2016-2339 CVE-2017-6181 CVE-2017-11465 CVE-2017-17790
Describe the data quality issue observed osv.dev marks these as "no fix available" and does not list any git tags
Suggested changes to record Git tags are listed and osv.dev is able to detect the CVE as fixed.
The exact cause of the problem is unfortunately unclear to me, otherwise I would suggest something more precise.
Given the "fixed" commits just point to the release tag commit, whatever produced the commit range did originally have the correct list of affected versions.
Additional context NIST CPEs list the versions affected correctly.
:sparkles: Thank you for your interest in OSV.dev's data quality! :sparkles:
Please review our FAQ entry on how to most efficiently have this addressed.
Preliminary investigation of CVE-2016-2336:
[CVE-2016-2336]: Pre-references, derived ["https://github.com/ruby/ruby"] for "ruby-lang" "ruby" using cache
[CVE-2016-2336]: Pre-references, derived ["https://github.com/ruby/ruby"] for "ruby-lang" "ruby" using cache
[CVE-2016-2336]: Summary: [CPEs=2 AppCPEs=2 DerivedRepos=1]
[CVE-2016-2336]: Repos: []string{"https://github.com/ruby/ruby"}
[CVE-2016-2336]: Trying to convert version tags {AffectedCommits:[] AffectedVersions:[{Introduced: Fixed: LastAffected:2.2.2} {Introduced: Fixed: LastAffected:2.3.0}]} to commits using [https://github.com/ruby/ruby]
[CVE-2016-2336]: Attempting version resolution for {Introduced: Fixed: LastAffected:2.2.2} using "https://github.com/ruby/ruby"
[CVE-2016-2336]: Successfully derived {Repo:https://github.com/ruby/ruby Introduced: Fixed: Limit: LastAffected:a9721a259665149b1b9ff0beabcf5f8dc0136120} for last_affected version "2.2.2"
[CVE-2016-2336]: Attempting version resolution for {Introduced: Fixed: LastAffected:2.3.0} using "https://github.com/ruby/ruby"
[CVE-2016-2336]: Successfully derived {Repo:https://github.com/ruby/ruby Introduced: Fixed: Limit: LastAffected:d40ea2afa6ff5a6e5befcf342fb7b6dc58796b20} for last_affected version "2.3.0"
The commits definitely exist for the version tags:
$ git ls-remote -t https://github.com/ruby/ruby | grep -E "(d40ea2afa6ff5a6e5befcf342fb7b6dc58796b20|a9721a259665149b1b9ff0beabcf5f8dc0136120)"
a9721a259665149b1b9ff0beabcf5f8dc0136120 refs/tags/v2_2_2
d40ea2afa6ff5a6e5befcf342fb7b6dc58796b20 refs/tags/v2_3_0
Yet analysis doesn't find the commits any branch, and https://github.com/ruby/ruby/commit/a9721a259665149b1b9ff0beabcf5f8dc0136120 and https://github.com/ruby/ruby/commit/d40ea2afa6ff5a6e5befcf342fb7b6dc58796b20 are not reported as being in the repo (which aligns with the behaviour from analysis)
The commits are definitely there:
$ git clone -q https://github.com/ruby/ruby
$ cd ruby
$ git show a9721a259665149b1b9ff0beabcf5f8dc0136120
commit a9721a259665149b1b9ff0beabcf5f8dc0136120 (tag: v2_2_2)
Author: nagachika <[email protected]>
Date: Mon Apr 13 13:19:16 2015 +0000
add tag v2_2_2
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/tags/v2_2_2@50295 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
$ git show d40ea2afa6ff5a6e5befcf342fb7b6dc58796b20
commit d40ea2afa6ff5a6e5befcf342fb7b6dc58796b20 (tag: v2_3_0)
Author: NARUSE, Yui <[email protected]>
Date: Thu Dec 24 16:35:48 2015 +0000
add tag v2_3_0
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/tags/v2_3_0@53290 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
$ git name-rev d40ea2afa6ff5a6e5befcf342fb7b6dc58796b20
d40ea2afa6ff5a6e5befcf342fb7b6dc58796b20 tags/v2_3_0
My Git internals fu isn't particularly strong, but relying on https://stackoverflow.com/questions/2706797/finding-what-branch-a-git-commit-came-from, for these two commits I get:
$ git branch -a --contains d40ea2afa6ff5a6e5befcf342fb7b6dc58796b20
$ git reflog show --all | grep d40ea2afa6ff5a6e5befcf342fb7b6dc58796b20
$ git log --merges d40ea2afa6ff5a6e5befcf342fb7b6dc58796b20
commit 4334bb87f918e8f39051d7c80ca1558205762d60
Merge: 77ac4a50f1 f15ac6c8d6
Author: Nobuyoshi Nakada <[email protected]>
Date: Thu Oct 8 01:44:51 2015 +0000
node.c: D_FIELD_HEADER
* node.c (D_FIELD_HEADER): concatenate sequential strings.
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@52078 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
commit d0191f54f437e34600d48b9aa970bad6da506395
Merge: d42d4c1e23 59991b6ac5
Author: svn[bot] <[email protected]>
Date: Tue Sep 8 22:47:16 2015 +0000
* properties.
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@51803 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
commit e0934947d3b5403ee51b0809c4b6c139eb99500a
Merge: a8b34c375d 843019f4a0
Author: Kazuki Tanaka <[email protected]>
Date: Sat Jun 6 20:35:35 2015 +0000
* lib/cmath.rb: [DOC] Documentation improvements [ci skip]
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@50795 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
commit ff3322560e5e54863f959d3793df1f37a14f35d8
Merge: daa18e5074 fadd0160d0
Author: svn[bot] <[email protected]>
Date: Sun May 3 18:11:41 2015 +0000
* 2015-05-04
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@50426 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
# I'm pretty sure this is what our analysis code does
$ git branch -a --contains a9721a259665149b1b9ff0beabcf5f8dc0136120
$ git reflog show --all | grep a9721a259665149b1b9ff0beabcf5f8dc0136120
$ git log --merges a9721a259665149b1b9ff0beabcf5f8dc0136120
commit fe0ab0517a6cc71b06f0fe1b074f3f2e8e213862
Merge: 364be8e7c2 7632a82d57
Author: NARUSE, Yui <[email protected]>
Date: Thu Dec 25 08:42:33 2014 +0000
merge revision(s) 48993:
* ext/io/console/console.c (console_dev): send the given arguments
to the opened console. as a special case, do nothing if :close
is given.
* test/lib/leakchecker.rb (LeakChecker#check_fd_leak): close if
console.
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/branches/ruby_2_2@49004 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
commit 31409cbf7f56d72df0049306a2345c6f40f08ed6
Merge: f5dbd9dbec f0806c4863
Author: NARUSE, Yui <[email protected]>
Date: Thu Dec 25 07:11:34 2014 +0000
Release branch of Ruby 2.2
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/branches/ruby_2_2@48992 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
$ git name-rev a9721a259665149b1b9ff0beabcf5f8dc0136120
a9721a259665149b1b9ff0beabcf5f8dc0136120 tags/v2_2_2
$ git log a9721a259665149b1b9ff0beabcf5f8dc0136120..HEAD --ancestry-path --merges
I need to understand how to interpret what git log --merges is telling me...
Ah yeah, the case of detached tags. It is unfortunately legal to tag outside of any branch.
In Ruby's case, it was simply because of the way it's imported from svn and in svn tags were completely separate to branches. For those you can probably assume that empty commits won't have an impact on the vulnerability as they contain no code changes and so can take the first non-empty parent commit when searching for paths between commits, which for Ruby will lie on a branch.
In other cases however, detached tags can contain code changes as an intentional part of the release process, such as https://github.com/swiftlang/swift/commit/2194dc2f736d224bf6f2bb1b4573af55da138cce from CVE-2020-9861. So it's somewhat awkward to generalise.
Playing around with a technique while discussing with a colleague recently:
$ git branch -r --contains a9721a259665149b1b9ff0beabcf5f8dc0136120
$ git merge-base master a9721a259665149b1b9ff0beabcf5f8dc0136120
7632a82d5750b7908bd173eda3268ecb0855b934
$ git branch -r --contains 7632a82d5750b7908bd173eda3268ecb0855b934
origin/HEAD -> origin/master
origin/master
origin/ruby_2_2
origin/ruby_2_3
origin/ruby_2_4
origin/ruby_2_5
origin/ruby_2_6
origin/ruby_2_7
origin/ruby_3_0
origin/ruby_3_1
origin/ruby_3_2
origin/ruby_3_3
Looking at 7632a82d5750b7908bd173eda3268ecb0855b934, it looks like the fix commit itself, so it would be incorrect to use this as the substitute for existing last_affected commit.
I note that all of the CVEs mentioned are now showing a last_affected commit, so I think this can be closed