[2/28/2024 Update: A bit more info added at end regarding “almost any bug might exploitable“.]
MITRE announced that The Linux Kernel Organization (Kernel.org, hereafter referred to as ‘Linux’) was officially a CVE Numbering Authority (CNA) on February 13, 2024 and via the CVE web site, that their advisories would be posted here. That means they now have the ability to assign CVE IDs without going through MITRE or another CNA. Several prominent members in the industry have already voiced concerns about this including Chompie, Ian Coldwater, Brad Spengler, and Katie Moussouris. All of them, and more, are exactly right about this development and what it will mean for the CVE ecosystem. While digging a bit for these comments, I found that Brad Spengler recalls exactly what I do, which isn’t surprising, and knows exactly what I mean that this problem was foretold in 2022. I’ll get to that at the end, but a bit of commentary, history, and information before that.
ID All the Things!
Since becoming a CNA, Linux has posted documentation around their process of assigning CVE IDs. Ironically, the first line of this page says that CVE was “developed as an unambiguous way to identify, define, and catalog publicly disclosed security vulnerabilities.” The bold emphasis is mine, pointing out exactly what the original purpose of CVE was. They get it! Right up until the end of the fifth paragraph which has the big warning sign: “This explains the seemingly large number of CVEs that are issued by the Linux kernel team.” This comes after saying that “almost any bug might be exploitable [..] but the possibility of exploitation is often not evident when the bug is fixed”
It is trivially debatable that not “almost any bug” might be exploitable as they say, even in the Linux world. One thing that must remain in mind at every part of the research, disclosure, and triage stage of this is what constitutes a vulnerability. The most succinct definition I have used for a long time is a bug that “allows the crossing of privilege boundaries“. That alone will rule out a substantial number of issues where the functionality in question is only invoked by a privileged account (e.g. root) and cannot be reached by the userland, or functionality is invoked by userland without a mechanism to elevate privileges. Yes, if part of the issue is that if the code can be reached by userland and triggered with higher or cross-user privileges, that may become a vulnerability. But there needs to be some hint or evidence of that, not this generic assertion that any bug might, someday, in some circumstance, when the moon is full, and the squirrels square dance, that it can then be exploited.
Taking the approach of “all bugs matter” is good; they do. But it does not mean that they matter in the security context of receiving a CVE ID. This is simply counterproductive to Linux kernel stakeholders and as Greg Kroah-Hartman, a Linux maintainer, will tell you, “the kernel lives at a different layer than most other software projects, and our user base is one of the widest and most varied compared to almost all other software projects“. He is absolutely, 100% correct in this! It also squarely explains why this approach is so poorly thought out and will have negative repercussions and serious consequences. The fallout of this approach will directly and indirectly affect more people in the long run than Microsoft, Oracle, IBM, and Cisco vulnerabilities combined. Linux is used in a ridiculous number of embedded systems, IoT devices, and servers. It’s important to note that Kroah-Hartman, in a prior talk about CVE, prefaced a conversation on CVE assignments with three ridiculous assertions that are all wrong.
Worse, Linux is very clear that this process is not intuitive and is done outside of their own established vulnerability reporting channels. So their CVE ID assignment process bypasses that completely:
The Linux kernel developer team does have the ability to assign CVEs for potential Linux kernel security issues. This assignment is independent of the normal Linux kernel security bug reporting process.
CVE Disputes & Resolution
The approach taken by Linux to “ID all the things” does have a dispute system. However, it is one that puts the initial burden on the outside world. The Linux CNA documentation reads:
The authority to dispute or modify an assigned CVE for a specific kernel change lies solely with the maintainers of the relevant subsystem affected. This principle ensures a high degree of accuracy and accountability in vulnerability reporting. Only those individuals with deep expertise and intimate knowledge of the subsystem can effectively assess the validity and scope of a reported vulnerability and determine its appropriate CVE designation. Any attempt to modify or dispute a CVE outside of this designated authority could lead to confusion, inaccurate reporting, and ultimately, compromised systems.
Again, ironically, they talk about “confusion” and “inaccurate reporting” when their process does precisely this by design. Don’t like it? Push back on each CVE ID and make the subsystem maintainer validate your report! But read it again and it clearly says that those maintainers are the only individuals that can “determine its appropriate CVE designation“. Yet, a body higher than them in the Linux CNA is doing exactly that; assigning CVE IDs without having the appropriate person make that decision.
I am not a Linux developer, but I asked one knowing that the question may not have a simple answer. How many subsystems does Linux have? He initially answered five: Scheduler, MMU, VFS, Networking, and IPC. But after a bit of discussion, he quickly qualified that maybe those should be considered the five major tenants, and that the list of sections in the Linux MAINTAINERS file could be argued as subsystems, and there are a lot. Another developer he talked to said that you could argue every subdirectory in drivers/ and /arch are their own subsystem, meaning there are currently 369.
That means only those developers, or ones who have intimate knowledge of that code, could determine the validity of a CVE assignment. However, even a developer that has contributed code to e.g. a driver may not be in a position to determine the validity of a CVE, if they have the time or inclination to do so. Even going by a conservative number of subsystems and maintainers, that is far less than the number of people that now have to deal with the fallout of these mass assignments.
Off to a Bad Start
As a CNA for 13 days, Linux has assigned 76 CVE IDs already, and only one has been flagged as REJECTed. That seems like a good start, given their approach. But as I covered incoming CVEs over the weekend for work, I noticed two that stood out to me as neither should have received a CVE assignment, and it was quite apparent from the descriptions alone. This was followed by one more today that stood out as again, not a vulnerability and the description made it pretty clear. Yes, by the Linux CNA logic, any bug might be, or become a vulnerability, but until there is some evidence then it simply isn’t worth assigning an ID. Let’s look at them:
In the Linux kernel, the following vulnerability has been resolved: PCI: Avoid potential out-of-bounds read in pci_dev_for_each_resource() Coverity complains that pointer in the pci_dev_for_each_resource() may be wrong, i.e., might be used for the out-of-bounds read. There is no actual issue right now because we have another check afterwards and the out-of-bounds read is not being performed. In any case it’s better code with this fixed, hence the proposed change. As Jonas pointed out “It probably makes the code slightly less performant as res will now be checked for being not NULL (which will always be true), but I doubt it will be significant (or in any hot paths).”
In the Linux kernel, the following vulnerability has been resolved: crypto: rsa – add a check for allocation failure Static checkers insist that the mpi_alloc() allocation can fail so add a check to prevent a NULL dereference. Small allocations like this can’t actually fail in current kernels, but adding a check is very simple and makes the static checkers happy.
In the Linux kernel, the following vulnerability has been resolved: Revert “kobject: Remove redundant checks for whether ktype is NULL” This reverts commit 1b28cb81dab7c1eedc6034206f4e8d644046ad31. It is reported to cause problems, so revert it for now until the root cause can be found.
For the first, the description clearly states there is no actual issue. The second says that the described issue cannot actually fail in current kernels, meaning it may only impact old or unreleased versions. The third just says the issue is reported to cause problems, but doesn’t specify the type of problem, how often, or if it even has a security implication. It also covers a patch that has been reverted, and related to redundant checks for something making it harder to understand what the “vulnerability” is. These are all examples of bad assignments with the exception of the last, pending a bit more explanation of the problem. Regardless, it is clear from the first two that the Linux CNA approach is only adding noise and extra work for the broader CVE ecosystem and all those within it.
The Prophecy was Foretold by the GSD
What is the GSD? It is the ‘Global Security Database‘ run by the Cloud Security Alliance, and GSD was originally created by Kurt Seifried and Josh Bressers. Kurt is currently the CIO at the CSA and formerly at Red Hat and emeritus CVE Board Member. I bring Kurt up because he actually pioneered the approach that the Linux CNA is currently using and they began doing it in or before 2022. You can see this beginning in the 2022-1000000 range of GSD identifiers, likely starting with GSD-2022-1000009. From there, the ID assignments spiral immediately into covering a considerable number of Linux issues.
These assignments follow the same pattern. Citing a Linux Kernel commit, the description is taken verbatim from the commit message header and the rest of the text is typically a placeholder disclaimer:
This is an automated ID intended to aid in discovery of potential security vulnerabilities. The actual impact and attack plausibility have not yet been proven.
So here we have a case of the GSD assigning an ID to an issue that may, or may not be a security vulnerability through a mostly, or completely, automated process. Brad Spengler points out that Linux is doing the same thing using a tool called “bippy”. This is not the right way to do vulnerability ID assignments. In some cases where an issue is suspected to be a vulnerability, based on experience or personal knowledge of how, assigning an ID is correct.
CVE was actually designed to assign the ID with a different format, e.g. CAN-1999-0520, to be used during the disclosure process so that the ID could be referred to by vendor(s) and researcher(s) to avoid confusion. Note, this is why it is important that unique IDs exist and even typos can cause a world of confusion and extra work these days.
Looking at the now CVE-1999-0520, after MITRE deprecated the CAN versus CVE prefix over a decade ago, you can see to this date how board members would vote on each issue to be considered for inclusion. Jump to today and reporting a vulnerability to a vendor may result in a quick ID assignment, whether an internal ID or a CVE ID, pending triage. If it is determined to be valid and disclosure happens, then a CVE ID usually becomes public. If not, it can be REJECTed by the vendor for non-use or declared “issue was not security related” (or similar). So the process of assigning IDs like this has some merit.
Right up until you assign an ID for every fixing commit that has certain terminology in it, like GSD does. Now, this immediately works against the process and goes against the spirit of that intent. Why? Because these IDs are immediately public and anyone using that source for vulnerability intelligence has to triage the issue. It’s difficult enough for teams to keep up on the well-written CVE descriptions, and it is already impossible for them to triage the numerous vague and poorly written descriptions on top of all of their responsibilities. This approach drowns blue teams and wastes their valuable time. This is what Brad Spengler also realized and remembered.
Jumping back to GSD, searching for “git.kernel.org” in their repository you get 29.8k files at the time of this blog. Who is this really helping by doing such mass assignments? That many GSD IDs for Linux issues in just two years since the CSA announcement on creating the GSD. With GSD assigning based on specific keywords, and the Linux CNA assigning more liberally, we could conceivably see numbers significantly higher than that. But again, these are assignments, not always vulnerabilities, and in both cases neither entity cares. It is by their design and how they want to approach “vulnerability intelligence”.
Cool. Do it your way! But when your way gets injected into the CVE ecosystem and forces the rest of us to triage your poorly written bug reports, some of which might be vulnerabilities, that crosses a line.
The solution is “simple” and we likely won’t see either one of these happen due to the apathy of MITRE. First, revoke the CNA stamp from Linux pending a better process. Second, let them stay a CNA but require them to write valid and accurate descriptions that clearly outline the vulnerability, impact, and attack vector, and do so under the supervision of a CNA with experience. Either one is sufficient to curb this problem before it gets out of hand. Unfortunately, MITRE has a near-perfect track record for not holding CNAs accountable to their own CNA rules as is. Until they decide to care, the burden is on the rest of us.
Good luck.
[2/28/2024 Updates: First, yesterday saw 71 Linux CNA assignments and today 86 so far. As Linux refines their automation for assignments, these numbers can conceivable go up considerably. If their philosophy truly is all bugs matter and to assign an ID to every one, consider that the kernel repo has over 1,200,000 commits to date. Imagine CVE IDs for even a tenth of them.
Second, a paper titled “SyzBridge: Bridging the Gap in Exploitability Assessment of Linux Kernel Bugs in the Linux Ecosystem” has an interesting point regarding exploitability and speaks to probability, specifically to the stance that “almost any bug might exploitable“. Consider this excerpt from the introduction:
Considering the enormous volume of kernel bugs, conducting manual inspections to assess the exploitability of every single one is unrealistic. This led to the development of bug assessment techniques which attempts to classify bugs based on some notion of “exploitability”, e.g., uncovering high-risk
exploit primitives. The automated exploitability assessments have successfully identified many exploitable bugs. Notably, SyzScope has classified 183 bugs out of 1,170 fuzzerexposed bugs as high-risk. KOOBE has managed to generate 6 new exploits for previously non-exploitable bugs. Despite these promising outcomes, the occurrence of realworld Linux kernel exploits remains surprisingly rare. Indeed, syzbot has reported only 5 exploitable kernel vulnerabilities originating from upstream kernel bugs since 2017.
Those numbers firmly push back on the Linux notion of exploitability. Food for thought.]