GSS 資安電子報 0247 期【避免漏洞版本！Java 的安全關鍵：CPU 快速修補、PSU 完整防護 】

在本文中，您將了解：

• 每個 Java 版本常見的安全漏洞。
• 安全更新版本 Critical Patch Updates（CPU） 如何修補這些漏洞。
• 並非所有 Java 供應商都提供 CPU，而 CPU 對於確保企業 Java 環境的安全性與穩定性至關重要。
• Azul Core 與 Oracle 同步，提供 CPU 與完整修補更新（Full Patch Updates）。
• Azul Core 為 JDK 6、7、8、11、17、21 與 25 提供完整支援版本，並在適用情況下回補所有安全性修補程式（Security Patches）。

最近，Azul 副技術長 Simon 與一位金融業的 Java 使用者討論採用 Azul Core 執行多項應用程式的可能性。其中，對於關鍵任務（Mission-Critical）的企業應用而言，最大的優勢之一，就是能夠及時取得最新的安全修補程式（Security Patches）與錯誤修正（Bug Fixes）。使用 Azul Core，企業可在更新情報解禁後，立刻依照既定的服務水準協議（SLA）取得相關更新。

當企業處理敏感資料，甚至涉及龐大金額的資金時，資訊安全更是不容忽視。然而，讓Simon有些意外的是，對方卻表示：「我們並不擔心安裝 Java 更新，因為核心銀行系統都部署在防火牆後面。」

Simon 表示：「我並非電腦安全領域的專家，但這樣的想法仍令我感到相當訝異。」真正有效的安全防護，應採取多層次（Multi-layered）的防禦策略，並在修補程式發布後，盡快修補所有可能存在的漏洞。

也因此， Simon 開始深入研究這個議題，希望能提出更具說服力的論點，說明企業為什麼應該持續更新其 Java 執行環境。

為什麼必須持續更新 Java？

首先必須了解的是，防火牆對於保護網路的作用其實相當有限。防火牆採取的是被動（Reactive）的防護模式，只能限制封包是否能夠傳送至內部主機。它確實可以用來封鎖特定連接埠（Port）、丟棄格式異常的封包、拒絕過小或過大的封包等。然而，真正的風險是來自那些被允許通過的封包。

更大的問題在於，自從人們開始開發軟體以來，就一直有人試圖以開發者原本未預期的方式利用這些軟體，而且往往是出於惡意目的，例如竊取信用卡資料或使用者身分。我們通常將這類能夠突破電腦安全防護的人稱為駭客（Hacker）。為了達成目的，駭客會採用各種不同的攻擊手法，從誘騙使用者洩露機密資訊的網路釣魚（Phishing），到利用緩衝區溢位（Buffer Overflow）等技術對軟體進行複雜攻擊，而如今這些攻擊更逐漸結合 AI 工具，大幅提升攻擊的效率與規模。

不幸的是，軟體越複雜，越可能存在可被駭客利用的漏洞。最新的 AI 模型（如 Claude Mythos）展現出極為出色的漏洞發掘能力，使這些潛在弱點更容易被發現與利用。Java Development Kit（JDK） 本身就是一套相當複雜的軟體，因此也可能存在安全漏洞。

Java 漏洞概述

在進一步探討之前，先了解安全漏洞的描述與分類方式，將有助於理解後續內容。

幾乎所有軟體或平台的安全漏洞，都會以 CVE（Common Vulnerabilities and Exposures，常見漏洞與曝險） 的形式公開揭露。這份 CVE 清單由非營利組織 MITRE 維護，收錄所有已公開揭露的資安漏洞，並免費提供查詢與使用。

每一個 CVE（即漏洞描述）都會對應一個 CVSS（Common Vulnerability Scoring System，通用漏洞評分系統） 分數，範圍介於 0.0 至 10.0。CVSS 分數是根據多項指標計算而來，包含基本（Base）、時間（Temporal）及環境（Environmental）三大類，用於評估漏洞的攻擊複雜度、是否需要特殊權限、是否可透過網路遠端利用等因素。

依照 CVSS 分數，漏洞風險等級可分為：

• 低風險（Low）： 0.1–3.9
• 中風險（Medium）： 4.0–6.9
• 高風險（High）： 7.0–8.9
• 重大風險（Critical）： 9.0–10.0

一個充分說明為何軟體必須及時套用安全修補程式的案例，就是美國消費者信用報告機構 Equifax 遭受的大規模資料外洩事件。Equifax 部署了多層防火牆，這些防火牆也確實執行了防火牆應有的功能，但最終仍無法阻止這次攻擊。攻擊者最初是透過 Credit Dispute 網站入侵企業網路，而該網站本身就是允許經由防火牆正常存取的服務。該網站採用了廣泛使用的 Apache Struts 框架（以 Java 開發）來產生動態網頁。

2017 年 3 月，Apache 發現 Apache Struts 存在一項安全漏洞，並發布修補程式，同時建議所有使用者應盡快完成更新。該漏洞編號為 CVE-2017-5638，CVSS 評分高達 10.0，屬於最高等級的重大漏洞，且極易遭到利用。然而，Equifax 並未及時更新其 Apache Struts 系統，導致駭客成功辨識出仍存在漏洞的伺服器。攻擊者透過在 HTTP Header 中植入特定的 Content-Type 值，成功在伺服器上執行系統命令，發動典型的遠端程式碼執行（Remote Code Execution，RCE）攻擊。

這項漏洞成為駭客入侵 Equifax 內部網路的入口，不僅導致 1.43 億名用戶的金融資料外洩，還使數十個敏感資料庫遭到存取。更嚴重的是，駭客甚至在 Equifax 的資訊系統中建立了 30 多個持續存取的入侵據點（Entry Points）。

在駭客入侵被發現之前的兩個月內，防火牆始終運作正常，傳送至 Apache Struts 的封包在結構與大小上都沒有任何異常，對防火牆而言完全屬於合法流量，因此防火牆不會加以攔截。

或許你會認為，Java 問世至今已有 30 年，也是全球最廣泛使用的軟體平台之一，所有可能的安全漏洞應該早已被發現並修補。然而，若仔細檢視 JDK，就會發現它包含超過 370 萬行程式碼（這個數字是 Simon 透過 cloc 統計 JDK 26 所得）。面對如此龐大的程式碼規模，幾乎不可能斷言其中不存在任何安全漏洞。Java 並非不安全，而是因為它功能強大、架構複雜，因此仍可能存在尚未被發現的漏洞。

每次 Java 更新中修補的 CVE 漏洞

接下來，我們來看看持續更新 JDK 對於維持 Java 環境安全性與穩定性的重要性。Simon 根據每次 Java 更新的 Release Notes 所提供的資訊，整理了 JDK 已修補的 CVE 漏洞統計資料。

首先，下表列出了 自 2019 年 4 月以來，各次 Java 更新中所修補的最高 CVSS 評分漏洞。之所以選擇 2019 年 4 月作為起點，是因為 Oracle 自該時間點起，不再提供 JDK 8 與 JDK 11 的免費商業應用更新。

如您所見，自 2019 年 4 月以來，JDK 雖然沒有再出現 CVSS 評分為 Critical（9.0–10.0） 的漏洞，但約有 60% 的更新都至少修補了一項高風險（High）漏洞。而在最近九次 Java 更新中，只有一次沒有包含高風險 CVE。

Simon 也進一步統計了 JDK 8 自 2015 年 1 月以來所修補的漏洞總數，並依 CVSS 風險等級進行分類如下：

• 低風險（Low）： 96
• 中風險（Medium）： 212
• 高風險（High）： 69
• 重大風險（Critical）： 68（其中 24 項的 CVSS 評分高達 10.0）

這表示，過去 11 年間，JDK 共修補了 444 項安全漏洞。其中包含 68 項重大（Critical）CVE，足以說明企業應持續將 JDK 更新至最新版本，以確保應用程式維持最高等級的安全防護。

如何透過更新 Java 維持安全性？

Azul 為每次 Java 更新提供兩種不同的版本：Critical Patch Update（CPU） 與 Patch Set Update（PSU）。

CPU 僅包含修補安全漏洞所需的變更；而 PSU 則除了涵蓋所有 CPU 的安全修補外，還包含其他錯誤修正（Bug Fixes）、小幅功能改善（Minor Enhancements）等更新。

之所以區分為兩種更新版本，是為了讓企業能在發現重大安全漏洞時，快速部署修補程式。由於 CPU 的變更範圍較小，因此對應用程式穩定性的影響較低，也較不容易因更新而導致應用程式無法正常運作。完成基本驗證（Touch Testing）後，即可快速部署 CPU，讓應用程式在最短時間內獲得最新的安全防護。

至於 PSU，企業則可投入較充裕的時間進行完整測試，例如執行全面性的回歸測試（Regression Testing），確認更新不會影響既有功能後，再部署至正式環境。透過這樣的更新策略，企業既能快速修補安全漏洞，也能兼顧應用程式的穩定性。

需要特別注意的是，並非所有 OpenJDK 發行版本供應商都清楚區分 CPU 與 PSU 的差異。有些供應商將其更新版本稱為 CPU，但實際上提供的卻是 PSU。因此，在部署更新之前，企業應仔細確認所取得的更新內容究竟包含哪些修補項目。

CPU 與 PSU 分開提供的優勢，可從 2020 年 7 月的更新案例中看出。當時，一項錯誤修正（Bug Fix）本身意外引入了新的回歸問題（Regression），導致 Hadoop Cluster、Solr 與 Lucene 等高使用率軟體無法穩定運作，對依賴這些技術的關鍵任務（Mission-Critical）應用而言，影響相當嚴重。

由於這項回歸問題並非源自安全修補，因此並未包含在 CPU 中。這也意味著，採用 CPU 的企業可以先快速完成安全漏洞修補，而不會受到這次功能性回歸問題的影響。

這項回歸問題最終透過「修正原修補程式的修補程式」獲得解決。針對 JDK 8，該修正版本以 Update 265 的形式於 7 月 27 日發布，距離原定的 7 月更新版本發布時間已相隔 12 天。而最初的更新版本中，包含一項修補 CVSS 基本分數（Base Score）達 8.3 的 CVE 漏洞修正，相關漏洞細節也已公開於 Release Notes 中。

如果企業使用了受影響的軟體系統，而手上只有包含所有變更的 PSU 更新版本，那麼在等待回歸問題修正期間，駭客將有接近兩週的時間嘗試利用該已公開的漏洞。

但如果企業同時能取得 CPU 更新版本，就可以先部署必要的安全修補程式，立即降低系統遭受攻擊的風險；同時等待修正版 PSU 發布後，再進行完整測試與部署。如此一來，企業既能即時強化安全防護，也能避免因未經充分驗證的更新影響應用程式穩定性。

維持 Java 安全

Azul Core，專為希望確保系統同時具備最高安全性與穩定性的使用者所設計。除了針對每次更新提供 CPU（僅包含安全修補） 與 PSU（完整更新） 兩種版本外，我們也致力於在 Oracle 發布其版本後，盡可能快速提供相應更新。

自 JDK 8 結束免費公開更新後，Azul Core 客戶已能在 Oracle 發布更新後 一小時內下載對應版本。實際上，這幾乎等同於與 Oracle 同步取得更新。

為了讓企業能以最簡單有效的方式維持 Java 安全並持續更新，Azul Core 提供 JDK 6、7、8、11、17、21 與 25 的完整支援版本，並在適用情況下回補所有安全性修補程式（Security Patches）。

既然我們已了解，不論 Java 使用哪個版本，都可能存在安全漏洞，現在正是檢視企業 Java Runtime 環境的時候。

無論是否屬於關鍵任務應用，安全性都應該是所有企業應用程式的首要考量。若要始終維持最高等級的安全性與穩定性，企業需要能即時取得所有 JDK 更新，包括 CPU 與 PSU 兩種形式的修補版本。您是否確定目前使用的 OpenJDK 發行版本，能提供企業真正需要的一切？

若對 Azul 有興趣歡迎留下資訊，將會有專人與您聯繫 ➤ https://www.gss.com.tw/product-services-nav/info-security/azul