Thread

Several vulnerabilities have been discovered in the Linux kernel

576 points · 408 comments · luispa

john_strinlai · 1790902914 · focus · HN ↗
note that _any_ bugfix is assigned a cve, which makes for big numbers.
>“Due to the layer at which the Linux kernel is in a system, almost any bug might be exploitable to compromise the security of the kernel… Because of this, the CVE assignment team is overly cautious and assign CVE numbers to any bugfix that they identify.”
<a href="https://docs.kernel.org/process/cve.html" rel="nofollow">https://docs.kernel.org/process/cve.html
"number of cves" is a useless metric, especially when it comes to the kernel.
1. SAI_Peregrinus · 1790903533 · focus · HN ↗
  Tautologically every bug can legitimately be assigned a CVE, since every bug prevents some feature from working as intended. It's therefore a denial of service, which by the definition of the CVE system using CVSS means every bug is at least a 1/Low level vulnerability to CVSS v4.0.
  If you're willing to stretch, missing but planned features also deny the use of said features since they haven't been added yet, and so are CVSS 1/Low vulnerabilities.
  Resume-driven development for security researchers has never been easier!
  1. jeroenhd · 1790922696 · focus · HN ↗
    Loads of bugs aren't CVE-worthy. If you tell the computer to make a light green but it makes the light red, that's a bug but no DoS or other CVE-worthy bug.
    However, the Linux kernel is supposed to run any userland program without crashing, so anything that crashes the kernel is a local DoS and there are a lot of them. It's also supposed to shield processes from each other and maintain privilege levels correctly, so many incorrect memory leaks are also CVE worthy. Whether a CVE applies depends on the people and programs using the kernel, and the kernel team can't read your code to tell you if it applies or not.
    People reading CVEs wrong ("it's got a high number so we must patch within a day") must be going crazy over this, but the point of CVEs is to let you make judgement calls, not to be a cool statistic about how secure something is.
    Most CVEs are irrelevant to most people, that's always been the case.
    somat · 1790928516 · focus · HN ↗
    "why did the ship crash?"
    Unpatched bug, wrong color lights.
    Yes, it is a bit of a stretch, I desperately hope programmable navigation lights are not a thing. And I also don't think every bug needs a CVE. But in the correct context nearly any bug could be critical.
    seanhunter · 1790929387 · focus · HN ↗
    Computer Weekly in the UK did some pioneering journalism into a helicopter crash[1] that had initially been blamed on the two pilots but seems very likely to have been caused by a failure of a computer system that was controlling the fuelling of the engines. Iirc this system seems to have crashed causing engine failure of both engines in heavy fog, bringing the helicopter down with a loss of everyone on board, however for reasons somewhat unclear, the MOD wanted to cover the failure up by blaming the pilots.
    Now this was a windows system[2] rather than linux but the point remains - if there was an external vulnerability in a crucial control system and this system was part of a network (eg to connect telemetry) then any exploit of that system could result in loss of life.
    [1] <a href="https://www.computerweekly.com/news/1280091718/Chinook-computer-was-positively-dangerous-say-newly-disclosed-MoD-documents" rel="nofollow">https://www.computerweekly.com/news/1280091718/Chinook-compu...
    After an assessment of the Fadec software the Superintendent of Engineering Systems said that the density of deficiencies was so high that the software was unintelligible.
    [2] Which, why? Why build the fuel controller for a helicopter engine on windows?
    rjsw · 1790932267 · focus · HN ↗
    Are you sure that the Chinook used Windows? I have not read this elsewhere.
    There have been documented problems with Windows for Warships.
    seanhunter · 1790939341 · focus · HN ↗
    My memory is ancient so may be flawed but that is what I remember. This seems to be a full chronology of the incident if you’re interested <a href="https://www.computerweekly.com/news/1280096804/Chronology-The-Chinook" rel="nofollow">https://www.computerweekly.com/news/1280096804/Chronology-Th...
    sas224dbm · 1790943160 · focus · HN ↗
    A windows system controlling the refuelling ? Worked in aviation software for a while and the certification for flight control (or similar) systems is subject to rigorous path testing/inspections/approvals etc DO-178C (level A or B likely). Not sure if any windows OS is certified to level A?? Typically certifiable RTOS'es are procured for those purposes
    jeroenhd · 1790940953 · focus · HN ↗
    That's still not cause for a CVE, even if it's a bad bug.
    MyMemoryfails · 1790928612 · focus · HN ↗
    Unless that computer happens be on traffic lights. Will this become CVE? Human life would be at risk.
    GTP · 1790938769 · focus · HN ↗
    This is actually the point of the parent comment: you have to read the CVE and see for yourself if it impacts your specific system or not.
    sigmoid10 · 1790939584 · focus · HN ↗
    If only the user can tell whether something is potentially dangerous, then either every bug or none of them should get a CVE. There are countless systems out there that are commonly used in ways beyond what even the developer intended, how should a third party authority like the CNA be able to discern this?
    TeMPOraL · 1790942743 · focus · HN ↗
    They can't. Which is why security discussions are such a hot mess.
    The vendors fixing them arguably prioritize these reports right. Most of the CVEs, even severe ones, are irrelevant in practice, and as parents note, are more like regular bugs with security flavor in reporting. The CVE label instead of regular bug tracking number makes them seem important.
    Linux Kernel may be one of the few legitimate exceptions, indeed, due to the position in which it sits in the software stack. Also LLMs make previously unexploitable-in-practice vulnerabilities exploitable (by making targeted / personalized attack cheap enough to give them positive ROI), which complicates things.
    openasocket · 1790948725 · focus · HN ↗
    I think you have to make a distinction between bugs and actual vulnerabilities. Therac-25 killed people, but I wouldn’t consider anything about it to be a security vulnerability. In my mind, the distinction between a bug and a vulnerability is that a bug is triggered during “normal” operations and can do anything. Whereas a vulnerability requires an adversary to “trigger” the vulnerability, and can do this to achieve some cognizable malicious goal. There’s probably some overlap on the edges; whether an issue in a library is a bug or a vulnerability may depend on how it is used, for example.
    But I think the most important thing to keep in mind is that a bug isn’t necessarily less serious or less important than a vulnerability. A serious bug should be patched just as urgently as a serious vulnerability.
    funcDropShadow · 1790934279 · focus · HN ↗
    Unless it is the led showing the status of a camera.
    literalAardvark · 1790939170 · focus · HN ↗
    Yeah in that case it's a feature and management can proudly proclaim "we own the glass"
    [deleted] · 1790943906 · focus · HN ↗
    [deleted]
    Sesse__ · 1790940574 · focus · HN ↗
    > but the point of CVEs is to let you make judgement calls
    Realistically, most admins cannot make judgment calls about 1000+ CVEs for a kernel release.
    jurgenburgen · 1790943466 · focus · HN ↗
    Usually the security team mandates a zero CVE policy on all deployments and the organization complies.
    lstodd · 1790950612 · focus · HN ↗
    we in security teams can only dream of such incompetent management
    zero CVE policy = halt on business development.
    dormento · 1790944226 · focus · HN ↗
    And not only that, remember the hn crowd is not at all representative of the average.
    Even more realistically, many admins do not have the background to be able to reason (by themselves) about the actual risk of most CVEs, so just going along with specialized media coverage is often a sound strategy.
    wang_li · 1790957857 · focus · HN ↗
    >And not only that, remember the hn crowd is not at all representative of the average.
    We should keep our hopes up, someday we may get there.

Open on Hacker News to reply ↗

Unofficial Hacker News client; not affiliated with Y Combinator.