CVEs: PrimeKey takes a step forward

A question we've been posed through the last few years is whether PrimeKey writes CVEs for known security issues. We're now implementing a change in this policy, and we'd like to talk a bit about it.

Our policy until now has been to fix minor issues with announcements in the release notes, while major vulnerabilities have been immediately patched and customers have been informed about the issue, its severity and possible workarounds.

As PrimeKey has grown as a company and our product line has come to become one of the most commonly used solutions for PKI - in the internal corporate sphere, in distributed production models for IoT devices and not to mention the world of Web PKI - we've chosen to take a step forward and start submitting CVEs for all new and found exposures and vulnerabilities in EJBCA.

What is a CVE?

CVE stands for Common Vulnerabilities and Exposures, and is a general format for describing an security issue. The original driving force for defining the format was the lack of commonality between the differing sets of vulnerability databases existent at the time. The point of CVE is not to replace these databases but to create a common catalogue of issues linking these together. In a CVE context

vulnerabilities are defined as issues where logic errors allow the application to be used in ways other than it was intended.
exposures are configuration issues or bugs that causes the application to leak sensitive information.

The pertinent parts of a CVE are:

The CVE ID
A brief description of the issue
Links to the vendor's support portal or other source of security advisories

Fix information, impact and other data about the vulnerability are not included in the CVE, but expected to be on the vendor's support portal, i.e PrimeKey's support portal in this case.

A CVE is created by a CVE Numbering Authority (CNA), which analyses reports and writes CVEs. A report can be submitted by anybody (not just the software vendor), and the CNA does its best to avoid duplicate reports. Many large vendors become CNAs in their own right, but the main CNA is the US government funded MITRE Corporation, which is the entity which would handle reports about PrimeKey products.

Once a CNA has written a CVE and assigned it a number it's submitted to the NIST National Vulnerability Database and assigned a score based on the severity.

PrimeKey and CVEs

Starting from Q1 2020, PrimeKey has decided to start submitting all found vulnerabilities and exposures in EJBCA. Our internal policy is that once an issue which is classed as either is found, it is to be patched onto the latest stable releases and made available to customers, along with announcements on our support portal and and security announcements on our mailing lists.

Two working weeks after the customer release we will submit the CVEs, hence making the found security issues public. This period is meant to give customers, if affected by the issue, a chance to upgrade to the latest patch before the issues become public knowledge. For any issues that we deem to be major we will also follow up with a release of EJBCA Community.

Classification

In order to be completely transparent, PrimeKey has internally classified security issues as the following types:

Vulnerability

A logic error, bug or missing security check (such as XSS or CSRF) in one of our applications with a clear path of being able to make the application perform an action to which it was not intended, or otherwise allow a user to perform an action of which they are not intended to perform. A vulnerability does not need to end up with the application in a compromised state as multiple seemingly benign vulnerabilities can be linked together into a chain ending up in a successful compromise.

Result: A CVE will be submitted

Security Hardening

Similar to a vulnerability, but without any known exploit vector. Hardenings are performed preemptively in order to avoid vulnerabilities from forming in future code iterations. Examples of what we classify as hardings are adding or improving security headers of web apps (such as CSP headers) or redundant integrity checks on transmitted data.

Result: A CVE will not be submitted

Exposure

As described above, a common misconfiguration that allows a user to see sensitive data of which they're not privy. This does not include data such as stack traces or internal IDs, as they relay nothing which is either not public or already publicly known through the source code.

Result: A CVE will be submitted

Vulnerability in an underlying library

As our products make use of various 3rd party libraries, vulnerabilities may in time be reported in them (along with their respective CVEs). If we find that any of these vulnerabilities cause similar issues in existing versions of our products, we will submit our own CVE along with releasing patches.
Result: A CVE will be submitted

Our First CVEs

Thanks to Matthias Kaiser of Apple Information Security, who performed some very diligent penetration testing, we have submitted the following CVEs for EJBCA:

Cheers,

Mike Agrenius Kushner

Product Owner EJBCA

Wednesday, April 22, 2020