突发！无数网站沦陷！php漏洞源码分析！

DAVID C

• 閱讀時間 11 分鐘
分享
突发！无数网站沦陷！php漏洞源码分析！

📌 突发！无数网站沦陷！php漏洞源码分析！

深入剖析 PHP 核心漏洞：遠端程式碼執行與底層記憶體管理失誤

⓵ 【容易懂 Easy Know】

想像一下你在玩一個建造遊戲，每當你要放置一個新方塊時，你都會先告訴遊戲「我要放一個方塊了！」（增加計數），然後才實際去放方塊。但如果這時候遊戲突然告訴你「沒空間了！」（記憶體不足），並且直接強制遊戲重啟，結果就是你說要放的方塊沒放成，但遊戲卻以為方塊已經增加了。下次遊戲啟動時，它會嘗試處理這些「不存在」或「半完成」的方塊，這就像是遊戲內部出現了混亂或錯誤，讓壞人有機可乘，可以透過特別設計的訊息來操控遊戲，讓它執行不該做的事情。另一個問題是，遊戲伺服器在處理完一個玩家後，沒有完全清空該玩家的舊資料，導致下一個玩家可能會意外讀到這些舊資料，也可能造成問題。PHP 這次的漏洞就是因為這些底層「沒處理乾淨」的小細節，讓整個系統變得不安全。

⓶ 【總結 Overall Summary】

本次深入探討的 PHP 核心漏洞，影響面廣泛且層級深入至語言本身，而非特定框架。這些漏洞讓攻擊者無需觸及任何業務程式碼，僅透過構造惡意請求即可實現遠端程式碼執行（Remote Code Execution, RCE）。漏洞的根源主要來自兩個核心機制處理不當：PHP 底層哈希表的運作方式，以及 FPM Worker 的請求複用模型。

漏洞一 發生在 PHP 哈希表的新增鍵值操作中。在底層，PHP 會先更新哈希表的計數器（unnum_used 和 unnum_of_elements），然後才嘗試為鍵分配記憶體並寫入數據。然而，當記憶體分配因觸發單進程記憶體上限（MemoryLimit）而失敗時，PHP 不會返回錯誤，而是直接透過 longjmp 機制（即 bio-out）中斷當前所有執行流程。這導致計數器已累加，但實際的鍵、哈希值和對應的 Value 卻未被寫入，造成哈希表中出現「半初始化」的槽位，其 Value 包含堆上遺留的「髒數據」（野指標）。在請求結束後的資源清理階段，PHP 會遍歷哈希表並銷毀每個 Bucket，此時若解析到這些髒數據，攻擊者便可精心構造請求內容，控制髒數據中的值，誘導解析函數回調至任意地址，從而觸發 RCE。

漏洞二 則與 FPM Worker 的狀態複用和 PHP upload_progress 功能有關。PHP 的 FPM Worker 在處理完請求後不會立即退出，而是會重置狀態以處理下一個請求，以節省啟動時間。然而，upload_progress 這一追蹤文件上傳進度的功能，其初始化時機非常早，甚至在正式請求數據解析之前。若攻擊者構造一個會導致 bio-out 提前退出的請求，upload_progress 相關的全域指標在 Worker 清理後，仍可能指向已被釋放但未被清空的記憶體。當同一個 Worker 處理下一個正常請求時，upload_progress 邏輯再次運行並訪問這些全域指標，實際上卻是訪問到上一次請求釋放後又被重新分配的記憶體區塊。攻擊者因此能透過第一次請求「污染」這塊記憶體，在第二次請求中加以利用，進而控制程式流程。

這兩個漏洞的共同根源在於，當 bio-out 異常分支觸發時，資源的清理是不完整的，未能保證操作的原子性。PHP 官方的修復方案並未採取直覺上的簡單程式碼順序調整（因為哈希表是底層核心結構，修改順序恐帶來不可預知的風險），而是改進了記憶體溢出的處理策略：對於軟記憶體超限，延遲 bio-out 直到當前原子操作完成；對於硬記憶體超限，則直接 exit() 殺掉 Worker 進程，避免正常清理流程中對髒哈希表的遍歷。這事件也為開發者提供了寶貴啟示：在編寫核心或基礎層級程式碼時，必須深入考量操作的原子性，並預判任何一行程式碼在中斷後可能造成的狀態不一致問題。

⓷ 【觀點與評論 Viewpoints】

  • 底層語言缺陷的廣泛影響力
    這個漏洞並非 PHP 框架層面，而是直接存在於 PHP 語言本身的底層。這意味著無論上層應用使用何種框架（如 Laravel, Symfony 等），只要使用 PHP 運行，都可能受到影響。這凸顯了核心語言穩定性與安全性對整個生態系統的重要性。
  • 非原子操作在異常處理下的危險性
    兩個漏洞的核心都指向一個問題：在 bio-out（即 longjmp）這樣的異常中斷機制下，多步操作（例如更新計數器、分配記憶體、寫入數據）未能保持原子性。當流程被強制中斷，部分狀態已更新而部分操作未完成，導致數據結構處於不一致的「半初始化」狀態。這提醒所有程式設計師，在涉及多步驟數據修改時，務必確保其原子性或具備完善的回滾機制，特別是在面對異常情況時。
  • 核心數據結構修改的複雜與風險
    PHP 官方並未簡單地調整哈希表的程式碼執行順序，而是選擇了更複雜的記憶體溢出處理策略。這反映出哈希表作為 PHP 引擎最基礎的數據結構之一，其內部邏輯可能存在複雜的依賴關係，任何微小的改動都可能帶來不可預知的連鎖反應和更大的風險。這強調了對核心系統進行修改時，必須極端謹慎且全面評估其潛在影響。
  • 狀態管理在長生命週期進程中的挑戰
    FPM Worker 的複用模型旨在提升效能，但其狀態管理若不嚴謹，便會導致跨請求的數據殘留問題。當 Worker 處理完一個請求後，若有全域狀態或指標未被妥善清理或重置，就可能影響到下一個請求，形成安全漏洞。這對所有使用長生命週期進程或執行緒的系統設計者來說，都是一個重要的警示，必須確保在每次任務執行前後，環境都能被徹底初始化或清理。
  • 「防禦性程式設計」的最高境界
    影片最後提到，開發者在撰寫程式碼時，應多設想程式碼在任何一行被中斷後可能發生的情況。這是一種極致的防禦性程式設計思維，尤其對於開發底層引擎、作業系統或中間件的工程師而言至關重要。這不僅需要考慮正常的執行流程，更要考慮各種邊緣情況、錯誤處理和異常中斷下的數據一致性。

⓸ 【重點條列 Key Points】

  • 📌 PHP漏洞影響廣泛：本次漏洞屬 PHP 語言本身缺陷，非框架問題，影響面極廣。
  • ⚠️ 遠端程式碼執行(RCE)：攻擊者無需業務程式碼，即可透過遠端請求觸發 RCE。
  • 📊 漏洞一根源：PHP 哈希表在記憶體超限 (MemoryLimit) 觸發 longjmp 時，計數器已更新但鍵值未初始化，導致數據結構不一致。
  • ✅ FPM Worker 複用風險：FPM Worker 處理完請求不退出，若狀態清理不當，可能導致跨請求數據殘留。
  • 📌 漏洞二關聯：upload_progress 功能初始化過早，若在前一個請求中斷，其全域指標可能指向已釋放但未清空的記憶體。
  • ⚠️ 根本原因：兩個漏洞皆因 bio-out 異常分支下的資源清理不完整，未能保證操作的原子性。
  • 🛡️ 官方修復策略：並非簡單調整程式碼順序，而是針對記憶體溢出實施更複雜處理：軟限制延遲 bio-out；硬限制直接 exit worker。
  • 💡 開發啟示：開發底層軟體時，需時刻預想程式碼在任何行被中斷的後果，確保數據結構一致性與操作原子性。

⓹ 【測驗三題 3-Question Quiz】

第一題：
PHP 的第一個漏洞主要原因與下列哪項情況最直接相關？
A. PHP 框架的輸入驗證不嚴謹。
B. 在 MemoryLimit 觸發 longjmp 時，哈希表計數器已更新但鍵值數據未被初始化。
C. 資料庫連接洩漏導致的記憶體溢出。
D. 使用者上傳惡意檔案繞過內容檢查。

正確答案：B
解析： 影片中明確指出，第一個漏洞源於在哈希表插入鍵值時，雖然計數器已累加，但如果因 MemoryLimit 觸發 longjmp，後續的鍵值記憶體分配與數據寫入操作會被跳過，導致哈希表處於不一致狀態。

第二題：
PHP 官方為何沒有直接透過調整哈希表內部程式碼的執行順序來修復第一個漏洞（例如先分配記憶體再更新計數器）？
A. 這樣的修改會嚴重降低 PHP 的運行效能。
B. 哈希表是 PHP 引擎的基礎結構，直接調整其核心邏輯可能引入更多不可控的風險。
C. 官方認為程式碼順序並非根本問題所在。
D. 技術上無法實現先分配記憶體再更新計數器。

正確答案：B
解析： 影片中強調，哈希表是 PHP 極為基礎的結構，許多其他邏輯都可能依賴於其現有順序。因此，直接調整順序可能導致其他潛在的、不可控的風險，其潛在的風險遠大於收益。

第三題：
對於與 upload_progress 相關的第二個漏洞，PHP 官方提供的臨時緩解方案是什麼？
A. 建議用戶將 PHP 升級到一個全新的語言版本。
B. 關閉 upload_progress 功能的設定。
C. 要求開發者在每個請求結束時手動清理所有全域指標。
D. 大幅增加 FPM Worker 的記憶體限制。

正確答案：B
解析： 影片中清楚提到，針對 upload_progress 造成的第二個漏洞，官方提供的臨時緩解措施是直接關閉 upload_progress 這個配置參數，即停用該功能。

💡 【推薦延伸續問 Suggested Follow-ups】

  1. 針對 PHP 核心引擎這類底層漏洞，除了官方修復外，開發者在日常開發中如何有效防範類似因異常中斷導致的數據結構不一致問題？
  2. FPM Worker 的狀態複用模型在提升效能的同時，也帶來了資料殘留的風險。是否有最佳實踐或架構設計模式，能更安全地管理 Worker 狀態，以避免跨請求污染？
  3. 考慮到 PHP 哈希表作為基礎數據結構的重要性，以及改變其操作順序帶來的潛在風險，有哪些更通用的程式設計原則或測試策略，可以幫助在不改動核心邏輯的前提下，提高底層模組的健壯性？

⓺ 【關鍵標籤 Hashtags】

#PHP漏洞 #遠端程式碼執行 #FPM #哈希表安全 #記憶體管理

✡ Oli小濃縮 Summary bot 為您濃縮重點 ✡

▶