Instructions
JVN#XXXXXXXX (Vulnerability ID)
A Vulnerability ID is a unique number assigned to each vulnerability information. IDs such as JVN#ABCD1234 (prefix JVN#) assigned to vulnerability information reported in Japan. IDs such as JVNTA00-001A and JVNVU#123456 (prefix JVNVU#) are assigned to US-CERT Technical Cyber Security Alerts and Vulnerability Notes respectively. IDs such as CPNI-123456 are assigned to vulnerability information provided by CPNI.
By using the corresponding ID, it is easier for readers to recognize that those reports refer to the same vulnerability.
| Vulnerability ID System | ||
|---|---|---|
| Information provider | Vulnerability ID used by the information provider | Vulnerability ID used on the JVN website |
| IPA, JPCERT/CC | JVN#12345678 | JVN#12345678 |
| CERT/CC, US-CERT | TA99-123A | JVNTA99-123A |
| VU#123456 | JVNVU#123456 | |
| CPNI | CPNI-123456 | CPNI-123456 |
Title
The Title indicates which system (product) contains a vulnerability and the type of the vulnerability.
Critical
A vulnerability will be indicated as Critical, when it has a serious impact on susceptible systems (products) or anything related to these systems, or when JPCERT/CC recommends immediate application of patches or workarounds.
The word "Critical" is also shown next to its vulnerability ID in the Recent Vulnerability Notes section on the JVN top page.
Please note that the actual severity depends on the environment in which the products are used and the importance of business operations carried out by these products. Therefore, the necessity of urgent implementation of the solution must be determined by individual organizations after understanding the vulnerability information.
The following cases will be subject to the Critical indication:
- Arbitrary code can be remotely executed. The shell can be accessed. The system can be fully controlled.
- Actual attacks or damage have been observed.
- An SQL injection or command injection has been executed.
- A denial-of-service (DoS) attack on the mission-critical Internet service has been observed.
Overview
This section provides an overview of the vulnerability. This is a so-called executive summary and is designed for individuals who need to decide whether or not more detailed information is required.
Products Affected
Names and version numbers of products affected by the vulnerability are listed.
Description
This section provides detailed description of the vulnerability.
Impact
This section provides a possible impact when the vulnerability is exploited.
Prerequisites of an attack are also described here (e.g., an attacker needs to have logged into the system as an administrator prior to the attack).
Solution
This section provides solutions to the vulnerability.
There are two types of solutions. One is to update or upgrade the product to resolve the vulnerability.
The other is to apply workarounds to mitigate the impact of the vulnerability.
Vendor Status
1. What is Vendor Status?
Vendor Status provides information from vendors (product developers). The vendor status includes information from the vendors registered in the JPCERT/CC Product Developers List.
| Vendor | Status | Last Update | Vendor Notes |
|---|---|---|---|
| XXX, Inc. | Vulnerable | YYYY.MM.DD | XXX Vulnerability |
2. Status
Status shows the existence of affected products, products under investigation, etc and is linked to the vendor statement page.
Each status refers to one of the conditions shown below:
| Status | Description |
|---|---|
| Vulnerable | There are products affected by the vulnerability. |
| Vulnerable, investigating | The vendor has found an affected product, and still continues investigation. |
| Not Vulnerable | There are no products affected by the vulnerability. |
| Not Vulnerable, investigating | The vendor has not yet found affected products, and still continues investigation. |
| Unknown | JPCERT/CC has not received a vendor statement yet. |
3. Last Update
The date shows the last date when JPCERT/CC received the vendor statement.
4. Vendor Notes
Vendor Notes provides links to advisories on the vulnerability that are released on the vendor's websites.
5. Vendors that are on the Vendor Status Table and vendors that are not
Vendor Status Table contains the registered vendors, if one of the following is the case
- "Vendors notify JPCERT/CC of the vendor status.
- "Vendors have received detailed vulnerability information from JPCERT/CC.
6. Links to other websites
When vendors not in the JPCERT/CC Product Developers List release information on the vulnerability, links to that information may be listed as shown below:
| Vendor | URL |
|---|---|
| XXX Corporation | Security Patch for XXXX |
References
This section provides links to documents released by other CSIRT organizations or security vendors.
JPCERT/CC Addendum
This section provides additional information from JPCERT/CC.
Severity Analysis by JPCERT/CC
1. What is Severity Analysis by JPCERT/CC?
JPCERT/CC analyzes how severe a vulnerability is from several view points. The estimation helps those who actually implement solutions to the vulnerability understand the severity of the vulnerability
2. Example
| Measures | Analysis | Severity |
|---|---|---|
| Access required | Routed - can be attacked over the Internet using packets |
|
| Authentication | None - anonymous or no authentication (IP addresses do not count) |
|
| User interaction required | Simple - the user must be convinced to take a standard action that does not feel harmful to most users, such as click on a link or view a file |
|
| Exploit complexity | large amount of expertise and/or luck required (BIOS expertise, guessing correctly in a large space) |
|
There are four analysis scales: "access required", "authentication", "user interaction required", and "exploit complexity." The detail of each analysis scale is as described below.
3. Access required
This questions asks the level of physical/virtual proximity required to exploit this vulnerability.
- Routed - can be attacked over the Internet using packets
- Non-rouetd - must be attacked from a local segment, such as Ethernet, Bluetooth,and 802.11 attacks
- Local - requires you to login into the box to a shell or remote desktop
- Physical - requires you to touch the box
4. Authentication
This questions asks the level of authentication required to exploit the vulnerability.
- None - anonymous or no authentication (IP addresses do not count)
- Limited - self-registration, perhaps valid e-mail
- Standard - login caused to be created by an administrator
- Privileged - a particular login or set there of is required (root, bin, etc.)
5. User interaction required
For vulnerabilities that require an honest user (perhaps the victim) to take an action, how difficult is getting that action to occur at the right time?
- None - the vulnerability can be exploited without an honest user taking any action
- Simple - the user must be convinced to take a standard action that does not feel harmful to most users, such as click on a link or view a file
- Complex - the user must be convinced to take a difficult or suspicious action. If the honest user must have elevated privileges, they are likely to be more suspicious.
6. Exploit complexity
This questions asks the level of technical difficulty that an attacker faces for successful exploitation
- Low - little to no expertise and/or luck required to exploit (cross-side scripting).Expected to be the common response
- Low-Medium - some expertise and/or luck required (most buffer overflows, guessing correctly in small space, expertise in Windows function calls)
- Medium-High - expertise and/or luck required (guessing correctly in mediumsized space, kernel expertise)
- Hight - large amount of expertise and/or luck required (BIOS expertise, guessing correctly in a large space)
Credit
Individuals or organizations that identified and reported the vulnerability are listed here unless they do not wish to be credited.
Other Information
This section provides related alerts and advisories, including JPCERT Alert, JPCERT REPORT, CERT Advisory, CPNI Advisory, TRnotes, CVE, and JVN iPedia.
Note
On April 25, 2007, the JVN design was renewed to include the sections of Description, Solution, JPCERT/CC addendum, and Severity Analysis by JPCERT/CC. Therefore, vulnerability notes released prior to this date may not have the information listed above.