What to do about CVE numbers

Posted Oct 4, 2019 22:46 UTC (Fri) by Karellen (subscriber, #67644)
In reply to: What to do about CVE numbers by kleptog
Parent article: What to do about CVE numbers

I wonder, does the system break down if a single commit introduces more than one distinct vulnerability?

What to do about CVE numbers

Posted Oct 5, 2019 1:46 UTC (Sat) by mathstuf (subscriber, #69389) [Link] (5 responses)

Then you have multiple commits saying `Fixes: samehash`. If you have that hash in your tree, you should pull that fixup patch. Even a single issue introduced in a patch may take multiple patches to address anyways, so a many-to-many relationship is probably wanted anyways (think of a patch(set) that plugs a set of holes with one mechanism).

What to do about CVE numbers

Posted Oct 5, 2019 6:52 UTC (Sat) by epa (subscriber, #39769) [Link] (4 responses)

But then you have no way of knowing whether ‘samehash’ has been fully fixed or not. Your tree might have one of the Fixes for it but be missing another one.

Better to have Partly-Fixes: x indicating that one of several bugs is being fixed. In that case you need to check by hand that your tree has all of the fixes for bugs introduced in commit x. Fixes: x on the other hand means that as far as anyone knows this commit is a complete fix and you don’t need to pull any others to deal with bugs from x.

What to do about CVE numbers

Posted Oct 5, 2019 12:03 UTC (Sat) by mathstuf (subscriber, #69389) [Link]

Do you ever have a way of knowing whether all of samehash's bugs have been fully fixed or not? Have you heard about commit unknownbutdangerousbug you have in your tree? Now, "do I have all *known* Fixes: samehash (as of $today) applied?" is a different question. But that is not something I can craft an easy git command line to answer. I suspect that some kind of DB (whether sqlite or a directory of `bugs/$buggyhash/fixed-by/$fixedbyhash` and `bugs/$buggyhash/cherry-picked-as/$backporthash`; this could be populated by reading `cherry-pick -x` messages and Fixes trailers through the history) could be used with some git pipelines to answer these questions.

What to do about CVE numbers

Posted Oct 7, 2019 15:04 UTC (Mon) by smurf (subscriber, #17840) [Link] (1 responses)

You can't have a "Partly-Fixes:" tag without a time machine. Often the partiality of the fix isn't known for some time.

What to do about CVE numbers

Posted Oct 10, 2019 11:23 UTC (Thu) by epa (subscriber, #39769) [Link]

Well, the effectiveness of the fix isn't always known for some time either. Some purported fixes for security holes have turned out to be useless or almost useless. But you can record the best known information at the time the commit was made. That could be in English text, or, for easier parsing, with some kind of header format like Fixes. Just as in English there is a difference between "I believe this is a full fix for the hole introduced in commit abc" and "This fixes the bug from commit abc in some but perhaps not all cases", it would be worthwhile to distinguish the two in the parsable header format.

But in fact, your point illustrates that commit messages are not a great place for this information. In git they are immutable. But knowledge (about which commits fix what bugs) changes over time. So it would perhaps be better as a separate database rather than parsing commit messages.

What to do about CVE numbers

Posted Oct 7, 2019 15:12 UTC (Mon) by geert (subscriber, #98403) [Link]

So it's not the vulnerabilities you're interested in, but the actual fixes.
Fixes can be identified uniquely by the commit ID in mainline. Backported commits in stable trees carry "Upstream commit foo" or "cherry picked from commit foo" lines, so the fixes can be tracked.
This also fixes the issue where a commit introduces multiple bugs, and you have multiple fixes.

What to do about CVE numbers

Posted Oct 10, 2019 6:42 UTC (Thu) by NYKevin (subscriber, #129325) [Link] (1 responses)

I'm more concerned about the reverse: What if you have two or three commits that, individually, are all fine, but in combination, work to create a security hole (e.g. because someone lost track of where the airtight hatchway is supposed to go)? Then which commit hash do you use?

I suppose the simple answer is that you figure out where the airtight hatchway should have been, figure out which commit was on the wrong side of it, and then blame that one. But that's a lot of "figuring out" for what used to be a simple "assign the next number in our preallocated block of numbers" process. You basically have to decide how you are going to fix the bug in order to give it an identifier, which seems very... wrong to me.

The other option is you use git bisect to find the chronologically earliest commit hash where the bug actually repros, regardless of whether that particular commit is "guilty" or not. But then you might be blaming a commit that didn't actually introduce the bug, which would be fine if everyone was using mainline kernels. Lots of people have non-upstreamed patches, however, and they might be misled by such a scheme (if, for example, one of their patches exposes the bug in a different way, and they never pulled the commit that you blamed, they might falsely believe that they don't need the fix).

What to do about CVE numbers

Posted Oct 10, 2019 8:52 UTC (Thu) by geert (subscriber, #98403) [Link]

Hence you use the commit hash of the _fix_ to refer to the bug.

The commit description of the fix can/should still have two or three Fixes tags.
And of course the description should clearly explain what's the underlying issue.