資安雷達 2026 年 6 月 23 日

2026-06-23 — PKCS#7 標籤長度繞過、quinn-proto 記憶體耗盡、memmap2 未定義行為

primary=https://www.openwall.com/lists/oss-security/2026/06/22/7 primary=https://blog.calif.io/p/how-to-format-a-ciphertext primary=https://rustsec.org/advisories/RUSTSEC-2026-0185.html primary=https://rustsec.org/advisories/RUSTSEC-2026-0186.html

PKCS#7/CMS 認證標籤長度驗證缺陷同時影響 OpenSSL、WolfSSL、Bouncy Castle 與 GnuPG

oss-security 郵件論壇 · 2026-06-22

2026 年 6 月 22 日,資安研究員在 oss-security 郵件論壇揭露一項跨函式庫設計缺陷:四個廣泛使用的密碼學實作在解析 PKCS#7/CMS AuthEnvelopedData 時,均未強制執行認證標籤的最小長度,允許攻擊者將標籤縮短至單位元組並以暴力破解繞過訊息完整性驗證。受影響的專案分別獲得 CVE-2026-34182(OpenSSL)、CVE-2026-5500(wolfSSL)及 CVE-2026-12802(Bouncy Castle)。

漏洞機制

RFC 5084 規定認證標籤長度應與 AuthEnvelopedData mac 欄位一致,並建議最短 12 位元組,但規範本身未警告此欄位為攻擊者可控。各實作的信任來源不同,導致各自存在獨立的繞過路徑。詳細攻擊分析可參閱研究者部落格 「How to Format a Ciphertext」

  • OpenSSLCVE-2026-34182):直接信任 ASN.1 結構中的 aes-ICVlen 參數,DER 解碼器不套用數值範圍約束,攻擊者可將其設為 1 而不觸發任何錯誤。
  • wolfSSLCVE-2026-5500):完全忽略 aes-ICVlen,改用 mac OCTET STRING 的實際長度;攻擊者只需將其重新編碼為 04 01 XX(單位元組)即可。
  • Bouncy CastleCVE-2026-12802):GCM 引擎有 4 位元組下限,但 CCM 引擎僅在加密時驗證,解密時接受零長度標籤。
  • GnuPG gpgsm(無 CVE):路徑與 wolfSSL 類似,受 libgcrypt 的 4 位元組下限保護,仍允許約 40 億次偽造嘗試。

當標籤縮短為 1 位元組時,每次嘗試的成功機率為 1/256,實質上喪失訊息認證能力。即使是 4 位元組標籤,在現代算力下仍屬可行的暴力破解範圍。

受影響版本

  • OpenSSL:CVE-2026-34182 公告日(2026-06-09)前所有含 CMS 支援版本
  • wolfSSL:修補版本釋出前(CVE-2026-5500
  • Bouncy Castle:1.85 之前(CVE-2026-12802
  • GnuPG gpgsm:commit 4c7e68cf 合併前

修補與緩解

Bouncy Castle 已在 1.85 版中修補 CCM 引擎的零長度標籤問題。GnuPG 修補已提交至 commit 4c7e68cf,OpenSSL 與 wolfSSL 修補請參照各自安全公告。若短期內無法升級,可在應用層強制拒絕標籤長度小於 12 位元組的 CMS 訊息,或改用不依賴 PKCS#7 CMS 的驗證機制。

原始來源:oss-security · 2026-06-22blog.calif.io 技術分析


quinn-proto 無界串流重組導致遠端記憶體耗盡(RUSTSEC-2026-0185)

RustSec Advisory Database · 2026-06-22

2026 年 6 月 22 日,QUIC 協定實作函式庫 quinn-proto 發布安全公告 RUSTSEC-2026-0185(別名 GHSA-4w2j-m93h-cj5j,CVSS 7.5 HIGH):遠端攻擊者可藉由刻意製造的非連續串流片段,使伺服器端的 Assembler 無限緩衝資料,最終耗盡主機記憶體,無需任何身份驗證或使用者互動。修補版本為 0.11.15,CVSS 向量為 CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H

漏洞機制

Assembler 元件負責將亂序到達的 QUIC 串流片段重新排列為有序資料。當對端故意傳送帶有大量間隙的非連續片段,同時省略較早的片段時,接收端會持續為尚未到達的資料預留緩衝空間,原設計對已排隊的間隙數量沒有設置上限。攻擊者無需完成 QUIC 握手驗證即可觸發此行為,使其成為低門檻的拒絕服務向量。修補 PR 為 quinn#2694(標題:「proto: yield error on too many gaps in assembler」),於 2026-06-22 合併至 0.11.x 分支,修補方案在 Assembler 中加入間隙數量上限,超過閾值時回傳錯誤並終止連線。

受影響版本

  • quinn-proto < 0.11.15

修補與緩解

升級至 quinn-proto ≥ 0.11.15 即可修復此問題。若暫時無法升級,可在應用層對單一 QUIC 連線設置接收緩衝區大小上限,或限制同時存在的最大未完成串流數量以降低風險。

原始來源:RUSTSEC-2026-0185


memmap2 crate 未驗證指標偏移參數造成未定義行為(RUSTSEC-2026-0186)

RustSec Advisory Database · 2026-06-22

2026 年 6 月 22 日,Rust 記憶體映射函式庫 memmap2 發布安全公告 RUSTSEC-2026-0186:多個涉及範圍操作的函式未對 offsetlen 參數進行邊界驗證,導致非法數值被傳入指標算術運算,在 safe Rust 程式碼中觸發未定義行為(unsoundness)。

漏洞機制

advise_rangeflush_rangeflush_async_range 等函式接受使用者提供的 offsetlen 後,直接使用這些值進行指標偏移計算,再將結果指標傳入 Linux 的 madvisemsync 系統呼叫或 Windows 的對應函式。雖然非法指標本身不會被解參考,但傳入系統呼叫已足以構成未定義行為,可能導致程式崩潰或不可預期的記憶體操作。問題追蹤於 memmap2-rs#169,修補由 PR#170 實作。

受影響版本

函式受影響版本範圍
Mmap::advise_range≥0.5.9, <0.9.11
Mmap::unchecked_advise_range≥0.8.0, <0.9.11
MmapMut::advise_range≥0.5.9, <0.9.11
MmapMut::flush_range<0.9.11
MmapMut::flush_async_range<0.9.11
MmapMut::unchecked_advise_range≥0.8.0, <0.9.11

修補與緩解

升級至 memmap2 ≥ 0.9.11 即可修復所有上述函式的邊界檢查缺失。此公告被歸類為 unsoundness(無 CVSS 評分),代表即便在 safe Rust 程式碼區塊中也可能觸發未定義行為。任何在 safe 程式碼中呼叫上述函式並傳入外部輸入的專案,均應優先升級。

原始來源:RUSTSEC-2026-0186


End of article
0
Would love your thoughts, please comment.x
()
x