iT邦幫忙

0

《AI 威脅倍增器:架構缺陷為何成為新前沿》

  • 分享至 

  • xImage
  •  

執行摘要

  • 現代的 macOS 二進制檔案通常具備強大的平台緩解措施,例如 PIEASLR 和代碼簽名。但我們好奇,當一個現代應用程式與數十年歷史的 POSIX 規則發生衝突時,會發生什麼情況。

  • 在我們對一個已簽章的 OpenSSL 包裝器二進制檔案(使用我們內部開發的 AI 研究工具「Hallucinator」)- 進行的分析中,我們驗證了一個關鍵的訊號可重入性弱點:傳統的 TLS 功能與在非同步環境中被認為危險的訊號、標準輸入輸出(stdio)和記憶體原語共存。

  • 雖然環境限制阻礙了端到端的漏洞利用確認,但我們的靜態和動態證據強烈支持存在高風險的**[[阻斷服務攻擊]]**條件,並且在不利的時序條件下,可能升級為釋放後使用。

  • 這篇文章詳細說明了已確認的證據,探討了合理的風險,並解釋了為什麼安全領導者必須超越合規檢查清單來評估架構威脅。

目標與證據邊界

為確保這項研究嚴格具備可辯護性,我們特意將直接觀察到的結果與需要額外運行時檢測才能確認的結果分開。

目標元數據

  • 目標: openssl(macOS Mach-O 通用二進制檔案)

  • SHA-256: 5a7d226a379afa156ea96068abd51da74f5f86cd2eb5b6b17ac45ee002d340b4

已確認的靜態證據

  1. 傳統 TLS 功能: 符號證據確認存在 _TLSv1_client_method()。

  2. 非同步不安全原語: 符號證據確認存在 _signal()、_fprintf() 和 _free()。

  3. 生產狀態: 代碼簽名、哈希輸出和文件元數據確認這是一個真實的、已簽章的 macOS 工件,而非合成的測試代碼。

這三點建立了一個高度可信的可重入性弱點模式,將此問題從一般的靜態分析警告提升為一個已驗證的架構缺陷。

CVSS:3.1/AV:L/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:H

基於當前證據的暫定評分: [[CVSS v3.1 = 5.1(中等)]]

目前可辯護主張的建議基礎向量:
為何暫定評分僅為中等?

  • 我們有強有力的靜態弱點證據,但沒有確認的漏洞利用鏈。

  • 影響主要是可用性風險(可能導致掛起或崩潰)。

  • 目前來看,漏洞利用似乎高度複雜。

核心漏洞:訊號引發的狀態混亂

這是一種常見的開發者反模式:設定了一個看門狗計時器,如果它觸發,開發者希望記錄事件並在退出前清理記憶體。他們在訊號處理程式中快速編寫了 fprintf(stderr,"Timeout..."),緊接著是 free()。在單元測試中,它似乎完美運作。

然而,在訊號處理程式中呼叫像 fprintf 和 free 這樣的函式,違反了基本的 POSIX [[非同步訊號安全規則]]。

當 OpenSSL 處理複雜的狀態轉換(例如關閉一個失敗的 TLS 連接)時,它在很大程度上依賴系統的記憶體分配器。訊號處理程式相對於正常控制流程是非同步執行的。如果攻擊者能夠精心計時一個網路封包,將回應延遲到剛好觸發 SIGALRM 看門狗,訊號處理程式將會突然中斷正在執行中的OpenSSL 關閉程序。

如果 fprintf 嘗試動態分配緩衝區空間,而主執行緒在會話清理期間仍然持有 libmalloc 堆積鎖,程式狀態就可能損壞。這種交集所帶來的實際、已確認的安全影響是嚴重的效能不穩定、程序掛起和非同步的阻斷服務攻擊。

催化劑:透過協議降級擴大攻擊視窗

在記憶體清理過程中擊中一個極微小的競爭條件是非常困難的。這就是 _TLSv1_client_method 的存在改變風險輪廓的地方。

傳統的 TLS 交握本質上比現代的 TLS 1.3 實作「更嘈雜」且狀態更密集。傳統密碼套件的錯誤處理和會話失效邏輯涉及 OpenSSL 內部結構中更廣泛的記憶體清理。

通過主動強制連接降級,攻擊者不一定試圖破壞加密;他們是有意將 OpenSSL 狀態機推向最老舊、延遲最高的程式碼路徑。這理論上會延長關閉程式的執行視窗,從而顯著提高成功觸發訊號中斷的可能性。

可利用性差距:阻斷服務 vs. 釋放後使用

在我們當前的執行環境中,運行時在驗證期間被強行終止(exit 137),並且 lldb 附加受到限制。由於這些限制,我們無法捕獲確鑿的死鎖追蹤記錄,也無法確認確定性的釋放後使用漏洞利用。

  • 風險等級: 高(可用性影響,加上時序壓力下的潛在完整性風險)

  • 信心水準: 對弱點模式的存在為中高;對最壞情況下的記憶體損壞影響為中等。

  • 結論: 我們已確認一個高風險的可重入性模式:一個已簽章的現代二進制檔案,在傳統協議路徑和非同步假設衝突時,暴露了高價值的弱點鏈。

在證據輸出文件(tmp.txt)中,同一個已簽章的 Mach-O二進制檔案包含 _TLSv1_client_method 以及 _signal、_fprintf 和 _free。這種共存是關鍵的技術條件:傳統的 TLS 功能程式碼路徑,加上非同步訊號處理原語和非同步不安全的 libc 使用,共同證實了高風險的可重入性弱點模式。

Demo-openssl-glitch % otool -Iv openssl > tmp.txt 2>&1 Demo-openssl-glitch % cat tmp.txt | grep -En "_TLSv1_client_method| _signal| _fprintf| _free" 620:0x0000000100035c1c 3132 _TLSv1_client_method 919:0x0000000100036ecc 3440 _fprintf 922:0x0000000100036efc 3443 _free 923:0x0000000100036f0c 3444 _freeaddrinfo 924:0x0000000100036f1c 3445 _freezero 1004:0x000000010003741c 3527 _signal # 1138:0x000000010004c318 3132 _TLSv1_client_method 1923:0x000000010004dba0 3445 _freezero 2010:0x000000010004de58 3440 _fprintf 2013:0x000000010004de70 3443 _free 2014:0x000000010004de78 3444 _freeaddrinfo 2048:0x000000010004df88 3527 _signal

CISO 視角:將技術缺陷轉化為業務風險

對於在複雜環境中進行管理的安全領導者而言,這類漏洞帶來了四個獨特的挑戰,這些挑戰規避了標準的合規性檢查:

  1. 「幽靈當機」與不斷擴大的平均修復時間

  2. 「綠色儀表板」的假象

  3. 作為利用槓桿的遺留技術債務

  4. AI 威脅倍增器(使複雜漏洞利用民主化)

「幽靈當機」與不斷擴大的平均修復時間

與會產生清晰區段錯誤並生成崩潰轉儲的標準緩衝區溢位不同,堆積鎖競爭會導致程序凍結。 它不會死亡;它只是停止服務請求。標準的正常運行時間監控可能顯示該程序仍在「執行中」,從而延遲事件響應。當工程師進行調查時,缺乏崩潰日誌使得根本原因分析變得極其困難,從而急劇增加了平均修復時間。

「綠色儀表板」的假象

此二進制檔案經過數位簽章,並使用了現代的記憶體保護機制,如位置無關可執行檔。 在標準的合規儀表板或基本漏洞掃描中,此資產可能看起來是安全的。這個漏洞凸顯了僅僅依賴基礎平台緩解措施的危險。作業系統層級的強化無法防禦涉及POSIX 並發違規的深層架構邏輯缺陷。

作為利用槓桿的遺留技術債務

資訊安全團隊通常會接受遺留協議(例如 TLS 1.0)的風險,理由是「沒人會用它」或「它只在中間人解密時構成風險」。 這項研究表明,遺留技術債務可以被積極地武器化,以啟用完全不同類別的攻擊。舊的TLS 實作不僅僅是弱加密;它正是攻擊者需要的、用來延長競爭條件視窗並執行記憶體損壞攻擊的槓桿。

AI 威脅倍增器(使複雜漏洞利用民主化)

以前,發現並串聯 POSIX 並發違規與傳統密碼學降級以實現狀態機失步,是精英漏洞研究人員的領域。如今,進攻性 AI 工具和[[大型語言模型]]輔助逆向工程的爆炸性成長,已大大降低了進入門檻。

攻擊者現在可以大規模自動化發現這些晦澀的架構交集。隨著威脅行為者檢測和武器化這些缺陷所需的認知複雜度降低,企業因未修補多階段邏輯漏洞而面臨的風險將呈指數級增長。

緩解策略

為了消除這個複雜的漏洞利用鏈,補救措施必須同時解決程式碼層級的根本原因和架構上的促成因素,具體方法如下:

  • 重構不安全的處理程式

  • [[在邊緣終止遺留協議]]

  • 升級到深度存活探測

  • 發展到持續威脅暴露管理和 AI 驗證

重構不安全的處理程式(根本原因)

開發人員必須嚴格從訊號處理程式中移除非同步訊號不安全的函式(free、fprintf)。強制使用
「[[self-pipe 技巧]]」將複雜的關閉邏輯安全地委派給主應用程式的事件迴圈。

在邊緣終止遺留協議(催化劑)

不要依賴本機應用程式設定。在您的邊界([[Web應用防火牆]]/負載平衡器)強制執行嚴格的TLS 1.2
或更高版本的最低要求,以防止攻擊者利用操作延遲來擊中這些微小的競爭條件。

升級到深度存活探測(營運韌性)

標準的正常運行時間監控無法捕捉堆積鎖競爭。部署能夠主動驗證記憶體分配和程序狀態的合成事務,
確保死鎖的「幽靈」程序能被立即標記並重新啟動。

發展到持續威脅暴露管理和 AI 驗證(策略)

傳統的靜態應用程式安全測試會錯過這些架構交集。將 AI 驅動的動態測試整合到您的[[持續威脅暴露管理]]
週期中,以便在攻擊者將其武器化之前,主動映射並破壞多步驟邏輯鏈。

原文出處


圖片
  熱門推薦
圖片
{{ item.channelVendor }} | {{ item.webinarstarted }} |
{{ formatDate(item.duration) }}
直播中

尚未有邦友留言

立即登入留言