JPCERT/CC Eyes

Hello and Happy Holiday Season to everybody.

Taki again, and today I will write about some experiences in product (software, hardware) vulnerability coordination this year.

 - Introduction -

A lot happened this year and I do not have the time to go through everything, but would like to go over some of the major issues that we handled and for those that are not familiar, provide a very brief overview of our coordination activities.

Before I move on, our vulnerability advisories are published at Japan Vulnerability Notes (JVN). Other CSIRTs across the globe have their own sites like this, such as CERT/CC and NCSC-FI. While CERT/CC publishes quite a few advisories each year, NCSC-FI only publishes several high-profile issues each year that affect a large number of users.

The number of published advisories on JVN is shown below.

[Figure 1 - Number of product vulnerability-related advisories published on JVN per quarter since the 2^nd quarter of 2011 (Source: JPCERT/CC)]

What can be seen on JVN are advisories for vulnerabilities in products, which directs users to fixes, updates, patches, etc. for products in use. However, what is seen here is merely a small portion of the work that is involved in our vulnerability handling activities.

We coordinate the disclosure of product vulnerabilities with developers, researchers so that they do not become 0-days, where information about a vulnerability is disclosed without a way for the user to resolve it. Some of you may have heard the phrase "Coordinated Disclosure," which is what we attempt to do.

 - This Year -

This past year, we were involved in a few high profile cases which even received media attention.

 One of these issues was the so-called "Heartbleed" vulnerability in OpenSSL. There are quite a few articles on the web that describe the disclosure timeline, so I will not get into those details here. As an aside, here is a previous entry that describes how Japanese organizations dealt with Heartbleed.

We received information on this issue a few days prior to disclosure from one of our global counterparts. As we were about to begin the coordination process with developers the issue was disclosed by the OpenSSL team.

This case taught us (again!) that while reports may be sent to us in a confidential manner, this does not mean that we are the only ones that have this information.

[Figure 2 - Sample image of vulnerability handling information flow during a coordination effort (What a mess!) (Source: JPCERT/CC)]

This is especially true in cases that involve open-sourced software. There were quite a few high-profile advisories involving OpenSSL this year (CCS Injection, POODLE attack, etc.) which eventually led to the OpenSSL team releasing a new security policy  related to addressing vulnerabilities.

 Pre-disclosure, or notification prior to public disclosure for such open source products have been done through mailing lists or sending separate e-mails to relevant parties. Now most major open source projects only pre-disclose with certain groups of developers that need fixes first and then the rest of the world gets to know about the issue at the same time. This is also true with software provided by the Internet Systems Consortium (ISC), such as BIND.

- The next step in vulnerability handling -

The experiences that I had over this past year have shown me that not only are more and more people looking for vulnerabilities, but this information is moving around at such high speeds to a variety of parties, where in some cases, have no idea that another particular group has that information.

In general, the fewer parties involved in a coordination effort, the better. Not only does this reduce the probability that the information gets disclosed prematurely, but it also provides the developer better control as to how this non-public vulnerability information is being handled.

As a coordination center, we serve as the intermediary between the reporter and developer. If a reporter can report and communicate with the developer directly, then I believe they should do so. Our involvement in such a case is not necessary and in fact is a loss of time since each communication has to go through an additional party.

However for cases involving open sourced software that is implemented in various products, further coordination becomes necessary and this is where we can (and have been able to) provide value in a coordination effort.

Vulnerability handling has been evolving from a series of one-to-one communications to where various parties (that are often not in contact with each other) are involved in a single case at the same time. Hopefully we can continue to evolve with the times so that we can provide maximum value to a vulnerability coordination effort so that the proper information is being sent to relevant parties.

I wish everybody a safe and wonderful holiday season!

Takayuki (Taki) Uchiyama