Slashdot Mirror

← Back to Stories (view on slashdot.org)

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

Posted by timothy on from the hope-it's-built-with-merger-in-mind dept.

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.

47 comments

  1. Redhat = embrace, extend by Anonymous Coward · · Score: 0, Funny

    Leave it to RedHat. Next we'll see systemd-CVE, which uses a dbus interface to generate new numbers on the fly, except the announcement will be in a binary format only readable by a new 'cvectl' binary.

    1. Re:Redhat = embrace, extend by Jawnn · · Score: 0

      Leave it to RedHat. Next we'll see systemd-CVE, which uses a dbus interface to generate new numbers on the fly, except the announcement will be in a binary format only readable by a new 'cvectl' binary.

      Yeah, why am I not feeling good about the results of RedHat's "contribution" here? Don't get me wrong. It's cool that a company with the resources to do so is willing to help out with an important project, but still...

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

    3. Re:Redhat = embrace, extend by ttucker · · Score: 1

      Reality is so pedantic to a troll...

  2. Red Hat by Anonymous Coward · · Score: 0

    So a "Red Hat Product Security Cloud guy" has NIHS... Shocking.

    CAPTCHA: protest

  3. So it is faster? by Anonymous Coward · · Score: 0

    But is it web scale?

  4. copied from the register by Anonymous Coward · · Score: 1

    no offense, but this article has been copied from the register: http://www.theregister.co.uk/2...

    1. Re:copied from the register by AchilleTalon · · Score: 1

      No, not a copy, just an article on the same subject.

      --
      Achille Talon
      Hop!
    2. Re:copied from the register by Anonymous Coward · · Score: 0

      read both, it's just a regurgitation of the register's work

  5. Standards - https://xkcd.com/927/ by BitZtream · · Score: 1

    Yes, because another service is always the solution ... instead of fixing the existing one and improving it.

    This is typical red hat (and a common Linux issue in general) ... we don't like it so we're going to reinvent the wheel ... poorly and refuse to acknowledge any problems or defects in the new version.

    Sometimes you just need to put a little effort into actually working together instead of being a douchebag loan wolf who takes his toys and goes to live in the woods.

    --
    Persistent Volume manager for Kubernetes - https://github.com/dwimsey/openshift-pvmanager
    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. Re:Standards - https://xkcd.com/927/ by Anonymous Coward · · Score: 0

      This is his attempt at fixing the existing system. The hope is that the competing system will spur the company that runs it into action.

      Good luck with that. My experience with Mitre is that it's where competence goes to die. Sending people numbers should be the most trivial thing in the world. You have a master number, and when anyone needs a new one, you increment it. Supermarket delis around the world can figure this out. Not a difficult task.

    3. Re:Standards - https://xkcd.com/927/ by Anonymous Coward · · Score: 0

      This is his attempt at fixing the existing system. The hope is that the competing system will spur the company that runs it into action.

      Good luck with that. My experience with Mitre is that it's where competence goes to die. Sending people numbers should be the most trivial thing in the world. You have a master number, and when anyone needs a new one, you increment it. Supermarket delis around the world can figure this out. Not a difficult task.

      What is so difficult about incrementing the CVE number by 1 each time? Format: YYYY-NNNN (YYYY: year, NNNN: serial number incremented by 1 starting at 0000 and ending with FFFF for each year.

    4. Re:Standards - https://xkcd.com/927/ by AlterEager · · Score: 1

      Yes, because another service is always the solution ... instead of fixing the existing one and improving it.

      So, how do you do that exactly? Someone asks MITRE for a CVS number for a vulnerability they've found and MITRE replies:

      Thank you for your request.

      Your request is outside the scope of CVE's published priorities. As such, it will not be assigned a CVE-ID by MITRE or another CVE CNA at this time.

      What next?

    5. Re:Standards - https://xkcd.com/927/ by Anonymous Coward · · Score: 0

      "Yes, because another service is always the solution ... instead of fixing the existing one and improving it."

      Sometimes it's the only solution.

      If the broken one is controlled by a disinterested party, what else can you do? Just sit while they remove features, rearrange the UI again, or whatever until your bug eventually gets marked WONTFIX?

    6. Re:Standards - https://xkcd.com/927/ by mysidia · · Score: 1

      What next?

      Why don't we just have the vendor self-generate a GUID to use to refer to the security vulnerability?

      Whoever notes the vulnerability first generates a GUID, and MITRE's only Job becomes to provide a database of the GUIDs.

    7. Re:Standards - https://xkcd.com/927/ by frank_adrian314159 · · Score: 1

      Is that better or worse than a loan shark?

      That depends... Is it a douchebag loan shark?

      --
      That is all.
    8. Re:Standards - https://xkcd.com/927/ by AlterEager · · Score: 1

      MITRE refused to allocate a CVE. It's not the number that's the problem, it's that they are refusing to do their job.

    9. Re:Standards - https://xkcd.com/927/ by Anonymous Coward · · Score: 0

      MITRE refused to allocate a CVE. It's not the number that's the problem, it's that they are refusing to do their job.

      They aren't refusing to do their job, so much as their mission statement is different from what the community now expects. CERT has a good blog post: https://insights.sei.cmu.edu/cert/2016/03/vulnerability-ids-fast-and-slow.html

    10. Re:Standards - https://xkcd.com/927/ by Anonymous Coward · · Score: 0

      What is so difficult about incrementing the CVE number by 1 each time? Format: YYYY-NNNN (YYYY: year, NNNN: serial number incremented by 1 starting at 0000 and ending with FFFF for each year.

      Ask Mitre, they're the ones that can't figure that out. Although I think you'd need a larger number space than just 16 bits.

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

    2. Re:Thanks by Anonymous Coward · · Score: 1

      The ironic thing is that people are so against systemd, when many of their complaints apply equally to OpenRC. Namely, it's mostly written in C (81.8% C, 9.3% Shell, 8.5% makefile, .4% other), it has annotations for dependency resolution, supports cgroups, and I believe parallel startup is also in the works. But when systemd does it, clearly nobody needs those features.

      The other ironic thing is that people have this nostalgic idea that sysvinit was somehow not a piece of crap. Except that it was self-defeating: the first replacement for SysV init was the init scripts themselves, which completely disregarded all of the features provided by init/inittab. Whatever we think of as an init system must have some insight into the underlying system; blindly starting or restarting services is a feature no one needs. Nobody trusts inittab to be able to start/stop/restart the database correctly, so the init scripts needed to absorb (and frequently, duplicate) all of the complexity actually needed to manage a system, and 33 years later, there is literally no one willing to maintain that snowballed clusterfuck. Systemd, OpenRC, launchd, and all the other SysV init replacements were simply recognizing that while there must be some script-like component to the init process, service writers should rely on scripting only where it cannot be avoided. Because while the script writer knows the most about their own processes, they do not and should not have the most information about the system as a whole.

      SysV init is the epitome of abandonware: discarded by everyone, even sysvinit.

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

    1. Re:"But according to a number of researchers" by Anonymous Coward · · Score: 0

      Seems to me it's about keeping track of security issues, publicity doesn't come with a number - it comes with a shiny logo. Where have you been?

    2. Re:"But according to a number of researchers" by generic · · Score: 1

      What makes for a crappy security researcher? because the software they've found a bug in isn't on mitre's short little list of CVE approved vendors?

      --
      Microsoft aggravates my tourettes syndrome.
    3. Re:"But according to a number of researchers" by Dr.+Evil · · Score: 1

      If I have a Radware product in my organization, I would subscribe to their security and support mailing lists, which is where this seems to be posted. There are thousands or more of different products from different vendors, probably tens or hundreds of thousands if you include the crazy knockoffs, FOSS assemblages, and fly-by-night companies.

      There are far fewer genuinely unique bits of software which most of these products are made from. E.g., only so many IP stacks are out there, only so many web servers, etc. Even this vulnerability mentions that it is in a "third party library"

      I had a longer reply, but if you follow the links, the guy who reported it expressly asked for discretion...

      "(And currently I'd apprechiate if you don't make a big buzz out of this issue, because we're preparing a paper on it by the end of march where we'll disclose a bunch of similar issues)"

      Ooops.

      Sucky security researchers are in my mind, the guys who self-aggrandize. This may very well be an issue where the guy's discovered something much bigger and wants one of those quiet reserved CVEs for his release of the vulnerability in the underlying library. There are lots of details in this specific case.

      I guess we'll find out.

    4. Re:"But according to a number of researchers" by generic · · Score: 1

      I see your point, I only care to assign CVE IDs to my discoveries because folks ask me for them. It gets annoying when I've found a vulnerability and someone is hounding me about the CVE ID so they can track it and mitre doesn't respond to my emails.

      --
      Microsoft aggravates my tourettes syndrome.
  8. 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.

  9. Another solution by edtice1559 · · Score: 0

    Maybe we find a way to not have so many vulnerabilities. Just a thought.

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

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

    3. Re:Another solution by Anonymous Coward · · Score: 0

      There were some security concerns raised in the 70s, but for the most part nobody had any idea that pretty much everything with a microchip was going to be networked together: there were pretty much only local threats, and the most valuable thing that could be stolen was computer time on some big multi-user system. Now not only do we have more and bigger problems, but we have an exponentially greater amount of code being written, due to the proliferation of useful high-level libraries, better toolchains, better languages, and putative "10x programmers". With more people writing ever-more code, are you surprised that there are more vulnerabilities?

      I don't think the current state of the industry says anything better or worse than at any other point in history. It's simply a bigger industry. However, if you have some sort of evidence to support your assertion, please share it.

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

    1. Re:A vague problem by generic · · Score: 1

      Mitre either isn't responding or flat out rejecting valid requests because they've changed the scope of what they will assign numbers too.

      --
      Microsoft aggravates my tourettes syndrome.
    2. Re:A vague problem by Anonymous Coward · · Score: 0

      Concrete examples and stats would be great in this instance. This reads a bit like a Slashdotter who says too many of his articles are rejected, and wants to start his own site.

    3. Re:A vague problem by generic · · Score: 1

      Here is one http://www.openwall.com/lists/...

      --
      Microsoft aggravates my tourettes syndrome.
    4. Re:A vague problem by Anonymous Coward · · Score: 0

      If you subscribe to oss-security, you must have noticed that people have been requesting CVEs for every minor thing recently. Even when the only consequence of a flaw is a crash, some people argue that's a DoS vulnerability, therefore it's a security flaw, and deserves a CVE number.

      I have no trouble believing that's becoming unmanageable.

    5. Re:A vague problem by Anonymous Coward · · Score: 0

      And? They're numbers, it's not like we're going to run out of them.

      How is this difficult? Get an email requesting a number, hit a button to pull a new number out of some master database sequence, send it out.

      So what if you give them to "minor" issues? Why is this an issue?

      This sounds like the stupid Wikipedia "notability" requirements all over again.

    6. Re:A vague problem by Anonymous Coward · · Score: 0

      It this was just about handing out unique numbers, of course it wouldn't be an issue. An e-mail wouldn't even be necessary, the process could be automated.

      Again, if you follow oss-security you'll see MITRE does a lot more than that. They question the requests on a technical level, clarify whether there should be one or more separate CVE numbers for the reported issues etc. Other organizations also have protocols that require reacting to CVEs.

      It's not just a number, it's a significant part of a larger process of vulnerability disclosure and record keeping.

  11. "Not for profit"... by jfengel · · Score: 1

    "Non-profit" is a pretty loaded term here. It implies charities or colleges or arts organizations. That's not really what's going on. It just means that they're not turning their profits over to any shareholders. There are tax consequences, but it's actually not all that big a deal, since even ordinary corporations are only supposed to be paying taxes on profits anyway, not revenues. Which theoretically lets them raise wages and lower prices, though they're not actually all that good at either. Mostly, they turn it into giant executive bonuses.

    I'm not exactly sure how MITRE and some other Beltway bandits get away with being "non-profits". I think they call themselves "research". But really, they don't belong in the same category as charities.

    1. Re:"Not for profit"... by Anonymous Coward · · Score: 0

      MITRE, like every FFRDC, is chartered by an act of Congress. They're exempt from comptetitive bid laws, and forbidden from competing with folks who are subject to those laws. Basically, FFRDCs are fair brokers created by the government to give them straight answers. That's why they're not for profit. They have no clients besides the government, by design.

  12. Relevant XKCD by themusicgod1 · · Score: 1

    Problem: there are N relevant places to look for CVEs

    Solution: let's make a better one!

    Problem: there are N+1 relevant places to look for CVEs.

    --
    GENERATION 26: The first time you see this, copy it into your sig on any forum and add 1 to the generation.
  13. Bull from a corporate shill Re:"Not for profit"... by rcharbon · · Score: 1

    Uh-huh. And just for the sake of comparison, what do the CEOs at those noble 'for profit' government defense contractors make on a yearly basis? The article mentioned Lockheed Martin, whose CEO made $25 million in 2013: https://www.washingtonpost.com...

  14. Re:Bull from a corporate shill Re:"Not for profit" by Anonymous Coward · · Score: 0

    Lockheed Martin does not run any FFRDCs. They are a for-profit company. So...apples to oranges.

  15. Re:Bull from a corporate shill Re:"Not for profit" by Anonymous Coward · · Score: 0

    Lockheed runs Sandia, which is an FFRDC. It is compartmentalized from their for-profit business.