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

    openssl：SSL_free_buffers 存在釋放後使用弱點 (CVE-2024-4741)

    問題摘要：以空的受支援用戶端通訊協定緩衝區呼叫 OpenSSL API 函式 SSL_select_next_proto 可能會造成當機或記憶體內容被傳送至對等記憶體。

    影響摘要：緩衝區過度讀取可造成一系列潛在後果，例如非預期的應用程式行為或當機。特別是，此問題可導致最多 255 位元組的任意私人資料從記憶體傳送至對等記憶體，進而導致機密性喪失。但是，只有透過 0 長度的受支援用戶端通訊協定清單直接呼叫 SSL_select_next_proto 函式的應用程式才會受到此問題影響。這種情況通常不會發生，而且通常不受攻擊者控制，但在呼叫應用程式中發生設定或程式設計錯誤的情況下可能會意外發生。

    OpenSSL API 函式 SSL_select_next_proto 通常由支援 ALPN (應用程式層通訊協定交涉) 或 NPN (下一個通訊協定交涉) 的 TLS 應用程式使用。NPN 較舊，從未標準化，並且已由 ALPN 取代。我們認為，ALPN 的部署範圍遠比 NPN 廣泛。SSL_select_next_proto 函式不僅接受來自伺服器的通訊協定清單和來自用戶端的通訊協定清單，還傳回出現在伺服器清單和用戶端清單中的第一個通訊協定。如果兩個清單之間沒有重疊，函式會傳回用戶端清單中的第一個項目。在任何一種情況下，它都會發出是否在兩個清單之間發現重疊情況的訊號。使用零長度用戶端清單呼叫 SSL_select_next_proto 時，它不會注意到此情況，並立即在用戶端清單指標出現之後傳回記憶體 (並報告清單中沒有重疊)。

    通常，在伺服器端應用程式回呼 ALPN 或用戶端應用程式回呼 NPN 時，才呼叫此函式。就 ALPN 而言，libssl 保證用戶端提供的通訊協定清單長度永遠不會為零。伺服器通訊協定清單來自應用程式，其長度通常不會為零。在這種情況下，如果已按預期呼叫 SSL_select_next_proto 函式 (清單由 client/client_len 參數中傳遞的用戶端提供)，應用程式則不會受到此問題的影響。如果應用程式意外被設定了零長度的伺服器清單，並意外在 client/client_len 參數中傳遞了這個零長度的伺服器清單，且無法正確處理無重疊回應 (這通常會導致 ALPN 中發生交握失敗)，則容易受到此問題的影響。

    就 NPN 而言，在沒有重疊的情況下，通訊協定會允許用戶端伺機選取通訊協定。OpenSSL 會在無重疊的情況下傳回第一個用戶端通訊協定以支援此設定。此用戶端通訊協定清單來自於應用程式，且正常情況下長度不應為零。但是，如果意外以 0 的 client_len 呼叫 SSL_select_next_proto 函式，則會改為傳回無效的記憶體指標。如果應用程式使用此輸出作為伺機性通訊協定，則會發生機密性喪失。

    此問題已評估為「低」嚴重性，因為如果應用程式使用 NPN 而非 ALPN，但 NPN 並未廣泛使用，則最容易受到影響。此外，這需要應用程式設定或編程錯誤。最後，此問題通常不受攻擊者控制，因此不太可能發生主動惡意利用。

    3.3、3.2、3.1 和 3.0 中的 FIPS 模組不受此問題影響。

    由於此問題的嚴重性低，因此我們目前不會發佈新版本的 OpenSSL。此修正將在下一版本可用時提供。(CVE-2024-5535)

Tenable 已直接從所測試產品的安全公告擷取前置描述區塊。

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

遠端主機上安裝的 openssl-snapsafe 版本為 1.0.2k-24 之前的版本。因此，它受到 ALAS2OPENSSL-SNAPSAFE-2024-006 公告中提及的一個弱點影響。

    問題摘要：以空的受支援用戶端通訊協定緩衝區呼叫 OpenSSL API 函式 SSL_select_next_proto 可能會造成當機或記憶體內容被傳送至對等記憶體。

    影響摘要：緩衝區過度讀取可造成一系列潛在後果，例如非預期的應用程式行為或當機。特別是，此問題可導致最多 255 位元組的任意私人資料從記憶體傳送至對等記憶體，進而導致機密性喪失。但是，只有透過 0 長度的受支援用戶端通訊協定清單直接呼叫 SSL_select_next_proto 函式的應用程式才會受到此問題影響。這種情況通常不會發生，而且通常不受攻擊者控制，但在呼叫應用程式中發生設定或程式設計錯誤的情況下可能會意外發生。

    OpenSSL API 函式 SSL_select_next_proto 通常由支援 ALPN (應用程式層通訊協定交涉) 或 NPN (下一個通訊協定交涉) 的 TLS 應用程式使用。NPN 較舊，從未標準化，並且已由 ALPN 取代。我們認為，ALPN 的部署範圍遠比 NPN 廣泛。SSL_select_next_proto 函式不僅接受來自伺服器的通訊協定清單和來自用戶端的通訊協定清單，還傳回出現在伺服器清單和用戶端清單中的第一個通訊協定。如果兩個清單之間沒有重疊，函式會傳回用戶端清單中的第一個項目。在任何一種情況下，它都會發出是否在兩個清單之間發現重疊情況的訊號。使用零長度用戶端清單呼叫 SSL_select_next_proto 時，它不會注意到此情況，並立即在用戶端清單指標出現之後傳回記憶體 (並報告清單中沒有重疊)。

    通常，在伺服器端應用程式回呼 ALPN 或用戶端應用程式回呼 NPN 時，才呼叫此函式。就 ALPN 而言，libssl 保證用戶端提供的通訊協定清單長度永遠不會為零。伺服器通訊協定清單來自應用程式，其長度通常不會為零。在這種情況下，如果已按預期呼叫 SSL_select_next_proto 函式 (清單由 client/client_len 參數中傳遞的用戶端提供)，應用程式則不會受到此問題的影響。如果應用程式意外被設定了零長度的伺服器清單，並意外在 client/client_len 參數中傳遞了這個零長度的伺服器清單，且無法正確處理無重疊回應 (這通常會導致 ALPN 中發生交握失敗)，則容易受到此問題的影響。

    就 NPN 而言，在沒有重疊的情況下，通訊協定會允許用戶端伺機選取通訊協定。OpenSSL 會在無重疊的情況下傳回第一個用戶端通訊協定以支援此設定。此用戶端通訊協定清單來自於應用程式，且正常情況下長度不應為零。但是，如果意外以 0 的 client_len 呼叫 SSL_select_next_proto 函式，則會改為傳回無效的記憶體指標。如果應用程式使用此輸出作為伺機性通訊協定，則會發生機密性喪失。

    此問題已評估為「低」嚴重性，因為如果應用程式使用 NPN 而非 ALPN，但 NPN 並未廣泛使用，則最容易受到影響。此外，這需要應用程式設定或編程錯誤。最後，此問題通常不受攻擊者控制，因此不太可能發生主動惡意利用。

    3.3、3.2、3.1 和 3.0 中的 FIPS 模組不受此問題影響。

    由於此問題的嚴重性低，因此我們目前不會發佈新版本的 OpenSSL。此修正將在下一版本可用時提供。(CVE-2024-5535)

Tenable 已直接從所測試產品的安全公告擷取前置描述區塊。

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

遠端主機上安裝的 openssl 版本低於 1.1.1za。因此，它受到 SSA:2024-199-01 公告中提及的多個弱點影響。

    現已提供適用於 Slackware 15.0 和最新版本的新 openssl 套件，可修正多個安全性問題。

Tenable 已直接從 openssl 安全公告擷取前置描述區塊。

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

遠端主機上安裝的 OpenSSL 版本為 1.1.1za 之前的版本。因此，它受到 1.1.1za 公告中提及的一個弱點影響。

  - 問題摘要：以空的受支援用戶端通訊協定緩衝區呼叫 OpenSSL API 函式 SSL_select_next_proto 可能會造成當機或記憶體內容被傳送至對等記憶體。影響摘要：緩衝區過度讀取可造成一系列潛在後果，例如非預期的應用程式行為或當機。
    特別是，此問題可導致最多 255 位元組的任意私人資料從記憶體傳送至對等記憶體，進而導致機密性喪失。但是，只有透過 0 長度的受支援用戶端通訊協定清單直接呼叫 SSL_select_next_proto 函式的應用程式才會受到此問題影響。這種情況通常不會發生，而且通常不受攻擊者控制，但在呼叫應用程式中發生設定或程式設計錯誤的情況下可能會意外發生。OpenSSL API 函式 SSL_select_next_proto 通常由支援 ALPN (應用程式層通訊協定交涉) 或 NPN (下一個通訊協定交涉) 的 TLS 應用程式使用。NPN 較舊，從未標準化，並且已由 ALPN 取代。我們認為，ALPN 的部署範圍遠比 NPN 廣泛。SSL_select_next_proto 函式不僅接受來自伺服器的通訊協定清單和來自用戶端的通訊協定清單，還傳回出現在伺服器清單和用戶端清單中的第一個通訊協定。如果兩個清單之間沒有重疊，函式會傳回用戶端清單中的第一個項目。在任何一種情況下，它都會發出是否在兩個清單之間發現重疊情況的訊號。使用零長度用戶端清單呼叫 SSL_select_next_proto 時，它不會注意到此情況，並立即在用戶端清單指標出現之後傳回記憶體 (並報告清單中沒有重疊)。通常，在伺服器端應用程式回呼 ALPN 或用戶端應用程式回呼 NPN 時，才呼叫此函式。就 ALPN 而言，libssl 保證用戶端提供的通訊協定清單長度永遠不會為零。伺服器通訊協定清單來自應用程式，其長度通常不會為零。在這種情況下，如果已按預期呼叫 SSL_select_next_proto 函式 (清單由 client/client_len 參數中傳遞的用戶端提供)，應用程式則不會受到此問題的影響。如果應用程式意外被設定了零長度的伺服器清單，並意外在 client/client_len 參數中傳遞了這個零長度的伺服器清單，且無法正確處理無重疊回應 (這通常會導致 ALPN 中發生交握失敗)，則容易受到此問題的影響。就 NPN 而言，在沒有重疊的情況下，通訊協定會允許用戶端伺機選取通訊協定。OpenSSL 會在無重疊的情況下傳回第一個用戶端通訊協定以支援此設定。用戶端通訊協定清單來自應用程式，其長度通常不會為零。不過，如果意外以 0 的 client_len 呼叫 SSL_select_next_proto 函式，則會改為傳回無效的記憶體指標。如果應用程式使用此輸出作為伺機性通訊協定，則會發生機密性喪失。此問題已評估為「低」嚴重性，因為如果應用程式使用 NPN 而非 ALPN，但 NPN 並未廣泛使用，則最容易受到影響。應用程式設定或程式設計錯誤也是前提條件。最後，此問題通常不受攻擊者控制，因此不太可能發生主動惡意利用。3.3、3.2、3.1 和 3.0 中的 FIPS 模組不受此問題影響。由於此問題的嚴重性低，因此我們目前不會發佈新版本的 OpenSSL。此修正將在下一版本可用時提供。由 Joseph Birr-Pixton 發現。感謝 David Benjamin (Google)。修正程式由 Matt Caswell 開發。已在 OpenSSL 1.1.1za 版 (高級支援) 中修正此問題 (受影響的是 1.1.1 和之後版本)。(CVE-2024-5535)

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

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

  - 問題摘要：以空的受支援用戶端通訊協定緩衝區呼叫 OpenSSL API 函式 SSL_select_next_proto 可能會造成當機或記憶體內容被傳送至對等記憶體。影響摘要：緩衝區過度讀取可造成一系列潛在後果，例如非預期的應用程式行為或當機。
    特別是，此問題可導致最多 255 位元組的任意私人資料從記憶體傳送至對等記憶體，進而導致機密性喪失。但是，只有透過 0 長度的受支援用戶端通訊協定清單直接呼叫 SSL_select_next_proto 函式的應用程式才會受到此問題影響。這種情況通常不會發生，而且通常不受攻擊者控制，但在呼叫應用程式中發生設定或程式設計錯誤的情況下可能會意外發生。OpenSSL API 函式 SSL_select_next_proto 通常由支援 ALPN (應用程式層通訊協定交涉) 或 NPN (下一個通訊協定交涉) 的 TLS 應用程式使用。NPN 較舊，從未標準化，並且已由 ALPN 取代。我們認為，ALPN 的部署範圍遠比 NPN 廣泛。SSL_select_next_proto 函式不僅接受來自伺服器的通訊協定清單和來自用戶端的通訊協定清單，還傳回出現在伺服器清單和用戶端清單中的第一個通訊協定。如果兩個清單之間沒有重疊，函式會傳回用戶端清單中的第一個項目。在任何一種情況下，它都會發出是否在兩個清單之間發現重疊情況的訊號。使用零長度用戶端清單呼叫 SSL_select_next_proto 時，它不會注意到此情況，並立即在用戶端清單指標出現之後傳回記憶體 (並報告清單中沒有重疊)。通常，在伺服器端應用程式回呼 ALPN 或用戶端應用程式回呼 NPN 時，才呼叫此函式。就 ALPN 而言，libssl 保證用戶端提供的通訊協定清單長度永遠不會為零。伺服器通訊協定清單來自應用程式，其長度通常不會為零。在這種情況下，如果已按預期呼叫 SSL_select_next_proto 函式 (清單由 client/client_len 參數中傳遞的用戶端提供)，應用程式則不會受到此問題的影響。如果應用程式意外被設定了零長度的伺服器清單，並意外在 client/client_len 參數中傳遞了這個零長度的伺服器清單，且無法正確處理無重疊回應 (這通常會導致 ALPN 中發生交握失敗)，則容易受到此問題的影響。就 NPN 而言，在沒有重疊的情況下，通訊協定會允許用戶端伺機選取通訊協定。OpenSSL 會在無重疊的情況下傳回第一個用戶端通訊協定以支援此設定。用戶端通訊協定清單來自應用程式，其長度通常不會為零。不過，如果意外以 0 的 client_len 呼叫 SSL_select_next_proto 函式，則會改為傳回無效的記憶體指標。如果應用程式使用此輸出作為伺機性通訊協定，則會發生機密性喪失。此問題已評估為「低」嚴重性，因為如果應用程式使用 NPN 而非 ALPN，但 NPN 並未廣泛使用，則最容易受到影響。應用程式設定或程式設計錯誤也是前提條件。最後，此問題通常不受攻擊者控制，因此不太可能發生主動惡意利用。3.3、3.2、3.1 和 3.0 中的 FIPS 模組不受此問題影響。由於此問題的嚴重性低，因此我們目前不會發佈新版本的 OpenSSL。此修正將在下一版本可用時提供。由 Joseph Birr-Pixton 發現。感謝 David Benjamin (Google)。修正程式由 Matt Caswell 開發。已在 OpenSSL 1.1.1za 版 (高級支援) 中修正此問題 (受影響的是 1.1.1 和之後版本)。(CVE-2024-5535)

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

遠端主機上安裝的 openssl 版本為 1.0.2k-24 之前版本。因此，它會受到 ALAS2-2024-2604 公告中提及的一個弱點影響。

    問題摘要：以空的受支援用戶端通訊協定緩衝區呼叫 OpenSSL API 函式 SSL_select_next_proto 可能會造成當機或記憶體內容被傳送至對等記憶體。

    影響摘要：緩衝區過度讀取可造成一系列潛在後果，例如非預期的應用程式行為或當機。特別是，此問題可導致最多 255 位元組的任意私人資料從記憶體傳送至對等記憶體，進而導致機密性喪失。但是，只有透過 0 長度的受支援用戶端通訊協定清單直接呼叫 SSL_select_next_proto 函式的應用程式才會受到此問題影響。這種情況通常不會發生，而且通常不受攻擊者控制，但在呼叫應用程式中發生設定或程式設計錯誤的情況下可能會意外發生。

    OpenSSL API 函式 SSL_select_next_proto 通常由支援 ALPN (應用程式層通訊協定交涉) 或 NPN (下一個通訊協定交涉) 的 TLS 應用程式使用。NPN 較舊，從未標準化，並且已由 ALPN 取代。我們認為，ALPN 的部署範圍遠比 NPN 廣泛。SSL_select_next_proto 函式不僅接受來自伺服器的通訊協定清單和來自用戶端的通訊協定清單，還傳回出現在伺服器清單和用戶端清單中的第一個通訊協定。如果兩個清單之間沒有重疊，函式會傳回用戶端清單中的第一個項目。在任何一種情況下，它都會發出是否在兩個清單之間發現重疊情況的訊號。使用零長度用戶端清單呼叫 SSL_select_next_proto 時，它不會注意到此情況，並立即在用戶端清單指標出現之後傳回記憶體 (並報告清單中沒有重疊)。

    通常，在伺服器端應用程式回呼 ALPN 或用戶端應用程式回呼 NPN 時，才呼叫此函式。就 ALPN 而言，libssl 保證用戶端提供的通訊協定清單長度永遠不會為零。伺服器通訊協定清單來自應用程式，其長度通常不會為零。在這種情況下，如果已按預期呼叫 SSL_select_next_proto 函式 (清單由 client/client_len 參數中傳遞的用戶端提供)，應用程式則不會受到此問題的影響。如果應用程式意外被設定了零長度的伺服器清單，並意外在 client/client_len 參數中傳遞了這個零長度的伺服器清單，且無法正確處理無重疊回應 (這通常會導致 ALPN 中發生交握失敗)，則容易受到此問題的影響。

    就 NPN 而言，在沒有重疊的情況下，通訊協定會允許用戶端伺機選取通訊協定。OpenSSL 會在無重疊的情況下傳回第一個用戶端通訊協定以支援此設定。此用戶端通訊協定清單來自於應用程式，且正常情況下長度不應為零。但是，如果意外以 0 的 client_len 呼叫 SSL_select_next_proto 函式，則會改為傳回無效的記憶體指標。如果應用程式使用此輸出作為伺機性通訊協定，則會發生機密性喪失。

    此問題已評估為「低」嚴重性，因為如果應用程式使用 NPN 而非 ALPN，但 NPN 並未廣泛使用，則最容易受到影響。此外，這需要應用程式設定或編程錯誤。最後，此問題通常不受攻擊者控制，因此不太可能發生主動惡意利用。

    3.3、3.2、3.1 和 3.0 中的 FIPS 模組不受此問題影響。

    由於此問題的嚴重性低，因此我們目前不會發佈新版本的 OpenSSL。此修正將在下一版本可用時提供。(CVE-2024-5535)

Tenable 已直接從所測試產品的安全公告擷取前置描述區塊。

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

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

  - 問題摘要：以空的受支援用戶端通訊協定緩衝區呼叫 OpenSSL API 函式 SSL_select_next_proto 可能會造成當機或記憶體內容被傳送至對等記憶體。影響摘要：緩衝區過度讀取可造成一系列潛在後果，例如非預期的應用程式行為或當機。
    特別是，此問題可導致最多 255 位元組的任意私人資料從記憶體傳送至對等記憶體，進而導致機密性喪失。但是，只有透過 0 長度的受支援用戶端通訊協定清單直接呼叫 SSL_select_next_proto 函式的應用程式才會受到此問題影響。這種情況通常不會發生，而且通常不受攻擊者控制，但在呼叫應用程式中發生設定或程式設計錯誤的情況下可能會意外發生。OpenSSL API 函式 SSL_select_next_proto 通常由支援 ALPN (應用程式層通訊協定交涉) 或 NPN (下一個通訊協定交涉) 的 TLS 應用程式使用。NPN 較舊，從未標準化，並且已由 ALPN 取代。我們認為，ALPN 的部署範圍遠比 NPN 廣泛。SSL_select_next_proto 函式不僅接受來自伺服器的通訊協定清單和來自用戶端的通訊協定清單，還傳回出現在伺服器清單和用戶端清單中的第一個通訊協定。如果兩個清單之間沒有重疊，函式會傳回用戶端清單中的第一個項目。在任何一種情況下，它都會發出是否在兩個清單之間發現重疊情況的訊號。使用零長度用戶端清單呼叫 SSL_select_next_proto 時，它不會注意到此情況，並立即在用戶端清單指標出現之後傳回記憶體 (並報告清單中沒有重疊)。通常，在伺服器端應用程式回呼 ALPN 或用戶端應用程式回呼 NPN 時，才呼叫此函式。就 ALPN 而言，libssl 保證用戶端提供的通訊協定清單長度永遠不會為零。伺服器通訊協定清單來自應用程式，其長度通常不會為零。在這種情況下，如果已按預期呼叫 SSL_select_next_proto 函式 (清單由 client/client_len 參數中傳遞的用戶端提供)，應用程式則不會受到此問題的影響。如果應用程式意外被設定了零長度的伺服器清單，並意外在 client/client_len 參數中傳遞了這個零長度的伺服器清單，且無法正確處理無重疊回應 (這通常會導致 ALPN 中發生交握失敗)，則容易受到此問題的影響。就 NPN 而言，在沒有重疊的情況下，通訊協定會允許用戶端伺機選取通訊協定。OpenSSL 會在無重疊的情況下傳回第一個用戶端通訊協定以支援此設定。用戶端通訊協定清單來自應用程式，其長度通常不會為零。不過，如果意外以 0 的 client_len 呼叫 SSL_select_next_proto 函式，則會改為傳回無效的記憶體指標。如果應用程式使用此輸出作為伺機性通訊協定，則會發生機密性喪失。此問題已評估為「低」嚴重性，因為如果應用程式使用 NPN 而非 ALPN，但 NPN 並未廣泛使用，則最容易受到影響。應用程式設定或程式設計錯誤也是前提條件。最後，此問題通常不受攻擊者控制，因此不太可能發生主動惡意利用。3.3、3.2、3.1 和 3.0 中的 FIPS 模組不受此問題影響。由於此問題的嚴重性低，因此我們目前不會發佈新版本的 OpenSSL。此修正將在下一版本可用時提供。由 Joseph Birr-Pixton 發現。感謝 David Benjamin (Google)。修正程式由 Matt Caswell 開發。已在 OpenSSL 3.3.2 版中修正此問題 (受影響的是 3.3.0 和之後版本)。(CVE-2024-5535)

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

因此，它會受到 ALAS2-2024-2591 公告中提及的一個弱點影響。

    問題摘要：以空的受支援用戶端通訊協定緩衝區呼叫 OpenSSL API 函式 SSL_select_next_proto 可能會造成當機或記憶體內容被傳送至對等記憶體。

    影響摘要：緩衝區過度讀取可造成一系列潛在後果，例如非預期的應用程式行為或當機。特別是，此問題可導致最多 255 位元組的任意私人資料從記憶體傳送至對等記憶體，進而導致機密性喪失。但是，只有透過 0 長度的受支援用戶端通訊協定清單直接呼叫 SSL_select_next_proto 函式的應用程式才會受到此問題影響。這種情況通常不會發生，而且通常不受攻擊者控制，但在呼叫應用程式中發生設定或程式設計錯誤的情況下可能會意外發生。

    OpenSSL API 函式 SSL_select_next_proto 通常由支援 ALPN (應用程式層通訊協定交涉) 或 NPN (下一個通訊協定交涉) 的 TLS 應用程式使用。NPN 較舊，從未標準化，並且已由 ALPN 取代。我們認為，ALPN 的部署範圍遠比 NPN 廣泛。SSL_select_next_proto 函式不僅接受來自伺服器的通訊協定清單和來自用戶端的通訊協定清單，還傳回出現在伺服器清單和用戶端清單中的第一個通訊協定。如果兩個清單之間沒有重疊，函式會傳回用戶端清單中的第一個項目。在任何一種情況下，它都會發出是否在兩個清單之間發現重疊情況的訊號。使用零長度用戶端清單呼叫 SSL_select_next_proto 時，它不會注意到此情況，並立即在用戶端清單指標出現之後傳回記憶體 (並報告清單中沒有重疊)。

    通常，在伺服器端應用程式回呼 ALPN 或用戶端應用程式回呼 NPN 時，才呼叫此函式。就 ALPN 而言，libssl 保證用戶端提供的通訊協定清單長度永遠不會為零。伺服器通訊協定清單來自應用程式，其長度通常不會為零。在這種情況下，如果已按預期呼叫 SSL_select_next_proto 函式 (清單由 client/client_len 參數中傳遞的用戶端提供)，應用程式則不會受到此問題的影響。如果應用程式意外被設定了零長度的伺服器清單，並意外在 client/client_len 參數中傳遞了這個零長度的伺服器清單，且無法正確處理無重疊回應 (這通常會導致 ALPN 中發生交握失敗)，則容易受到此問題的影響。

    就 NPN 而言，在沒有重疊的情況下，通訊協定會允許用戶端伺機選取通訊協定。OpenSSL 會在無重疊的情況下傳回第一個用戶端通訊協定以支援此設定。此用戶端通訊協定清單來自於應用程式，且正常情況下長度不應為零。但是，如果意外以 0 的 client_len 呼叫 SSL_select_next_proto 函式，則會改為傳回無效的記憶體指標。如果應用程式使用此輸出作為伺機性通訊協定，則會發生機密性喪失。

    此問題已評估為「低」嚴重性，因為如果應用程式使用 NPN 而非 ALPN，但 NPN 並未廣泛使用，則最容易受到影響。此外，這需要應用程式設定或編程錯誤。最後，此問題通常不受攻擊者控制，因此不太可能發生主動惡意利用。

    3.3、3.2、3.1 和 3.0 中的 FIPS 模組不受此問題影響。

    由於此問題的嚴重性低，因此我們目前不會發佈新版本的 OpenSSL。此修正將在下一版本可用時提供。(CVE-2024-5535)

Tenable 已直接從所測試產品的安全公告擷取前置描述區塊。

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

遠端 Ubuntu 20.04 LTS/22.04 LTS/24.04 LTS 主機上安裝的套件受到 USN-6937-1 公告中所提及的多個弱點影響。

    據發現，使用某些非預設 TLS 伺服器設定時，OpenSSL 未正確處理 TLSv1.3 工作階段。遠端攻擊者可能會利用此問題造成 OpenSSL 耗用資源，進而導致拒絕服務。(CVE-2024-2511)

    據發現，OpenSSL 未正確處理對過長 DSA 金鑰或參數的檢查。遠端攻擊者可能會利用此問題造成 OpenSSL 耗用資源，進而導致拒絕服務。此問題僅影響了 Ubuntu 22.04 LTS 和 Ubuntu 24.04 LTS。(CVE-2024-4603)

    William Ahern 發現，OpenSSL 未正確處理很少使用的 API 中的某些記憶體作業。
    遠端攻擊者可利用此問題造成 OpenSSL 當機，進而引發拒絕服務或可能執行任意程式碼。(CVE-2024-4741)

    Joseph Birr-Pixton 發現，OpenSSL 未正確處理受支援的用戶端通訊協定緩衝區為空的特定 API 呼叫。遠端攻擊者可能利用此問題取得敏感資訊或造成 OpenSSL 損毀，進而導致拒絕服務。(CVE-2024-5535)

Tenable 已直接從 Ubuntu 安全公告擷取前置描述區塊。

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

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

  - 問題摘要：以空的受支援用戶端通訊協定緩衝區呼叫 OpenSSL API 函式 SSL_select_next_proto 可能會造成當機或記憶體內容被傳送至對等記憶體。影響摘要：緩衝區過度讀取可造成一系列潛在後果，例如非預期的應用程式行為或當機。
    特別是，此問題可導致最多 255 位元組的任意私人資料從記憶體傳送至對等記憶體，進而導致機密性喪失。但是，只有透過 0 長度的受支援用戶端通訊協定清單直接呼叫 SSL_select_next_proto 函式的應用程式才會受到此問題影響。這種情況通常不會發生，而且通常不受攻擊者控制，但在呼叫應用程式中發生設定或程式設計錯誤的情況下可能會意外發生。OpenSSL API 函式 SSL_select_next_proto 通常由支援 ALPN (應用程式層通訊協定交涉) 或 NPN (下一個通訊協定交涉) 的 TLS 應用程式使用。NPN 較舊，從未標準化，並且已由 ALPN 取代。我們認為，ALPN 的部署範圍遠比 NPN 廣泛。SSL_select_next_proto 函式不僅接受來自伺服器的通訊協定清單和來自用戶端的通訊協定清單，還傳回出現在伺服器清單和用戶端清單中的第一個通訊協定。如果兩個清單之間沒有重疊，函式會傳回用戶端清單中的第一個項目。在任何一種情況下，它都會發出是否在兩個清單之間發現重疊情況的訊號。使用零長度用戶端清單呼叫 SSL_select_next_proto 時，它不會注意到此情況，並立即在用戶端清單指標出現之後傳回記憶體 (並報告清單中沒有重疊)。通常，在伺服器端應用程式回呼 ALPN 或用戶端應用程式回呼 NPN 時，才呼叫此函式。就 ALPN 而言，libssl 保證用戶端提供的通訊協定清單長度永遠不會為零。伺服器通訊協定清單來自應用程式，其長度通常不會為零。在這種情況下，如果已按預期呼叫 SSL_select_next_proto 函式 (清單由 client/client_len 參數中傳遞的用戶端提供)，應用程式則不會受到此問題的影響。如果應用程式意外被設定了零長度的伺服器清單，並意外在 client/client_len 參數中傳遞了這個零長度的伺服器清單，且無法正確處理無重疊回應 (這通常會導致 ALPN 中發生交握失敗)，則容易受到此問題的影響。就 NPN 而言，在沒有重疊的情況下，通訊協定會允許用戶端伺機選取通訊協定。OpenSSL 會在無重疊的情況下傳回第一個用戶端通訊協定以支援此設定。用戶端通訊協定清單來自應用程式，其長度通常不會為零。不過，如果意外以 0 的 client_len 呼叫 SSL_select_next_proto 函式，則會改為傳回無效的記憶體指標。如果應用程式使用此輸出作為伺機性通訊協定，則會發生機密性喪失。此問題已評估為「低」嚴重性，因為如果應用程式使用 NPN 而非 ALPN，但 NPN 並未廣泛使用，則最容易受到影響。應用程式設定或程式設計錯誤也是前提條件。最後，此問題通常不受攻擊者控制，因此不太可能發生主動惡意利用。3.3、3.2、3.1 和 3.0 中的 FIPS 模組不受此問題影響。由於此問題的嚴重性低，因此我們目前不會發佈新版本的 OpenSSL。此修正將在下一版本可用時提供。由 Joseph Birr-Pixton 發現。感謝 David Benjamin (Google)。修正程式由 Matt Caswell 開發。已在 OpenSSL 1.1.1za 版 (高級支援) 中修正此問題 (受影響的是 1.1.1 和之後版本)。(CVE-2024-5535)

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

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

  - 問題摘要：以空的受支援用戶端通訊協定緩衝區呼叫 OpenSSL API 函式 SSL_select_next_proto 可能會造成當機或記憶體內容被傳送至對等記憶體。影響摘要：緩衝區過度讀取可造成一系列潛在後果，例如非預期的應用程式行為或當機。
    特別是，此問題可導致最多 255 位元組的任意私人資料從記憶體傳送至對等記憶體，進而導致機密性喪失。但是，只有透過 0 長度的受支援用戶端通訊協定清單直接呼叫 SSL_select_next_proto 函式的應用程式才會受到此問題影響。這種情況通常不會發生，而且通常不受攻擊者控制，但在呼叫應用程式中發生設定或程式設計錯誤的情況下可能會意外發生。OpenSSL API 函式 SSL_select_next_proto 通常由支援 ALPN (應用程式層通訊協定交涉) 或 NPN (下一個通訊協定交涉) 的 TLS 應用程式使用。NPN 較舊，從未標準化，並且已由 ALPN 取代。我們認為，ALPN 的部署範圍遠比 NPN 廣泛。SSL_select_next_proto 函式不僅接受來自伺服器的通訊協定清單和來自用戶端的通訊協定清單，還傳回出現在伺服器清單和用戶端清單中的第一個通訊協定。如果兩個清單之間沒有重疊，函式會傳回用戶端清單中的第一個項目。在任何一種情況下，它都會發出是否在兩個清單之間發現重疊情況的訊號。使用零長度用戶端清單呼叫 SSL_select_next_proto 時，它不會注意到此情況，並立即在用戶端清單指標出現之後傳回記憶體 (並報告清單中沒有重疊)。通常，在伺服器端應用程式回呼 ALPN 或用戶端應用程式回呼 NPN 時，才呼叫此函式。就 ALPN 而言，libssl 保證用戶端提供的通訊協定清單長度永遠不會為零。伺服器通訊協定清單來自應用程式，其長度通常不會為零。在這種情況下，如果已按預期呼叫 SSL_select_next_proto 函式 (清單由 client/client_len 參數中傳遞的用戶端提供)，應用程式則不會受到此問題的影響。如果應用程式意外被設定了零長度的伺服器清單，並意外在 client/client_len 參數中傳遞了這個零長度的伺服器清單，且無法正確處理無重疊回應 (這通常會導致 ALPN 中發生交握失敗)，則容易受到此問題的影響。就 NPN 而言，在沒有重疊的情況下，通訊協定會允許用戶端伺機選取通訊協定。OpenSSL 會在無重疊的情況下傳回第一個用戶端通訊協定以支援此設定。用戶端通訊協定清單來自應用程式，其長度通常不會為零。不過，如果意外以 0 的 client_len 呼叫 SSL_select_next_proto 函式，則會改為傳回無效的記憶體指標。如果應用程式使用此輸出作為伺機性通訊協定，則會發生機密性喪失。此問題已評估為「低」嚴重性，因為如果應用程式使用 NPN 而非 ALPN，但 NPN 並未廣泛使用，則最容易受到影響。應用程式設定或程式設計錯誤也是前提條件。最後，此問題通常不受攻擊者控制，因此不太可能發生主動惡意利用。3.3、3.2、3.1 和 3.0 中的 FIPS 模組不受此問題影響。由於此問題的嚴重性低，因此我們目前不會發佈新版本的 OpenSSL。此修正將在下一版本可用時提供。由 Joseph Birr-Pixton 發現。感謝 David Benjamin (Google)。修正程式由 Matt Caswell 開發。已在 OpenSSL 3.3.2 版中修正此問題 (受影響的是 3.3.0 和之後版本)。(CVE-2024-5535)

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

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

  - 問題摘要：以空的受支援用戶端通訊協定緩衝區呼叫 OpenSSL API 函式 SSL_select_next_proto 可能會造成當機或記憶體內容被傳送至對等記憶體。影響摘要：緩衝區過度讀取可造成一系列潛在後果，例如非預期的應用程式行為或當機。
    特別是，此問題可導致最多 255 位元組的任意私人資料從記憶體傳送至對等記憶體，進而導致機密性喪失。但是，只有透過 0 長度的受支援用戶端通訊協定清單直接呼叫 SSL_select_next_proto 函式的應用程式才會受到此問題影響。這種情況通常不會發生，而且通常不受攻擊者控制，但在呼叫應用程式中發生設定或程式設計錯誤的情況下可能會意外發生。OpenSSL API 函式 SSL_select_next_proto 通常由支援 ALPN (應用程式層通訊協定交涉) 或 NPN (下一個通訊協定交涉) 的 TLS 應用程式使用。NPN 較舊，從未標準化，並且已由 ALPN 取代。我們認為，ALPN 的部署範圍遠比 NPN 廣泛。SSL_select_next_proto 函式不僅接受來自伺服器的通訊協定清單和來自用戶端的通訊協定清單，還傳回出現在伺服器清單和用戶端清單中的第一個通訊協定。如果兩個清單之間沒有重疊，函式會傳回用戶端清單中的第一個項目。在任何一種情況下，它都會發出是否在兩個清單之間發現重疊情況的訊號。使用零長度用戶端清單呼叫 SSL_select_next_proto 時，它不會注意到此情況，並立即在用戶端清單指標出現之後傳回記憶體 (並報告清單中沒有重疊)。通常，在伺服器端應用程式回呼 ALPN 或用戶端應用程式回呼 NPN 時，才呼叫此函式。就 ALPN 而言，libssl 保證用戶端提供的通訊協定清單長度永遠不會為零。伺服器通訊協定清單來自應用程式，其長度通常不會為零。在這種情況下，如果已按預期呼叫 SSL_select_next_proto 函式 (清單由 client/client_len 參數中傳遞的用戶端提供)，應用程式則不會受到此問題的影響。如果應用程式意外被設定了零長度的伺服器清單，並意外在 client/client_len 參數中傳遞了這個零長度的伺服器清單，且無法正確處理無重疊回應 (這通常會導致 ALPN 中發生交握失敗)，則容易受到此問題的影響。就 NPN 而言，在沒有重疊的情況下，通訊協定會允許用戶端伺機選取通訊協定。OpenSSL 會在無重疊的情況下傳回第一個用戶端通訊協定以支援此設定。用戶端通訊協定清單來自應用程式，其長度通常不會為零。不過，如果意外以 0 的 client_len 呼叫 SSL_select_next_proto 函式，則會改為傳回無效的記憶體指標。如果應用程式使用此輸出作為伺機性通訊協定，則會發生機密性喪失。此問題已評估為「低」嚴重性，因為如果應用程式使用 NPN 而非 ALPN，但 NPN 並未廣泛使用，則最容易受到影響。應用程式設定或程式設計錯誤也是前提條件。最後，此問題通常不受攻擊者控制，因此不太可能發生主動惡意利用。3.3、3.2、3.1 和 3.0 中的 FIPS 模組不受此問題影響。由於此問題的嚴重性低，因此我們目前不會發佈新版本的 OpenSSL。此修正將在下一版本可用時提供。由 Joseph Birr-Pixton 發現。感謝 David Benjamin (Google)。修正程式由 Matt Caswell 開發。已在 OpenSSL 1.1.1za 版 (高級支援) 中修正此問題 (受影響的是 1.1.1 和之後版本)。(CVE-2024-5535)

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

遠端 CentOS Linux 9 主機上安裝的套件受到 openssl-3.2.2-4.el9 版本變更記錄中提及的弱點影響。

  - SSL_select_next_proto 緩衝區過度讀取 (CVE-2024-5535)

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

因此，會受到 ALAS2023-2024-677 公告中所提及的多個弱點影響。

    問題摘要：檢查過長的 DSA 金鑰或參數時可能會非常緩慢。

    影響摘要：使用 EVP_PKEY_param_check() 或 EVP_PKEY_public_check() 函式檢查 DSA 金鑰或 DSA 參數的應用程式可能會遇到長時間延遲。如果要檢查的金鑰或參數是從未受信任的來源取得，這可能會導致拒絕服務。

    EVP_PKEY_param_check() 或 EVP_PKEY_public_check() 函式對 DSA 參數執行各種檢查。
    如果模數 (「p」參數) 太大，某些運算會花很長的時間。

    嘗試使用非常大的模數時執行速度會變慢，且 OpenSSL 不允許使用長度超過 10,000 位元的公開金鑰用於執行簽章驗證。不過，執行檢查時，金鑰和參數檢查函式不會限制模數大小。

    應用程式如果呼叫 EVP_PKEY_param_check() 或 EVP_PKEY_public_check() 並提供從未受信任之來源取得的金鑰或參數，則容易遭受拒絕服務攻擊。

    OpenSSL 本身不會在未受信任的 DSA 金鑰上呼叫這些函式，因此只有直接呼叫這些函式的應用程式可能會受到影響。

    使用「-check」選項時，OpenSSL pkey 和 pkeyparam 命令列應用程式也容易受到影響。

    OpenSSL SSL/TLS 實作不受此問題影響。

    OpenSSL 3.0 和 3.1 FIPS 提供者受此問題影響。(CVE-2024-4603)

    openssl：SSL_free_buffers 存在釋放後使用弱點 (CVE-2024-4741)

    問題摘要：以空的受支援用戶端通訊協定緩衝區呼叫 OpenSSL API 函式 SSL_select_next_proto 可能會造成當機或記憶體內容被傳送至對等記憶體。

    影響摘要：緩衝區過度讀取可造成一系列潛在後果，例如非預期的應用程式行為或當機。特別是，此問題可導致最多 255 位元組的任意私人資料從記憶體傳送至對等記憶體，進而導致機密性喪失。但是，只有透過 0 長度的受支援用戶端通訊協定清單直接呼叫 SSL_select_next_proto 函式的應用程式才會受到此問題影響。這種情況通常不會發生，而且通常不受攻擊者控制，但在呼叫應用程式中發生設定或程式設計錯誤的情況下可能會意外發生。

    OpenSSL API 函式 SSL_select_next_proto 通常由支援 ALPN (應用程式層通訊協定交涉) 或 NPN (下一個通訊協定交涉) 的 TLS 應用程式使用。NPN 較舊，從未標準化，並且已由 ALPN 取代。我們認為，ALPN 的部署範圍遠比 NPN 廣泛。SSL_select_next_proto 函式不僅接受來自伺服器的通訊協定清單和來自用戶端的通訊協定清單，還傳回出現在伺服器清單和用戶端清單中的第一個通訊協定。如果兩個清單之間沒有重疊，函式會傳回用戶端清單中的第一個項目。在任何一種情況下，它都會發出是否在兩個清單之間發現重疊情況的訊號。使用零長度用戶端清單呼叫 SSL_select_next_proto 時，它不會注意到此情況，並立即在用戶端清單指標出現之後傳回記憶體 (並報告清單中沒有重疊)。

    通常，在伺服器端應用程式回呼 ALPN 或用戶端應用程式回呼 NPN 時，才呼叫此函式。就 ALPN 而言，libssl 保證用戶端提供的通訊協定清單長度永遠不會為零。伺服器通訊協定清單來自應用程式，其長度通常不會為零。在這種情況下，如果已按預期呼叫 SSL_select_next_proto 函式 (清單由 client/client_len 參數中傳遞的用戶端提供)，應用程式則不會受到此問題的影響。如果應用程式意外被設定了零長度的伺服器清單，並意外在 client/client_len 參數中傳遞了這個零長度的伺服器清單，且無法正確處理無重疊回應 (這通常會導致 ALPN 中發生交握失敗)，則容易受到此問題的影響。

    就 NPN 而言，在沒有重疊的情況下，通訊協定會允許用戶端伺機選取通訊協定。OpenSSL 會在無重疊的情況下傳回第一個用戶端通訊協定以支援此設定。此用戶端通訊協定清單來自於應用程式，且正常情況下長度不應為零。但是，如果意外以 0 的 client_len 呼叫 SSL_select_next_proto 函式，則會改為傳回無效的記憶體指標。如果應用程式使用此輸出作為伺機性通訊協定，則會發生機密性喪失。

    此問題已評估為「低」嚴重性，因為如果應用程式使用 NPN 而非 ALPN，但 NPN 並未廣泛使用，則最容易受到影響。此外，這需要應用程式設定或編程錯誤。最後，此問題通常不受攻擊者控制，因此不太可能發生主動惡意利用。

    3.3、3.2、3.1 和 3.0 中的 FIPS 模組不受此問題影響。

    由於此問題的嚴重性低，因此我們目前不會發佈新版本的 OpenSSL。此修正將在下一版本可用時提供。(CVE-2024-5535)

Tenable 已直接從所測試產品的安全公告擷取前置描述區塊。

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

ID	名稱	產品	系列	已發布	已更新	嚴重性
205438	Amazon Linux 2：openssl11 (ALAS-2024-2621)	Nessus	Amazon Linux Local Security Checks	2024/8/13	2024/9/6	critical
207411	Amazon Linux 2：openssl-snapsafe (ALASOPENSSL-SNAPSAFE-2024-006)	Nessus	Amazon Linux Local Security Checks	2024/9/18	2024/9/18	critical
202581	Slackware Linux 15.0/最新版 OpenSSL 多個弱點 (SSA:2024-199-01)	Nessus	Slackware Local Security Checks	2024/7/17	2024/9/6	medium
201084	OpenSSL 1.1.1 < 1.1.1za 弱點	Nessus	Web Servers	2024/6/27	2024/7/3	critical
201085	OpenSSL 3.0.0 < 3.0.15 弱點	Nessus	Web Servers	2024/6/27	2024/7/3	critical
205731	Amazon Linux 2：openssl (ALAS-2024-2604)	Nessus	Amazon Linux Local Security Checks	2024/8/17	2024/8/17	critical
201087	OpenSSL 3.3.0 < 3.3.2 弱點	Nessus	Web Servers	2024/6/27	2024/7/3	critical
202987	Amazon Linux 2：edk2 (ALAS-2024-2591)	Nessus	Amazon Linux Local Security Checks	2024/7/23	2024/7/23	critical
204924	Ubuntu 20.04 LTS / 22.04 LTS / 24.04 LTS：OpenSSL 弱點 (USN-6937-1)	Nessus	Ubuntu Local Security Checks	2024/7/31	2024/9/6	critical
201081	OpenSSL 3.2.0 < 3.2.3 弱點	Nessus	Web Servers	2024/6/27	2024/7/3	critical
201082	OpenSSL 3.1.0 < 3.1.7 弱點	Nessus	Web Servers	2024/6/27	2024/7/3	critical
201086	OpenSSL 1.0.2 < 1.0.2zk 弱點	Nessus	Web Servers	2024/6/27	2024/7/3	critical
206293	CentOS 9：openssl-3.2.2-1.el9	Nessus	CentOS Local Security Checks	2024/8/28	2024/8/28	critical
205110	Amazon Linux 2023：openssl、openssl-devel、openssl-libs (ALAS2023-2024-677)	Nessus	Amazon Linux Local Security Checks	2024/8/6	2024/9/6	critical

偵測

搜尋 Plugin

critical

critical

medium

critical

critical

critical

critical

critical

critical

critical

critical

critical

critical

critical