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

  - 在 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)

  - 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 這一功能的應用程式。(CVE-2023-0286)

  - 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 RSA Decryption 實作中存在計時型旁路，其足可在 Bleichenbacher 式攻擊中跨網路復原純文字。若要成功解密，攻擊者必須能夠傳送大量的試用訊息以進行解密。
    此弱點會影響所有 RSA 填補模式：PKCS#1 v1.5、RSA-OEAP 和 RSASVE。例如，在 TLS 連線中，用戶端通常會使用 RSA 將加密的 pre-master 密碼傳送至伺服器。攻擊者若觀察到用戶端與伺服器之間存在真正連線，就可以利用此缺陷將試用訊息傳送至伺服器，並記錄處理這些訊息所用的時間。攻擊者獲得充足的訊息之後，便可復原用於最初連線的 pre-master 密碼，進而能夠解密透過該連線傳送的應用程式資料。(CVE-2022-4304)

  - 公開 API 函式 BIO_new_NDEF 是一個用於透過 BIO 串流 ASN.1 資料的 helper 函式。此函式主要用於 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 命令行應用程式受到類似影響。(CVE-2023-0215)

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

偵測

Nutanix AOS：多個弱點 (NXSA-AOS-6.5.6.6)

critical Nessus Plugin ID 206674

版本 1.8