遠端主機上安裝的 openssl 版本為 1.0.2k-19 之前版本。因此，會受到 ALAS2-2021-1608 公告中所提及的多個弱點影響。

  - OpenSSL 1.0.2 支援 SSLv2。如果用戶端嘗試與設定為支援 SSLv2 以及較新的 SSL 和 TLS 版本的伺服器交涉 SSLv2，則在取消填補 RSA 簽章時會檢查是否有版本復原攻擊。支援 SSLv2 以上版本 SSL 或 TLS 的用戶端應使用特殊的填補形式。支援 SSLv2 以上版本的伺服器應拒絕存在此特殊填補形式之用戶端的連線嘗試，因為這表示發生版本回溯 (即用戶端和伺服器皆支援 SSLv2 以上版本，但這是所要求的版本)。此填補檢查的實作會反轉邏輯，以便在有填補的情況下接受連線嘗試，而在沒有填補的情況下拒絕連線嘗試。這表示，伺服器將在發生版本復原攻擊時接受連線。此外，如果嘗試進行一般 SSLv2 連線，伺服器會錯誤地拒絕連線。僅 1.0.2s 至 1.0.2x 版的 OpenSSL 1.0.2 伺服器受到此問題影響。1.0.2 伺服器要受到攻擊，必須滿足下列條件：1) 編譯時已設定 SSLv2 支援 (預設為停用)，2) 在執行階段已設定 SSLv2 支援 (預設為停用)，3) 已設定 SSLv2 加密套件 (這些不在預設的加密套件清單中) OpenSSL 1.1.1 不支援 SSLv2，因此不易受此問題影響。RSA_padding_check_SSLv23() 函式實作中有基礎錯誤。這也會影響其他多種函式所使用的 RSA_SSLV23_PADDING 填補模式。雖然 1.1.1 版不支援 SSLv2，但 RSA_padding_check_SSLv23() 函式仍然存在，RSA_SSLV23_PADDING 填補模式亦如此。直接呼叫該函式或使用該填補模式的應用程式將會遇到此問題。
    不過，由於 1.1.1 版不支援 SSLv2 通訊協定，因此在該版本中，此問題將被視為錯誤，而非安全性問題。OpenSSL 1.0.2 不在支援範圍，亦不再接收公開更新。
    OpenSSL 1.0.2 的高級支援客戶應升級至 1.0.2y。其他使用者應升級至 1.1.1j。
    已在 OpenSSL 1.0.2y 中修正 (受影響的版本為 1.0.2-1.0.2w)。(CVE-2021-23839)

  - 在某些情況下，若輸入長度接近平台上整數的最大允許長度，呼叫 EVP_CipherUpdate、EVP_EncryptUpdate 和 EVP_DecryptUpdate 可能造成輸出長度引數溢位。在此類情況下，函式呼叫的傳回值將為 1 (表示成功)，但輸出長度值將為負值。這可造成應用程式的行為不正確或損毀。
    OpenSSL 1.1.1i 及以下版本受到此問題影響。這些版本的使用者應升級至 OpenSSL 1.1.1j。OpenSSL 1.0.2x 及以下版本受到此問題影響。但 OpenSSL 1.0.2 不在支援範圍，亦不再接收公開更新。OpenSSL 1.0.2 的高級支援客戶應升級至 1.0.2y。其他使用者應升級至 1.1.1j。已在 OpenSSL 1.1.1j 中修正 (受影響的版本為 1.1.1-1.1.1i)。
    已在 OpenSSL 1.0.2y 中修正 (受影響的版本為 1.0.2-1.0.2x)。(CVE-2021-23840)

  - OpenSSL 公開 API 函式 X509_issuer_and_serial_hash() 嘗試根據 X509 憑證中所含的簽發者和序號資料建立唯一的雜湊值。但是，它無法正確處理剖析簽發者欄位時可能發生的任何錯誤 (如果簽發者欄位遭到惡意建構，則可能發生此類錯誤)。之後，這可能導致 NULL 指標解除參照和當機，進而導致潛在的拒絕服務攻擊。OpenSSL 本身絕不會直接呼叫 X509_issuer_and_serial_hash() 函式，因此只有在直接使用此函式，並在可能是從未受信任來源取得的憑證上使用時，應用程式才會受到影響。OpenSSL 1.1.1i 及以下版本受到此問題影響。這些版本的使用者應升級至 OpenSSL 1.1.1j。OpenSSL 1.0.2x 及以下版本受到此問題影響。但 OpenSSL 1.0.2 不在支援範圍，亦不再接收公開更新。OpenSSL 1.0.2 的高級支援客戶應升級至 1.0.2y。其他使用者應升級至 1.1.1j。已在 OpenSSL 1.1.1j 中修正 (受影響的版本為 1.1.1-1.1.1i)。已在 OpenSSL 1.0.2y 中修正 (受影響的版本為 1.0.2-1.0.2x)。(CVE-2021-23841)

請注意，Nessus 並未測試此問題，而是僅依據應用程式自我報告的版本號碼。

遠端主機上安裝的 Junos OS 版本受到 JSA69715 公告中提及的多個弱點影響。

  - Raccoon 攻擊惡意利用了 TLS 規格中的一個瑕疵，可導致攻擊者能夠在使用 Diffie-Hellman (DH) 型加密套件的連線中計算 pre-master 密碼。在這種情況下，這會導致攻擊者能夠竊聽透過該 TLS 連線傳送的所有加密通訊。只有當實作在多個 TLS 連線中重複使用 DH 密碼時，才能惡意利用此攻擊。請注意，此問題只會影響 DH 加密套件，而不會影響 ECDH 加密套件。
    此問題會影響 OpenSSL 1.0.2 ，其不再支援且不再接收公開更新。OpenSSL 1.1.1 不受此問題影響。已在 OpenSSL 1.0.2w 中修復 (受影響的是 1.0.2-1.0.2v)。(CVE-2020-1968)

  - X.509 GeneralName 類型是用於代表不同類型名稱的泛型類型。其中一種名稱類型稱為 EDIPartyName。OpenSSL 會提供一個 GENERAL_NAME_cmp 函式，該函式可比較 GENERAL_NAME 的不同執行個體，判斷其是否相等。兩個 GENERAL_NAME 都包含 EDIPARTYNAME 時，此函式的行為不正確。可能發生 NULL 指標解除參照和損毀問題，進而可能導致拒絕服務攻擊。出於以下兩個目的，OpenSSL 本身會使用 GENERAL_NAME_cmp 函式：1) 比較可用 CRL 和內嵌在 X509 憑證中的 CRL 發佈點之間的 CRL 發佈點名稱 2) 驗證時間戳記回應權杖簽署者是否符合時間戳記授權單位名稱時 (透過 API 函式 TS_RESP_verify_response 和 TS_RESP_verify_token 洩漏)，如果攻擊者可同時控制比較的兩個項目，則可觸發損毀。例如，如果攻擊者可誘騙用戶端或伺服器針對惡意 CRL 檢查惡意憑證，則可能發生此問題。請注意，部分應用程式會根據憑證中內嵌的 URL 自動下載 CRL。此檢查在驗證憑證和 CRL 的簽章之前進行。
    OpenSSL 的 s_server、s_client 和驗證工具支援實作 CRL 自動下載的 -crl_download 選項，且已證明此攻擊可針對這些工具發動。請注意，不相關錯誤表示受影響的 OpenSSL 版本無法剖析或建構 EDIPARTYNAME 的正確編碼。不過，可以建構 OpenSSL 剖析器會接受的格式錯誤的 EDIPARTYNAME，進而觸發此攻擊。所有 OpenSSL 1.1.1 和 1.0.2 版本皆受到此問題影響。
    其他 OpenSSL 版本不在支援範圍內，且尚未經過檢查。已在 OpenSSL 1.1.1i 中修正 (受影響的為 1.1.1-1.1.1h)。已在 OpenSSL 1.0.2x 中修正 (受影響的為 1.0.2-1.0.2w)。(CVE-2020-1971)

  - 在 OpenSSL 內部，ASN.1 字串以 ASN1_STRING 結構表示，其中包含一個保留字串資料的緩衝區，以及一個保留緩衝區長度的欄位。與此相對照的是，一般 C 字串表示為以 NUL (0) 位元組結束的字串資料緩衝區。雖然不是嚴格要求，但使用 OpenSSL 自己的 d2i 函式 (和其他類似剖析函式) 剖析 ASN.1 字串，以及已使用 ASN1_STRING_set() 函式設定值的任何字串，都會以額外的 NUL 結束 ASN1_STRING 結構中的位元組陣列。但是，應用程式可以透過直接設定 ASN1_STRING 陣列中的資料和長度欄位，直接建構非以 NUL 結束位元組陣列的有效 ASN1_STRING 結構。使用 ASN1_STRING_set0() 函式也可發生此情況。目前發現多個列印 ASN.1 資料的 OpenSSL 函式會假設 ASN1_STRING 位元組陣列將以 NUL 結束，但直接建構的字串並不一定如此。若應用程式要求列印 ASN.1 結構，且該 ASN.1 結構包含由應用程式直接建構的 ASN1_STRING，並且非以 NUL 結束資料欄位，則可能發生讀取緩衝區滿溢。在處理憑證的名稱限制期間也會發生同樣的情況 (例如，如果憑證是由應用程式直接建構，而非透過 OpenSSL 剖析函式載入，且憑證包含非以 NUL 結束的 ASN1_STRING 結構)。X509_get1_email()、X509_REQ_get1_email() 和 X509_get1_ocsp() 函式中也可能發生此情況。如果惡意執行者可造成應用程式直接建構 ASN1_STRING，然後透過其中一個受影響的 OpenSSL 函式加以處理，則可能會發生此問題。這可能會導致當機 (造成拒絕服務攻擊)。
    也可能導致私密記憶體內容 (例如私密金鑰或敏感的純文字) 洩漏。已在 OpenSSL 1.1.1l 中修復 (受影響的是 1.1.1-1.1.1k)。已在 OpenSSL 1.0.2za 中修正 (受影響的是 1.0.2-1.0.2y)。(CVE-2021-3712)

  - OpenSSL 1.0.2 支援 SSLv2。如果用戶端嘗試與設定為支援 SSLv2 以及較新的 SSL 和 TLS 版本的伺服器交涉 SSLv2，則在取消填補 RSA 簽章時會檢查是否有版本復原攻擊。支援 SSLv2 以上版本 SSL 或 TLS 的用戶端應使用特殊的填補形式。支援 SSLv2 以上版本的伺服器應拒絕存在此特殊填補形式之用戶端的連線嘗試，因為這表示發生版本回溯 (即用戶端和伺服器皆支援 SSLv2 以上版本，但這是所要求的版本)。此填補檢查的實作會反轉邏輯，以便在有填補的情況下接受連線嘗試，而在沒有填補的情況下拒絕連線嘗試。這表示，伺服器將在發生版本復原攻擊時接受連線。此外，如果嘗試進行一般 SSLv2 連線，伺服器會錯誤地拒絕連線。僅 1.0.2s 至 1.0.2x 版的 OpenSSL 1.0.2 伺服器受到此問題影響。1.0.2 伺服器必須滿足下列條件才容易遭到攻擊：1) 編譯時已設定 SSLv2 支援 (預設為停用)，2) 在執行階段已設定 SSLv2 支援 (預設為停用)，3) 已設定 SSLv2 加密套件 (這些不在預設的加密套件清單中) OpenSSL 1.1.1 不支援 SSLv2，因此不易受此問題影響。RSA_padding_check_SSLv23() 函式實作中有基礎錯誤。這也會影響其他多種函式所使用的 RSA_SSLV23_PADDING 填補模式。雖然 1.1.1 版不支援 SSLv2，但 RSA_padding_check_SSLv23() 函式仍然存在，RSA_SSLV23_PADDING 填補模式亦如此。直接呼叫該函式或使用該填補模式的應用程式將會遇到此問題。
    不過，由於 1.1.1 版不支援 SSLv2 通訊協定，因此在該版本中，此問題將被視為錯誤，而非安全性問題。OpenSSL 1.0.2 不在支援範圍，亦不再接收公開更新。
    OpenSSL 1.0.2 的高級支援客戶應升級至 1.0.2y。其他使用者應升級至 1.1.1j。
    已在 OpenSSL 1.0.2y 中修正 (受影響的版本為 1.0.2s-1.0.2x)。(CVE-2021-23839)

  - 在某些情況下，若輸入長度接近平台上整數的最大允許長度，呼叫 EVP_CipherUpdate、EVP_EncryptUpdate 和 EVP_DecryptUpdate 可能造成輸出長度引數溢位。在此類情況下，函式呼叫的傳回值將為 1 (表示成功)，但輸出長度值將為負值。這可造成應用程式的行為不正確或損毀。
    OpenSSL 1.1.1i 及以下版本受到此問題影響。這些版本的使用者應升級至 OpenSSL 1.1.1j。OpenSSL 1.0.2x 及以下版本受到此問題影響。但 OpenSSL 1.0.2 不在支援範圍，亦不再接收公開更新。OpenSSL 1.0.2 的高級支援客戶應升級至 1.0.2y。其他使用者應升級至 1.1.1j。已在 OpenSSL 1.1.1j 中修復 (受影響的版本為 1.1.1-1.1.1i)。
    已在 OpenSSL 1.0.2y 中修正 (受影響的版本為 1.0.2-1.0.2x)。(CVE-2021-23840)

  - OpenSSL 公開 API 函式 X509_issuer_and_serial_hash() 嘗試根據 X509 憑證中所含的簽發者和序號資料建立唯一的雜湊值。但是，它無法正確處理剖析簽發者欄位時可能發生的任何錯誤 (如果簽發者欄位遭到惡意建構，則可能發生此類錯誤)。之後，這可能導致 NULL 指標解除參照和當機，進而導致潛在的拒絕服務攻擊。OpenSSL 本身絕不會直接呼叫 X509_issuer_and_serial_hash() 函式，因此只有在直接使用此函式，並在可能是從未受信任來源取得的憑證上使用時，應用程式才會受到影響。OpenSSL 1.1.1i 及以下版本受到此問題影響。這些版本的使用者應升級至 OpenSSL 1.1.1j。OpenSSL 1.0.2x 及以下版本受到此問題影響。但 OpenSSL 1.0.2 不在支援範圍，亦不再接收公開更新。OpenSSL 1.0.2 的高級支援客戶應升級至 1.0.2y。其他使用者應升級至 1.1.1j。已在 OpenSSL 1.1.1j 中修復 (受影響的版本為 1.1.1-1.1.1i)。已在 OpenSSL 1.0.2y 中修正 (受影響的版本為 1.0.2-1.0.2x)。(CVE-2021-23841)

注意：Nessus 發現此裝置已啟用 J-Web [設定系統服務 web 管理 http(s)]。

2021 年 2 月 16 日，OpenSSL 發佈了針對 CVE-2021-23841、CVE-2021-23839 和 CVE-2021-23840 的安全性更新。先前版本的 Puppet Agent 中包含有弱點的 OpenSSL 版本。如需有關此弱點的更多資訊，請參閱 OpenSS 安全性公告。

請注意，Nessus 並未測試此問題，而是僅依據應用程式自我報告的版本號碼作出判斷。

遠端主機上安裝的 openssl11 為 1.1.1g-12 之前版本。因此，會受到 ALAS2-2021-1612 公告中所提及的多個弱點影響。

  - OpenSSL 1.0.2 支援 SSLv2。如果用戶端嘗試與設定為支援 SSLv2 以及較新的 SSL 和 TLS 版本的伺服器交涉 SSLv2，則在取消填補 RSA 簽章時會檢查是否有版本復原攻擊。支援 SSLv2 以上版本 SSL 或 TLS 的用戶端應使用特殊的填補形式。支援 SSLv2 以上版本的伺服器應拒絕存在此特殊填補形式之用戶端的連線嘗試，因為這表示發生版本回溯 (即用戶端和伺服器皆支援 SSLv2 以上版本，但這是所要求的版本)。此填補檢查的實作會反轉邏輯，以便在有填補的情況下接受連線嘗試，而在沒有填補的情況下拒絕連線嘗試。這表示，伺服器將在發生版本復原攻擊時接受連線。此外，如果嘗試進行一般 SSLv2 連線，伺服器會錯誤地拒絕連線。僅 1.0.2s 至 1.0.2x 版的 OpenSSL 1.0.2 伺服器受到此問題影響。1.0.2 伺服器要受到攻擊，必須滿足下列條件：1) 編譯時已設定 SSLv2 支援 (預設為停用)，2) 在執行階段已設定 SSLv2 支援 (預設為停用)，3) 已設定 SSLv2 加密套件 (這些不在預設的加密套件清單中) OpenSSL 1.1.1 不支援 SSLv2，因此不易受此問題影響。RSA_padding_check_SSLv23() 函式實作中有基礎錯誤。這也會影響其他多種函式所使用的 RSA_SSLV23_PADDING 填補模式。雖然 1.1.1 版不支援 SSLv2，但 RSA_padding_check_SSLv23() 函式仍然存在，RSA_SSLV23_PADDING 填補模式亦如此。直接呼叫該函式或使用該填補模式的應用程式將會遇到此問題。
    不過，由於 1.1.1 版不支援 SSLv2 通訊協定，因此在該版本中，此問題將被視為錯誤，而非安全性問題。OpenSSL 1.0.2 不在支援範圍，亦不再接收公開更新。
    OpenSSL 1.0.2 的高級支援客戶應升級至 1.0.2y。其他使用者應升級至 1.1.1j。
    已在 OpenSSL 1.0.2y 中修正 (受影響的版本為 1.0.2s-1.0.2x)。(CVE-2021-23839)

  - 在某些情況下，若輸入長度接近平台上整數的最大允許長度，呼叫 EVP_CipherUpdate、EVP_EncryptUpdate 和 EVP_DecryptUpdate 可能造成輸出長度引數溢位。在此類情況下，函式呼叫的傳回值將為 1 (表示成功)，但輸出長度值將為負值。這可造成應用程式的行為不正確或損毀。
    OpenSSL 1.1.1i 及以下版本受到此問題影響。這些版本的使用者應升級至 OpenSSL 1.1.1j。OpenSSL 1.0.2x 及以下版本受到此問題影響。但 OpenSSL 1.0.2 不在支援範圍，亦不再接收公開更新。OpenSSL 1.0.2 的高級支援客戶應升級至 1.0.2y。其他使用者應升級至 1.1.1j。已在 OpenSSL 1.1.1j 中修正 (受影響的版本為 1.1.1-1.1.1i)。
    已在 OpenSSL 1.0.2y 中修正 (受影響的版本為 1.0.2-1.0.2x)。(CVE-2021-23840)

  - OpenSSL 公開 API 函式 X509_issuer_and_serial_hash() 嘗試根據 X509 憑證中所含的簽發者和序號資料建立唯一的雜湊值。但是，它無法正確處理剖析簽發者欄位時可能發生的任何錯誤 (如果簽發者欄位遭到惡意建構，則可能發生此類錯誤)。之後，這可能導致 NULL 指標解除參照和當機，進而導致潛在的拒絕服務攻擊。OpenSSL 本身絕不會直接呼叫 X509_issuer_and_serial_hash() 函式，因此只有在直接使用此函式，並在可能是從未受信任來源取得的憑證上使用時，應用程式才會受到影響。OpenSSL 1.1.1i 及以下版本受到此問題影響。這些版本的使用者應升級至 OpenSSL 1.1.1j。OpenSSL 1.0.2x 及以下版本受到此問題影響。但 OpenSSL 1.0.2 不在支援範圍，亦不再接收公開更新。OpenSSL 1.0.2 的高級支援客戶應升級至 1.0.2y。其他使用者應升級至 1.1.1j。已在 OpenSSL 1.1.1j 中修正 (受影響的版本為 1.1.1-1.1.1i)。已在 OpenSSL 1.0.2y 中修正 (受影響的版本為 1.0.2-1.0.2x)。(CVE-2021-23841)

請注意，Nessus 並未測試此問題，而是僅依據應用程式自我報告的版本號碼作出判斷。

遠端主機上安裝的 AOS 版本低於 6.5.6.7。因此，它受到 NXSA-AOS-6.5.6.7 公告中所提及的多個弱點影響。

  - 1.9.30 版之前的 Linux 版 Intel(R) Ethernet Controller RDMA 驅動程式中存在存取控制不當弱點，未經驗證的使用者可藉此透過網路存取造成特權提升。
    (CVE-2023-25775)

  - 除了 CVE-2022-1292 中發現的 c_rehash shell 命令插入，程式碼審查還發現 c_rehash 指令碼未正確清理 shell 中繼字元以防止命令插入的其他情況。修復 CVE-2022-1292 後，未在指令碼中的其他位置發現雜湊憑證的檔案名稱可能會傳遞至透過 shell 執行的命令。某些作業系統會以自動執行的方式發佈此指令碼。在這類作業系統上，攻擊者可以透過指令碼的權限執行任意命令。c_rehash 指令碼的使用已過時，應由 OpenSSL rehash 命令列工具取代。已在 OpenSSL 3.0.4 中修復 (受影響的是 3.0.0、3.0.1、3.0.2、3.0.3)。已在 OpenSSL 1.1.1p 中修復 (受影響的是 1.1.1-1.1.1o)。已在 OpenSSL 1.0.2zf 中修復 (受影響的是 1.0.2-1.0.2ze)。(CVE-2022-2068)

  - 通常在 OpenSSL EC 群組中，總是存在一個輔助因子，並且該輔助因子用於抗旁路的程式碼路徑。不過，在某些情況下，可能使用明確的參數 (而非使用具名曲線) 建構群組。在這些情況下，這類群組可能沒有餘因式存在。即使所有參數都符合已知的具名曲線，也會發生這種情況。如果使用這類曲線，則 OpenSSL 會回復為非防旁路程式碼路徑，這在 ECDSA 簽名作業期間，可能會導致完整金鑰復原。為了易於受到影響，攻擊者必須能夠在使用 libcrypto 的應用程式正在使用不存在餘因式的明確參數時，建立大量簽章計時。為避免疑義，libssl 因為從不使用明確參數而不易受到影響。已在 OpenSSL 1.1.1d 中修正 (受影響的是 1.1.1-1.1.1c)。已在 OpenSSL 1.1.0l 中修正 (受影響的是 1.1.0-1.1.0k)。已在 OpenSSL 1.0.2t 中修正 (受影響的是 1.0.2-1.0.2s)。(CVE-2019-1547)

  - OpenSSL 含有目錄樹狀結構的內部預設值，其中它可以尋找組態檔，以及在 TLS 中用於驗證的憑證。此目錄最常稱為 OPENSSLDIR，並且可使用 --prefix / --openssldir 組態選項設定。若是 OpenSSL 1.1.0 和 1.1.1 版，mingw 組態目標會假設所產生的程式和程式庫安裝在類似 Unix 的環境中，而且用於程式安裝以及 OPENSSLDIR 的預設前置詞應該是「/usr/local」。不過，mingw 程式是 Windows 程式，因此會自行查看「C:/usr/local」的子目錄，可能全局皆可寫入，讓未受信任的使用者能夠修改 OpenSSL 的預設組態、插入 CA 憑證、修改 (或甚至取代) 現有的引擎模組等等。若是 OpenSSL 1.0.2，「/usr/local/ssl」會用作所有 Unix 和 Windows 目標 (包括 Visual C 組建) 上 OPENSSLDIR 的預設值。但在 1.0.2 上，不同 Windows 目標的一些建置指令會建議您指定自己的 --prefix。OpenSSL 1.1.1、1.1.0 和 1.0.2 版受到此問題影響。由於受影響部署的範圍有限，此問題被評估為低嚴重性，因此我們目前並未建立新版本。已在 OpenSSL 1.1.1d 中修正 (受影響的是 1.1.1-1.1.1c)。
    已在 OpenSSL 1.1.0l 中修正 (受影響的是 1.1.0-1.1.0k)。已在 OpenSSL 1.0.2t 中修正 (受影響的是 1.0.2-1.0.2s)。
    (CVE-2019-1552)

  - 在攻擊者收到解密嘗試成功或失敗的自動通知的情況下，攻擊者在傳送大量要解密的訊息之後，可利用 Bleichenbacher padding oracle 攻擊恢復 CMS/PKCS7 傳輸的加密金鑰，或解密任何之前以公開 RSA 金鑰加密的 RSA 加密訊息。如果應用程式將憑證與 CMS_decrypt 或 PKCS7_decrypt 函式的私密 RSA 金鑰一起使用，以選擇正確的收件者資訊進行解密，則它們不會受到影響。已在 OpenSSL 1.1.1d 中修正 (受影響的是 1.1.1-1.1.1c)。已在 OpenSSL 1.1.0l 中修正 (受影響的是 1.1.0-1.1.0k)。已在 OpenSSL 1.0.2t 中修正 (受影響的是 1.0.2-1.0.2s)。(CVE-2019-1563)

請注意，Nessus 並未測試這些問題，而是僅依據應用程式自我報告的版本號碼作出判斷。

遠端主機上安裝的 OpenSSL 為 1.0.2y 之前版本。因此，會受到 1.0.2y 公告中所提及的多個弱點影響。

  - OpenSSL 公開 API 函式 X509_issuer_and_serial_hash() 嘗試根據 X509 憑證中所含的簽發者和序號資料建立唯一的雜湊值。但是，它無法正確處理剖析簽發者欄位時可能發生的任何錯誤 (如果簽發者欄位遭到惡意建構，則可能發生此類錯誤)。之後，這可能導致 NULL 指標解除參照和當機，進而導致潛在的拒絕服務攻擊。OpenSSL 本身絕不會直接呼叫 X509_issuer_and_serial_hash() 函式，因此只有在直接使用此函式，並在可能是從未受信任來源取得的憑證上使用時，應用程式才會受到影響。OpenSSL 1.1.1i 及以下版本受到此問題影響。這些版本的使用者應升級至 OpenSSL 1.1.1j。OpenSSL 1.0.2x 及以下版本受到此問題影響。但 OpenSSL 1.0.2 不在支援範圍，亦不再接收公開更新。OpenSSL 1.0.2 的高級支援客戶應升級至 1.0.2y。其他使用者應升級至 1.1.1j。已在 OpenSSL 1.1.1j 中修復 (受影響的版本為 1.1.1-1.1.1i)。已在 OpenSSL 1.0.2y 中修正 (受影響的版本為 1.0.2-1.0.2x)。(CVE-2021-23841)

  - 在某些情況下，若輸入長度接近平台上整數的最大允許長度，呼叫 EVP_CipherUpdate、EVP_EncryptUpdate 和 EVP_DecryptUpdate 可能造成輸出長度引數溢位。在此類情況下，函式呼叫的傳回值將為 1 (表示成功)，但輸出長度值將為負值。這可造成應用程式的行為不正確或損毀。
    OpenSSL 1.1.1i 及以下版本受到此問題影響。這些版本的使用者應升級至 OpenSSL 1.1.1j。OpenSSL 1.0.2x 及以下版本受到此問題影響。但 OpenSSL 1.0.2 不在支援範圍，亦不再接收公開更新。OpenSSL 1.0.2 的高級支援客戶應升級至 1.0.2y。其他使用者應升級至 1.1.1j。已在 OpenSSL 1.1.1j 中修復 (受影響的版本為 1.1.1-1.1.1i)。
    已在 OpenSSL 1.0.2y 中修正 (受影響的版本為 1.0.2-1.0.2x)。(CVE-2021-23840)

  - OpenSSL 1.0.2 支援 SSLv2。如果用戶端嘗試與設定為支援 SSLv2 以及較新的 SSL 和 TLS 版本的伺服器交涉 SSLv2，則在取消填補 RSA 簽章時會檢查是否有版本復原攻擊。支援 SSLv2 以上版本 SSL 或 TLS 的用戶端應使用特殊的填補形式。支援 SSLv2 以上版本的伺服器應拒絕存在此特殊填補形式之用戶端的連線嘗試，因為這表示發生版本回溯 (即用戶端和伺服器皆支援 SSLv2 以上版本，但這是所要求的版本)。此填補檢查的實作會反轉邏輯，以便在有填補的情況下接受連線嘗試，而在沒有填補的情況下拒絕連線嘗試。這表示，伺服器將在發生版本復原攻擊時接受連線。此外，如果嘗試進行一般 SSLv2 連線，伺服器會錯誤地拒絕連線。僅 1.0.2s 至 1.0.2x 版的 OpenSSL 1.0.2 伺服器受到此問題影響。1.0.2 伺服器必須滿足下列條件才容易遭到攻擊：1) 編譯時已設定 SSLv2 支援 (預設為停用)，2) 在執行階段已設定 SSLv2 支援 (預設為停用)，3) 已設定 SSLv2 加密套件 (這些不在預設的加密套件清單中) OpenSSL 1.1.1 不支援 SSLv2，因此不易受此問題影響。RSA_padding_check_SSLv23() 函式實作中有基礎錯誤。這也會影響其他多種函式所使用的 RSA_SSLV23_PADDING 填補模式。雖然 1.1.1 版不支援 SSLv2，但 RSA_padding_check_SSLv23() 函式仍然存在，RSA_SSLV23_PADDING 填補模式亦如此。直接呼叫該函式或使用該填補模式的應用程式將會遇到此問題。
    不過，由於 1.1.1 版不支援 SSLv2 通訊協定，因此在該版本中，此問題將被視為錯誤，而非安全性問題。OpenSSL 1.0.2 不在支援範圍，亦不再接收公開更新。
    OpenSSL 1.0.2 的高級支援客戶應升級至 1.0.2y。其他使用者應升級至 1.1.1j。
    已在 OpenSSL 1.0.2y 中修正 (受影響的版本為 1.0.2s-1.0.2x)。(CVE-2021-23839)

請注意，Nessus 並未測試這些問題，而是僅依據應用程式自我報告的版本號碼作出判斷。

遠端主機上安裝的 IBM Cognos Analytics 版本低於 11.1.7 FP8、11.2.4 FP3 或 12.0.2。因此，該軟體受到 IBM 安全佈告欄 7123154 中所提及的多個弱點影響，包括下列項目：

  - 在還原序列化不受信任的或損毀的資料時，讀取器消耗的記憶體可能超出允許的限制，因而導致系統記憶體不足。此問題會影響使用 Apache Avro Java SDK 及之前版本的 Java 應用程式，包括 1.11.2。使用者應更新至 apache-avro 1.11.3 版，便可解決此問題。(CVE-2023-39410)

  - 為了解密 SM2 加密資料，應用程式應呼叫 API 函式 EVP_PKEY_decrypt()。通常，應用程式會呼叫此函式兩次。第一次進入時，「out」參數可以是 NULL，而在結束時，「outlen」參數會填入保留解密純文字所需的緩衝區大小。然後，應用程式可以配置足夠大的緩衝區，並再次呼叫 EVP_PKEY_decrypt()，但這次會為「out」參數傳遞一個非 NULL 值。SM2 解密程式碼實作中有一個錯誤，表示保留第一次呼叫 EVP_PKEY_decrypt() 傳回的純文字所需的緩衝區大小計算結果可能小於第二次呼叫所需的實際大小。當應用程式使用過小的緩衝區第二次呼叫 EVP_PKEY_decrypt() 時，這可導致緩衝區溢位。能夠向應用程式呈現 SM2 解密內容的惡意攻擊者可造成攻擊者選擇的資料溢出緩衝區最多 62 個位元組，進而改變保留在緩衝區之後的其他資料內容，這可能會改變應用程式行為或造成應用程式損毀。緩衝區的位置與應用程式相關，但通常是配置的堆積。已在 OpenSSL 1.1.1l 中修復 (受影響的是 1.1.1-1.1.1k)。(CVE-2021-3711)

  - SnakeYaml 的 Constructor() 類別未限制可在還原序列化期間具現化的類型。
  反序列化攻擊者提供的 yaml 內容可導致遠端程式碼執行。我們建議在剖析未受信任的內容時使用 SnakeYaml 的 SafeConsturctor，以限制還原序列化。我們建議升級至 2.0 或更新版本。(CVE-2022-1471)

請注意，Nessus 並未測試此問題，而是僅依據應用程式自我報告的版本號碼作出判斷。

ID	名稱	產品	系列	已發布	已更新	嚴重性
146628	Amazon Linux 2：openssl (ALAS-2021-1608)	Nessus	Amazon Linux Local Security Checks	2021/2/19	2024/12/11	low
166767	Juniper Junos OS 多個弱點 (JSA69715)	Nessus	Junos Local Security Checks	2022/11/1	2024/10/11	high
184148	Puppet Agent 6.x < 6.22.1 / 7.x < 7.6.1 弱點	Nessus	Windows	2023/11/1	2023/11/2	low
147910	Amazon Linux 2：openssl11 (ALAS-2021-1612)	Nessus	Amazon Linux Local Security Checks	2021/3/19	2024/12/11	low
212513	Nutanix AOS：多個弱點 (NXSA-AOS-6.5.6.7)	Nessus	Misc.	2024/12/11	2025/7/22	critical
146591	OpenSSL 1.0.2 < 1.0.2y 多個弱點	Nessus	Web Servers	2021/2/19	2024/10/23	low
193868	IBM Cognos Analytics 11.1.1 < 11.1.7 FP8/11.2.x < 11.2.4 FP3/12.0.x < 12.0.2 (7123154)	Nessus	CGI abuses	2024/4/25	2024/12/18	critical

偵測

搜尋 Plugin

low

high

low

low

critical

low

critical