遠端主機上安裝的 OpenSSL 版本低於 1.1.1t。因此，會受到 SSA:2023-038-01 公告中提及的多個弱點影響。

  - OpenSSL RSA Decryption 實作中存在計時型旁路，其足可在 Bleichenbacher 式攻擊中跨網路復原純文字。若要成功解密，攻擊者必須能夠傳送大量的試用訊息以進行解密。
    此弱點會影響所有 RSA 填補模式：PKCS#1 v1.5、RSA-OEAP 和 RSASVE。例如，在 TLS 連線中，用戶端通常會使用 RSA 將加密的 pre-master 密碼傳送至伺服器。觀察到用戶端和伺服器之間有真正連線的攻擊者可利用此缺陷，將試用訊息傳送至伺服器，並記錄處理訊息所用的時間。在訊息數量足夠大之後，攻擊者可以復原用於原始連線的 pre-master 密碼，因此能夠解密透過該連線傳送的應用程式資料。已在 OpenSSL 1.0.2zg 版中修正此問題 (受影響的是 1.0.2 和之後版本)。(CVE-2022-4304)

  - PEM_read_bio_ex() 函式會從 BIO 讀取 PEM 檔案，並剖析和解碼名稱 (例如：
    CERTIFICATE)、任何標頭資料和承載資料。如果函式成功運行，則使用包含相關解碼資料之緩衝區的指標填入 name_out、標頭和資料引數。
    呼叫者負責釋放這些緩衝區。攻擊者可以建構會產生 0 位元組承載資料的 PEM 檔案。在此情況下，PEM_read_bio_ex() 會傳回失敗程式碼，但會在標頭引數中填入已釋放的緩衝區指標。如果呼叫者也釋放此緩衝區，則會發生雙重釋放。這很可能會導致當機。能夠提供惡意 PEM 檔案進行剖析的攻擊者可利用此弱點發動拒絕服務攻擊。PEM_read_bio() 和 PEM_read() 函式是 PEM_read_bio_ex() 的簡單包裝函式，因此這些函式也會直接受到影響。其他一些 OpenSSL 函式也會間接呼叫這些函式，包括同樣容易遭受攻擊的 PEM_X509_INFO_read_bio_ex() 和 SSL_CTX_use_serverinfo_file()。若在 OpenSSL 內部使用部分此類函式，則不會受到影響，因為如果 PEM_read_bio_ex() 傳回失敗程式碼，呼叫者將不會釋放標頭引數。這些位置包括 PEM_read_bio_TYPE() 函式以及 OpenSSL 3.0 中引入的解碼器。OpenSSL asn1parse 命令行應用程式也受此問題影響。已在 OpenSSL 3.0.8 版中修正此問題 (受影響的是 3.0.0 和之後版本)。(CVE-2022-4450)

  - 公開 API 函式 BIO_new_NDEF 是用於透過 BIO 串流 ASN.1 資料的協助程式函式。此函式主要用於 OpenSSL 內部，以支援 SMIME、CMS 和 PKCS7 串流功能，但也可能由終端使用者應用程式直接呼叫。此函式會接收來自呼叫者的 BIO，並在前面附加新的 BIO_f_asn1 篩選器 BIO 以形成 BIO 鏈結，然後將 BIO 鏈結的新標頭傳回給呼叫者。在某些情況下，例如，如果 CMS 收件人公開金鑰無效，則新篩選器 BIO 會被釋放，並且該函式會傳回 NULL 結果，表明失敗。但在此情況下，BIO 鏈結未經正確清理，且呼叫者傳送的 BIO 仍保留先前釋放的篩選器 BIO 的內部指標。如果呼叫者接著呼叫 BIO 上的 BIO_pop()，則會發生釋放後使用。這很可能會導致當機。此情況直接發生在內部函式 B64_write_ASN1() 中，其可能導致呼叫 BIO_new_NDEF()，並隨後在 BIO 上呼叫 BIO_pop()。此內部函式會接著由公開 API 函式 PEM_write_bio_ASN1_stream、PEM_write_bio_CMS_stream、PEM_write_bio_PKCS7_stream、SMIME_write_ASN1、SMIME_write_CMS 和 SMIME_write_PKCS7 呼叫。其他可能受到此問題影響的公開 API 函式包括 i2d_ASN1_bio_stream、BIO_new_CMS、BIO_new_PKCS7、i2d_CMS_bio_stream 和 i2d_PKCS7_bio_stream。OpenSSL cms 和 smime 命令行應用程式受到類似影響。感謝 Octavio Galland (Max Planck Institute for Security and Privacy)。感謝  Marcel Bhme (Max Planck Institute for Security and Privacy)。修正程式由 Viktor Dukhovni 開發。修正程式由 Matt Caswell 開發。已在 OpenSSL 1.1.1t 版中修正此問題 (受影響的是 1.1.1 和之後版本)。(CVE-2023-0215)

  - X.509 GeneralName 中有一個與 X.400 位址處理相關的類型混淆弱點。
    X.400 位址被剖析為 ASN1_STRING，但 GENERAL_NAME 的公開結構定義錯誤地將 x400Address 欄位的類型指定為 ASN1_TYPE。此欄位隨後會被 OpenSSL 函式 GENERAL_NAME_cmp 解譯為 ASN1_TYPE，而非 ASN1_STRING。啟用 CRL 檢查時 (即應用程式設定 X509_V_FLAG_CRL_CHECK 旗標)，此弱點可能允許攻擊者向 memcmp 呼叫傳遞任意指標，使其能夠讀取記憶體內容或發動拒絕服務攻擊。在大多數情況下，攻擊者需要同時提供憑證鍊和 CRL，兩者都不需要有效的簽章。如果攻擊者只控制其中一個輸入，則另一個輸入必須已包含 X.400 位址作為 CRL 發佈點，此情況並不常見。因此，此弱點最有可能只影響已實作透過網路擷取 CRL 這一功能的應用程式。感謝 David Benjamin (Google)。修正程式由 Hugo Landau 開發。已在 OpenSSL 1.1.1t 版中修正此問題 (受影響的是 1.1.1 和之後版本)。(CVE-2023-0286)

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

偵測

Slackware Linux 15.0/最新版 OpenSSL 多個弱點 (SSA:2023-038-01)

high Nessus Plugin ID 171086

版本 1.2