57

We are a vendor providing a product that is being used in enterprises. We know that those companies having periodic CVE scans on products they are using part of their vulnerability management process. My question is, do we have to raise a CVE if our own security researcher found a vulnerability in our product or we can just raise this vulnerability in the weekly security updates we publish in our official website?

Filipon
  • 1,204
  • 10
  • 22
  • 2
    It seems you sell your product. Do you have a reasonable way of communicating the information to all your clients, and only to your clients? (i.e. by sending an e-mail instead of publishing an announcement on your website). The answer to this question may help you choose between the answers below. – Law29 Mar 16 '19 at 04:59

6 Answers6

66

You can do either, but I recommend applying for a CVE so that customers who get threat intelligence feeds are more likely to notice the issue and expedite a patch. Assigning a CVE also makes it easier to reference a specific vulnerability in general communications if you need to later. It's also a signal to your customers that you take security transparency seriously.

CVEs are assigned and managed by MITRE, and you can use the CVE application form to make a request.

Polynomial
  • 132,208
  • 43
  • 298
  • 379
  • 1
    Domyou have first hand experience with applying as a Vendor for a commercial product for a cve at the root cna? – eckes Mar 15 '19 at 11:19
  • 1
    @eckes I've never done the process myself, but I've worked with and for vendors that have applied for CVEs and from what I could tell the process was no different than if a 3rd party applied for it. – Polynomial Mar 15 '19 at 11:21
  • 1
    Yes, should be the same process, the question is just how fast was the turn around and what happens after repeating it a few times a year – eckes Mar 15 '19 at 11:22
  • 2
    @eckes Oh, CVE assignment turnaround is generally fairly quick. I've had them assigned within hours before. Longest wait I ever had was 6 days but there were extenuating circumstances (two people responsible for assigning CVEs at MITRE were sick at the same time). – Polynomial Mar 15 '19 at 11:24
  • 1
    Good to know, sounds like this has improved! – eckes Mar 15 '19 at 11:36
  • I can affirm that the people at MITRE are very dilligent, in my case they even notified me of a mixup with identifiers on another site. Regarding getting CVEs registered as a vendor, I am sure they will be happy to receive the info, no matter the source. – J.A.K. Mar 15 '19 at 18:19
25

It would be helpful to publish the CVE so that others know it's necessary to update: as you said, they can see it in threat intelligence feeds (or CVE scans) instead of having to read the changelog of every update to decide whether they need to update.

Additionally, as a pentester, it helps us a lot in our work. If we find SAPConnectorDeluxe 4.1.39, the first thing we do is check a CVE database for any vulnerabilities. Even if the software is proprietary and in use for only a few companies, it is useful for us to know the risks of running that software so that we can advise the customer correctly.

It also tells us how frequently and what kind of issues are being found: if we see that a small software component had 10 buffer overflow vulnerabilities in the past year, we know the developers don't get the time to include security in their development process. In such a case, it's very likely that more vulnerabilities will be found, or are already found by malicious parties.

Submitting CVEs is not common if the software is only used internally. If we find custom software, we do some analysis (depending on how much time we have) and advise to have someone review its security more thoroughly. Info about internal products would not help anyone outside the company, so there is no need to publish it to a central database like CVE.

Luc
  • 31,973
  • 8
  • 71
  • 135
  • 2
    This answer spends quite a bit of time discussing a reason not to file a CVE, which is that too many can make you look bad. I think the benefits of demonstrating your commitment to security outweigh this, but this answer won't help convince anyone of that. – sondra.kinsey Mar 14 '19 at 17:31
  • 2
    On a similar note, too many CVEs can also make you an attractive target for hackers. If you patched 10 buffer overflow vulnerabilities in the past year, then a hacker can see this as likely evidence of an 11th, and focus a lot more energy on you than he would otherwise. Even if your actions showed commitment to security and you patched all of your overflow vulns, the extra attention is likely to expose an unrelated problem. So, at a point, too many CVEs themselves can become a security liability. – Nosajimiki Mar 14 '19 at 19:47
  • To complement the above comments, I have the feeling sometimes CVEs are (mis)used as free advertisement, to sneak the name of an otherwise unknown product in thousands of feeds. – Enos D'Andrea Jun 02 '20 at 08:06
8

You are not required to request a CVE, but you are free to do so when you think it will be benificial.

A CVE is just a central number that identifies a vulnerability, which can assist when communicating about vulnerabilities. CVE's are particularly helpful when there are multiple parties involved. Anyone can request a CVE in your product, but in my opinion it looks better if you do it yourself before somebody else does.

Sjoerd
  • 28,707
  • 12
  • 74
  • 102
  • 2
    Small remark: You say "it looks better if you [request a CVE for a vuln in your product] yourself before somebody else does", but that sounds like the developer of the software should always snatch up the CVE before anyone else can request it. To me, that would feel like taking part of the credit. I'd rather say it should be the person who found it -- which in this case is the company itself, but it often (usually?) isn't. Not sure how you meant it. – Luc Mar 13 '19 at 20:27
7

I think the most important question is if your product comes with an auto-updater. If it auto-updates by default, then a CVE can sometimes do more harm than good by putting your product into the realm of awareness for many hackers who may otherwise not know you even exist. They can see your CVE history, and get a good feeling about your security posture. If they see a lot of fixes for "amature" mistakes, then your product might easily come under the scrutiny of people who know how to find the more obscure stuff that you may have otherwise gotten luck enough to avoid.

Also, products that are unlikely to be patched even if you release a CVE can do more harm than good. Most IoT devices never get patched, so, CVEs just tell hackers which ones are easy prey.

In contrast, if your product typically requires a manual update that is likely to happen if you release a CVE, then you should probably do it.

Nosajimiki
  • 1,799
  • 6
  • 13
2

If this is a really critical issue, then you might patch the issue and keep it secret for as long as possible.

Then the customers have a longer time frame for applying software updates.

Also make sure to use as much binary obfuscation as possible, in order to hinder "differential reverse engineering" after delivering the patch.

Mike76
  • 283
  • 1
  • 2
  • 9
  • 8
    By keeping it secret, there is not one effect (the one you mention) but two effects: yes, customers have more time to upgrade because bad guys *might* not realize there is a vulnerability, but also, customers won't be aware there is an issue and might go "meh, we don't need these new features and didn't notice any bugs, no need to spend sysadmin hours to upgrade it". That said, you did get me thinking: it might be good to, instead, communicate it to customers privately before making it public (as is done with responsible disclosure). – Luc Mar 13 '19 at 20:41
  • 1
    @Luc: I don't think that Mike is suggesting keeping the existence of a patch secret. It's the details of the issue that are kept secret. Customers should be motivated to install a patch listed as "fixed remote code execution vuln" based on the severity, without understanding the bug itself. – Ben Voigt Mar 14 '19 at 18:43
  • 1
    @BenVoigt CVEs usually don't include enough detail to exploit an issue, only in some cases they're later updated to link to a page with more details. But indeed, Mike might have meant that, I don't know. – Luc Mar 14 '19 at 19:27
  • 3
    @Luc: Just grabbing a random recent CVE, CVE-2018-7183. The title is "Buffer overflow in the decodearr function in ntpq in ntp 4.2.8p6 through 4.2.8p10 allows remote attackers to execute arbitrary code by leveraging an ntpq query and sending a response with a crafted array." That is not precisely "enough detail to exploit an issue" but it certainly is enough to give attackers a huge headstart. – Ben Voigt Mar 14 '19 at 20:07
  • I suggest to write something like "critical bug fixes, improved security" in the release notes. Most CVEs I have seen provide way too much details for a fast disclosure. – Mike76 Mar 14 '19 at 22:46
  • 3
    @BenVoigt just a remark, if you look at open source CVEs there are by nature more complete and detailed. Commercial vendors might have a policy not to disclose details. Oracle for example is notoriously bad. – eckes Mar 15 '19 at 11:40
1

Few companies will apply patches immediately, most will have some quality control and evaluation before any update is put into their systems. The CVE definition allows them to know what vulnerabilities are in the current version of the software. Then can then evaluate that vulnerability and make an informed choice of when they will apply the update.

Ralph
  • 11
  • 1