LWN: Comments on "What to do about CVE numbers"

What to do about CVE numbers

Aissen — Tue, 22 Oct 2019 08:43:08 +0000

That's not my understanding at all, I think there might be a quid pro quo in the article. I think Greg wants to identify not vulnerabilities as they are introduced, but as they are *fixed*. So the CIDs are in fact the patches that fix a vulnerability. It helps everyone know whether they are running a patched system or not, and it helps backporters know what to apply.

It seems this script does exactly that:

https://github.com/gregkh/gregkh-linux/blob/master/script...

What to do about CVE numbers

jberkus — Mon, 21 Oct 2019 18:55:19 +0000

As a warning, Red Hat already tried to launch a distributed replacement for CVE, and gave it up after a year because the participation wasn't there:

https://github.com/distributedweaknessfiling/

https://twitter.com/kurtseifried/status/1103858442479910913

Not sure how K-H is going to make it work better. Turns out that the main problem with the CVE system is the submitters.

What to do about CVE numbers

msmeissn — Thu, 10 Oct 2019 14:19:49 +0000

Some comments:

- Spectre variant 1 / single CVE

The Spectre 1 CVE covers actually problem of the CPU, and not the kernel. The kernel has mitigations for it.

I would consider Spectre 1 even more a "bugclass" (like "format string exploit"), so every mitigating fix would need to get its own CVE (which now would be 50-100 or more for Spectre v1 alone).

Same goes for the other Spectre flavor CVEs, like Bounds Check Bypass Store ...

- Giving government bodies like Mitre ahead knowledge of CVE.

For allocation of a CVE it is not necessary to hand out any information, depending on the CNA. Mitre as the Root CNA , or any CNA able to allocate Kernel issues could hand out a blank CVE without getting details of the issue.

- Misallocation by Mitre

If there would be a specific Linux kernel CNA, operated by more knowledgeable people, these could take decisions on what issues get what CVEs.
So far Mitre does it best effort, and as GregKH states does "too much" occasionaly.
Mitre for instance blocks any CVE requests for drivers/staging/ already.

This would need at least a fulltime position, or even more.

What to do about CVE numbers

epa — Thu, 10 Oct 2019 11:23:45 +0000

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

geert — Thu, 10 Oct 2019 08:52:18 +0000

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.

What to do about CVE numbers

NYKevin — Thu, 10 Oct 2019 06:42:57 +0000

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).

Getting code upstream

IanKelling — Tue, 08 Oct 2019 12:04:16 +0000

> I think you've read something into the article that wasn't there. Nobody thinks that upstreaming is going to rescue all of the unsupported devices out there.

Corbet, good to know that wasn't intended, but it's clearly there. You wrote:

> The final question was about users who are stuck with vendor kernels that will not be upgraded; what are they to do? Kroah-Hartman responded that this is a real problem. Those vendors typically add about three-million lines of code to their kernels, so they are shipping a "Linux-like system". The answer is to force vendors to get their code upstream; to do that, customers have to push back.

So, "the answer" is very clearly a reference to "users who are stuck", present tense stuck, but your saying, of course thats not what you really meant, only preventing it for future users, but you need to sayyy that if its what you mean. Its like saying "What about the problem that there are a million or so species that will go extinct due to current carbon levels. The answer is to decrease our carbon emissions." But of course, that is not an answer to the stated problem since it won't change existing carbon levels or their effects. It's an answer to prevent the next million, but you have to say that, or else people will read what you wrote literally.

Talk video

hupstream — Tue, 08 Oct 2019 11:50:13 +0000

Here is the link for the video of this talk during Kernel Recipes 2019: https://youtu.be/HeeoTE9jLjM

What to do about CVE numbers

nim-nim — Tue, 08 Oct 2019 08:00:49 +0000

Age [of a CVE] is not a perfect indicator but the best is the enemy of good and the IT industry in general is in such a woeful state it’s more than good enough to highlight companies that don’t really care about (product) bugfixing once a product is out of the door. Including companies which core business is IT security BTW.

What to do about CVE numbers

IanKelling — Mon, 07 Oct 2019 22:43:09 +0000

> allows regular users to trust their device

Regular users have no idea about evil maids or rom signature verification, but your argument is that apple should be completely in charge, and I don't think regular users trust apple completely. And it is not necessary to trust only apple to get all those security benefits. Apple could securely let users modify the software on their devices using the same kind of cryptography they currently use to only allow themselves to modify the software.

What to do about CVE numbers

IanKelling — Mon, 07 Oct 2019 21:53:21 +0000

> allows regular users to trust their device

No, if the only one who can modify it is apple, it means users are trusting apple, and its not "their device", and it is not necessary to trust only apple to get all those security benefits. Apple could securely let users modify the software on their devices. It would mean using something like a tpm with unmodifiable firmware to tell the user which keys the device trusts to sign the software.

What to do about CVE numbers

geert — Mon, 07 Oct 2019 15:12:59 +0000

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

smurf — Mon, 07 Oct 2019 15:04:44 +0000

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

Getting code upstream

corbet — Mon, 07 Oct 2019 13:55:11 +0000

I think you've read something into the article that wasn't there. Nobody thinks that upstreaming is going to rescue all of the unsupported devices out there. Nothing is going to fix those. The objective is to stop creating such devices in the future.

What to do about CVE numbers

imMute — Mon, 07 Oct 2019 13:50:45 +0000

>so if unit A is still fixing years old CVes while unit B is fixing last week’s CVEs, you know which one has a problem

I'm not sure I do... Age [of a CVE] is not the only indicator of priority. Maybe Unit A has fixed all the "critical" CVEs and are now working their way through the "probably not even exploitable" CVEs from years ago.

What to do about CVE numbers

jem — Mon, 07 Oct 2019 11:25:55 +0000

When a consumer brings home a smart TV and connects it to the home network, why wouldn't it be connected directly to the internet?

What to do about CVE numbers

IanKelling — Mon, 07 Oct 2019 10:54:00 +0000

I agree the existing ones won't get updates. The article states otherwise, which is what I quoted from the article, and my complaint is that it makes no sense and I expect better from LWN.

What to do about CVE numbers

pomac — Mon, 07 Oct 2019 09:20:25 +0000

Connected directly to the internet? I think not.

What to do about CVE numbers

pomac — Mon, 07 Oct 2019 09:19:32 +0000

The major difference is: 2.5 billion devices connected to the internet.

If you connect the most important control machine for a nuclear power plant to the internet without firewalls... well.. you'll end up as vapor.

What to do about CVE numbers

pomac — Mon, 07 Oct 2019 09:18:06 +0000

Usually the SOC vendor is the limiting factor for which kernel you can use - so usually Qualcomm.

What to do about CVE numbers

NAR — Mon, 07 Oct 2019 08:05:18 +0000

Distributing exploits is one indirect but effective way to help customers push back [ project managers ].

I think that's still not enough. A worm is required that globally bricks devices (or at least changes background images to something like "You're owned!") - the mere possibility that a phone can be remotely cracked will not scare enough people.

What to do about CVE numbers

nim-nim — Mon, 07 Oct 2019 07:22:00 +0000

CVEs are a wonderful tool to measure the robustness and efficiency of your software supply chain.

S* happens, and software has bugs. So you *will* get CVEs. If your software suppliers are unable to report the CVEs fixed in each delivery, they are *lying* (or incompetent suppliers that should be replaced). If they *are* reporting the fixed CVEs, you get a direct measure of the whole software supply bugfixing velocity (so if unit A is still fixing years old CVes while unit B is fixing last week’s CVEs, you know which one has a problem).

I’m not sure if people realize how much that helps cutting the crap and avoiding kilometers of powerpoint obfuscation.

What to do about CVE numbers

roc — Mon, 07 Oct 2019 04:04:28 +0000

> "a bug is a bug"

It's entirely rational for some kernel consumers to have a risk budget and to want to focus that risk budget on security bugs. Intentionally frustrating those consumers by refusing to identify bugs with known security implications is sheer bloodymindedness at this point. It contributes to backporting failures like the recent Android (not) zero-day: https://arstechnica.com/information-technology/2019/10/at...

What to do about CVE numbers

marcH — Sun, 06 Oct 2019 18:22:07 +0000

> All of these fixes are handled in the same way; "a bug is a bug", he said.

Probably the biggest difference between a security bug versus not: testing the former requires complex tools and unexpected sequences.

Now if tests for normal bugs are lacking in the first place then it's of course difficult to see that difference.

What to do about CVE numbers

marcH — Sun, 06 Oct 2019 18:08:54 +0000

> That would work but you could also generate a random number and call it a "Change ID" for the same effect. Oh wait, that's what Gerrit uses and we can't do that...

No you can't because it has been Not Invented Here, so "it's tied to Gerrit" and other lies have already been spread https://lwn.net/Articles/797613/

What to do about CVE numbers

marcH — Sun, 06 Oct 2019 17:58:54 +0000

Distributing exploits is one indirect but effective way to help customers push back [ project managers ].

Most people buying "smart" phone still believe they buy a piece of hardware. They haven't realized yet they buy millions of lines of crappy and rushed out code + *maybe* some firefighting service that goes with it. The sooner and... harder they understand it the better.

What to do about CVE numbers

excors — Sun, 06 Oct 2019 00:24:07 +0000

> And the ability to lock down the devices is something *all* vendors very much want.

As an example of why it's useful, see the recent iOS boot ROM vulnerability which allows an attacker with physical access to run arbitrary code on the device at the CPU's highest privilege level.

Because the device is locked down (i.e. there is a secure boot chain that starts with Apple's public key stored in ROM, and the boot ROM verifies the bootloader which verifies the kernel which verifies the system which verifies the apps) it can't be turned into a persistent exploit - the device will always be in a good state (or bricked) after restarting. That gives reasonable protection again evil maid attacks (e.g. when someone tries to install malware in the factory or during delivery or in border security checks (remember to restart your device when you get it back), or before selling a device as second-hand, etc) and allows regular users to trust their device. It's still a bad vulnerability but it would have been much worse without a locked bootloader.

> Look on how Huawei first promised to unlock bootloader on Mate 30 Pro and then decided not to do that, in the end.

I assume most people wanted an unlocked bootloader so they could sideload Google apps onto it (which aren't installed by default because of US trade restrictions)? Huawei found a different (worse) method, by allowing certain third-party apps approved and signed by Huawei to install other apps (like Google's) with system-level privileges: https://arstechnica.com/gadgets/2019/10/the-internets-hor...

What to do about CVE numbers

khim — Sat, 05 Oct 2019 23:06:27 +0000

Existing ones would be locked and unmaintained. Period. Nobody could force their makers to do anything - and they very much don't want to do anything so nothing would happen.

Interest in any device for any maker goes to precisely zero once a device is sold. Even security updates and other such things are only ever done to make sure new batches of the same hardware could be sold.

What would happen to *future* device, on the other hand, could be meaningfully influenced if we are smart: people haven't paid for them yet, thus hardware makers could be convinced to do something to make that happen.

Article just comes from "what could we *actually* do" POV, not from "what could we do in the imaginary world filled with fairies and unicorns" POV.

What to do about CVE numbers

khim — Sat, 05 Oct 2019 23:00:08 +0000

I don't know what kinda of alternate reality you imagine, but in *our* reality an attempt to switch Linux over to GPLv3 would have just resulted in Zircon or some other BSD or Apache-licensed kernel been the default instead of Linux.

If Google would try to push for that then vendors would just switch to some other AOSP-based fork of Android.

I think you vastly overestimate influence of Google on Android ecosystem: sure, if any *one* vendor does not like something - then Google could ignore it. But if *all* vendors want something - they would get that.

And the ability to lock down the devices is something *all* vendors very much want. Look on how Huawei first promised to unlock bootloader on Mate 30 Pro and then decided not to do that, in the end.

What to do about CVE numbers

scientes — Sat, 05 Oct 2019 22:39:13 +0000

> During a Senate hearing on Meltdown and Spectre, Senators pressed the NVD representatives on why the Senate had not been notified about the vulnerabilities ahead of time, for example.

Maybe because congress is completely incompetent and unaccountable? Just maybe.

What to do about CVE numbers

IanKelling — Sat, 05 Oct 2019 17:24:36 +0000

"The final question was about users who are stuck with vendor kernels that will not be upgraded; what are they to do?" ... "The answer is to force vendors to get their code upstream. " It can help with future devices, but not existing ones. Submit those 3 million lines of code, most requires massive changes, some will never be accepted, and at some point in this process, the phone vendor is going to suddenly update their old devices they never planned on updating? No. We all want code upstreamed, but let's get articles that make sense.

What to do about CVE numbers

IanKelling — Sat, 05 Oct 2019 16:48:42 +0000

This is a very google centric view of things. "customers have to push back", but, of course the customer is Sony, not the people buying phones, who are just the unwashed 2.5 billion serfs.

In an alternative reality, users would be running a gpv3 kernel, and google gives users the option to switch to a secure kernel by clicking a button or two and then rebooting, similar to how they got most desktop users to switch browsers. But, with google's proprietary leverage, they could do something similar: require vendors to ship phones with all free software at the kernel and below. Note, shipped free software means no cryptographic lockdown.

What to do about CVE numbers

mathstuf — Sat, 05 Oct 2019 12:03:31 +0000

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

yhchen — Sat, 05 Oct 2019 11:33:57 +0000

Does the statement that CVE is useless apply only to Linux kernel? I think it's still a valuable resource for software that doesn't update as frequently as the kernel?

Commit ID / Git Kernel Hash as a security id

dottedmag — Sat, 05 Oct 2019 09:51:35 +0000

Maintained by Federated Security Brigade.

Commit ID / Git Kernel Hash as a security id

amacater — Sat, 05 Oct 2019 09:21:36 +0000

That could go well with the Kernel Gross Bugcount - itself descended from the Obvious Greatest Problems (with) Unix

Commit ID / Git Kernel Hash as a security id

Cyberax — Sat, 05 Oct 2019 08:51:02 +0000

Maybe NKVD: National Kernel Vulnerability Database?

Commit ID / Git Kernel Hash as a security id

adamg — Sat, 05 Oct 2019 07:25:52 +0000

Here I wonder. We probably still want to track if security fixes are applied to stable kernels.
This will mean we will have multiple Commit IDs to a single security vulnerability.

Comparing this to CVE (which may contain links to multiple git hashes) I think the latter is better.

Perhaps it might be better to split from NVD and create LKNVD (Linux Kernel National Vulerability Database)?

What to do about CVE numbers

epa — Sat, 05 Oct 2019 06:52:42 +0000

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

tlamp — Sat, 05 Oct 2019 06:34:13 +0000

But what about fixes for grave issue you did not introduced in your tree?
E.g., Spectre, Meltdown, ..., where not introduced by a single change - I mean maybe the one adding support for the respective vulnerable hardware, but that can't hardly count?

But agree very much on the statement that CVE are overused and have seldom any value now.