Shulou(Shulou.com)06/01 Report--

This article is about how to make Java applications secure. Xiaobian thinks it is quite practical, so share it with everyone for reference. Let's follow Xiaobian and have a look.

Previously, the way most Java users accessed JDK updates changed. The reason for this is changes Oracle has made to the way JDK is developed and to the licensing terms of Oracle JDK.

Oracle JDK 11 and Oracle JDK 8 (starting with Update 211) now use the Oracle Technology Network License Agreement. This limits free use to only four situations:

Personal use (laptop or desktop for personal applications)

the development and use

Oracle-approved product usage

Oracle Cloud Infrastructure Usage

For all other cases, Java SE subscriptions must be purchased from Oracle.

This requires users to make decisions about their JDK deployment strategy. One such approach is "OK, it works fine on the JDK we have now; let's stick with it."

There is an obvious drawback to this, namely the impact that the decision will have on the security of the application.

Since people started developing software, others have struggled to find ways to use it in unexpected ways. This is usually done for malicious purposes, such as stealing credit card numbers or user identities. We use the term hacker to describe someone who is capable of breaking computer security. Hackers can achieve their goals in countless ways; from tricking people into leaking confidential information (phishing) to performing complex manipulations on software through techniques such as buffer overflows.

Unfortunately, the more complex the software, the more likely hackers are to exploit vulnerabilities. JDK is a very complex piece of software and therefore may contain vulnerabilities.

When vulnerabilities in software are discovered, they are usually recorded as Common Vulnerabilities and Exposures (CVE). The National Cyber Security FFRDC, operated by Mitre Corporation, maintains the CVE database. Each CVE identified by a unique number has a textual description of the vulnerability.

Each CVE has a Common Vulnerability Scoring System (CVSS) value. This is not included in CVE, but is maintained in the National Vulnerability Database hosted by the National Institute of Science and Technology (NIST). CVSS provides a base score and a set of metrics. The base score is a value between 0.1 and 10.0 indicating the severity of the vulnerability (technically, the base score starts at 0.0, but by definition anything with a score of zero is not a vulnerability). The base score is calculated from a set of indicators that indicate different aspects of the vulnerability. These metrics relate to such things as whether vulnerabilities can be exploited over the network and whether physical access to the machine is required.

0.0: None

0.1-3.9: Low

4.0-6.9: Medium

7.0-8.9: High

9.0-10.0: Serious

Let's see how important it is to keep your JDK up-to-date.

First, I reviewed the updates over the past three years and extracted the vulnerabilities with the highest CVSS base scores that were each addressed. This is shown in the table below.

Processor Date Highest CVSS Affected JDK Version July 2020 April 2020

January 2020

October 2019

July 2019

8.38.3(Multiple)

8.1

6.8(Multiple)

6.8

7、8、11、147、8、11、13、14

7、8、11、13

7、8、11、13

7、8、11、12

April 2019 9.08January 2019 6.16, 7, 8, 11October 2018 9.08,11July 2018 5.96, 7, 8, 10April 2018 8.36, 7, 8, 9, 10January 2018 8.3 (multiple) 6, 7, 8, 9October 2017 9.6 (multiple) 6,7,8, 92017 July 9.6 (multiple) 7,8

As you can see, most updates address at least one high-scoring vulnerability and address several critical vulnerabilities. When we limited it to updates after Oracle Java SE license changes, we still saw one with serious vulnerabilities and three with high vulnerabilities. Interestingly, the critical vulnerability addressed in the April 2019 update resides in the Windows DLL used to build JDK, not in any JDK code.

Next, I analyzed all the updates since January 2015, which are readily available information. Looking at all of the vulnerabilities addressed and dividing them into risk groups, we can generate a bar chart.

I split the key ones into two sections to highlight how many scored 10.

As you can see, a total of 320 CVEs were resolved, most of them in the low to medium range. The number of critical CVE's is 59, which makes you think about the importance of keeping JDK up to date.

However, there is one complication.

Oracle provides two different versions for each update; this is the same for all of their software. These are called Critical Patch Updates (CPU) and Patch Set Updates (PSU).

CPU contains only changes related to addressing security vulnerabilities. PSU provides all of these changes, as well as any other bug fixes, minor enhancements, etc. The reason for this is to roll out updates quickly when critical vulnerabilities need to be patched. Because the CPU contains a small set of changes, it is unlikely to have an impact on the stability of your application (i.e., it is unlikely to prevent your application from working). Once touch testing is done with the CPU, you can deploy it to ensure maximum security for your application. Then, you can spend more time testing the PSU (usually running a full suite of regression tests) before deploying it to production machines. This ensures maximum stability of your application.

One thing to note here is that not all OpenJDK binary providers understand the difference between CPU and PSU. Some people call their update CPU, when in fact it is PSU. Before deploying, you should look carefully at what you get.

To highlight the benefits of having both CPU and PSU, we just need to look at the July 2020 update. This includes fixing a bug that introduces regression itself. The impact of this regression is that heavily used software such as Hadoop Cluster, Solr, and Lucene no longer works reliably, which is a serious problem for mission-critical applications that use them. Regression is not included in the security patch and therefore is not included in the CPU.

A fix was released as Update 265 on July 27 (i.e., 12 days after the scheduled July update was released), thereby resolving the regression issue. The initial update contains fixes for CVE with a base score of 8.3, details of which are disclosed in the release notes. If you are using one of the affected software systems, if you only have all-inclusive PSU, hackers will have nearly two weeks to try to exploit it. If you also have access to the CPU, you can roll out the necessary security patches to protect your system from threats and then wait worry-free for the revised PSU to be released.

Azul's Zulu Enterprise version of OpenJDK is aimed at users who want to ensure that their systems provide the highest level of security and stability. In addition to providing CPU (secure) and PSU (full) versions of each update, we strive to deliver these updates as soon as Oracle releases their versions. Since the end of the free public update for JDK 8, Zulu Enterprise customers can download the update within an hour of Oracle's release. This is basically simultaneous.

In summary, it is clear how important it is to ensure that all systems running JVM-based applications are kept up to date.

Thank you for reading! About "how to ensure Java application security" this article is shared here, I hope the above content can be of some help to everyone, so that everyone can learn more knowledge, if you think the article is good, you can share it to let more people see it!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.