Slashdot Mirror


One Solution to MITRE's Overworked CVE System: Build a New One (helpnetsecurity.com)

An anonymous reader writes: For the last 17 years, the American not-for-profit MITRE Corporation has been editing and maintaining the list of Common Vulnerabilities and Exposures (CVEs). According to a number of researchers, MITRE has lately been doing a lousy job when it comes to assigning these numbers, forcing researchers to do without them or to delay public disclosure of vulnerabilities indefinitely. The problem is getting worse by the day, and the situation has spurred Kurt Seifried, a "Red Hat Product Security Cloud guy" and a CVE Editorial Board member, to create a complementary system for numbering vulnerabilities.

9 of 47 comments (clear)

  1. Re:Standards - https://xkcd.com/927/ by arth1 · · Score: 2

    a douchebag loan wolf

    Is that better or worse than a loan shark?

  2. Thanks by Anonymous Coward · · Score: 3, Insightful

    I was looking for a way to say this politely, but can you just can it with the systemd trolling? It has literally no connection to this proposal. This is some guy who happens to work at Red Hat. It shouldn't shock anyone that Red Hat employs a lot of people in the Linux and/or security worlds. He says right up front he is speaking on his own behalf and not that of Red Hat, and as far as I can tell he has jack-all to do with systemd development. There's even the possibility that he dislikes systemd as much as you do. I'd bet any amount of money that he would oppose your hypothetical systemd-CVE as a completely pointless increase in attack surface.

    Begone, troll. This is not the overreaching NIH syndrome you were looking for.

    1. Re:Thanks by Luthair · · Score: 2, Insightful

      If they stopped trolling they might have time to write the software they want that doesn't use systemd. Of course they don't want to do actual work, they want someone else to do it for them.

  3. "But according to a number of researchers" by Dr.+Evil · · Score: 2

    1 is a number. There are lots of numbers.

    If there's a problem at all, I would wager it's all the crappy "security researchers" trying to make a name for themselves by claiming the sky is falling and getting a CVE on their blog to make themselves look important.

  4. Re:Redhat = embrace, extend by Luthair · · Score: 3, Insightful

    So in the interests of full disclosure and transparency I (Kurt Seifried) am writing this email as an individual and member of the DWF System, and not as an employee of Red Hat. Please note that although I have a day job at Red Hat I also (like many information security people) work on other projects in my personal life, either because they are not work related, or because it's simply not appropriate to work on the project as part of my day job (in this case it's less about Red Hat, and more about the fact that as a Red Hat Employee I am a member of the CVE Editorial Board).

    Seems clear RedHat has nothing to do with this

  5. Red Hat/DoD/MITRE - I see the relationship by OffTheLip · · Score: 2

    The US Dept of Defense (DoD) is a Red Hat customer and required to react to IAVA's/CVE's. MITRE provides system engineering support for the USAF among other branches so it seems like a good working relationship to me. Red Hat has been supportive of the IAVA/CVE patch process and working to better the system is a win-win in my opinion.

  6. A vague problem by feenberg · · Score: 2

    Is the problem that MITRE has an inventory of unprocessed requests, or that MITRE is rejecting requests as duplicative or incorrect? That does make a difference in how one thinks about the problem. If the latter, perhaps those in favor of bypassing MITRE could provide convincing examples of incorrect rejections.

  7. Re:Another solution by xxxJonBoyxxx · · Score: 2

    >> Just a thought.

    When did this place become Facebook? What's next, "just sayin'"? "JK"? Perhaps your high ID explains it, but on SlashDot there's no reason to snark off and then hide behind your mom's skirt - we LIKE bold discussions.

  8. Re:Another solution by edtice1559 · · Score: 2

    The fact that vulnerabilities are happening so fast that we can't even catalog them speaks pretty poorly for our industry. There is new code being written today that will have exploitable buffer overflows. Even though this problem has been well documented since probably the seventies. We have things like ASLR that put a band aid on it, but the reality is that the systems we develop are a few more orders of magnitude more complicated that what was built back then. But our tools and techniques haven't advanced much. Sometimes I'm surprised that any non-trivial software even works.