網路安全 on KnightLi的博客

Copy Fail 漏洞 CVE-2026-31431：Linux 核心檔案複製路徑中的容器逃逸風險

Fri, 01 May 2026 18:42:34 +0800

Copy Fail 是一個影響 Linux 核心檔案複製路徑的漏洞，編號為 CVE-2026-31431。 Bugcrowd 的分析把它稱為一個值得關注的核心級問題：在特定條件下，非特權使用者可以利用檔案複製相關邏輯觸發越權寫入，進而造成權限提升或容器逃逸。

從風險角度看，它不是普通應用層漏洞。問題發生在核心處理檔案複製和頁面快取的路徑上，因此影響面會延伸到容器、共享主機、CI/CD Runner、PaaS 平台和多租戶 Linux 環境。如果攻擊者已經能在系統裡執行低權限程式碼，漏洞就可能成為進一步突破隔離邊界的跳板。

漏洞大致發生在哪裡

Copy Fail 關聯的是 Linux 核心中的檔案複製能力。現代 Linux 提供了多種高效複製路徑，例如 copy_file_range、splice 類路徑以及不同檔案系統之間的資料複製最佳化。這些機制的目標是減少使用者態和核心態之間的資料搬運，提高大檔案複製效能。

問題在於，高效能複製路徑通常會複用頁面快取、檔案偏移、權限檢查和檔案系統回呼。如果其中某個邊界條件處理不嚴，核心可能在錯誤的權限上下文裡執行寫入，或者把本不應該被修改的資料頁暴露給攻擊者控制。

Copy Fail 的核心風險可以概括為：

攻擊者不需要 root 權限；
攻擊入口來自常見檔案複製能力；
影響點在核心態；
在容器環境裡，漏洞可能繞過命名空間和掛載隔離；
成功利用後可能寫入宿主機上不應被容器修改的內容。

這也是它被重點討論的原因。容器安全依賴 Linux 核心提供隔離能力，一旦核心路徑本身出現越權寫入，容器邊界就會變得脆弱。

為什麼容器場景更敏感

容器並不是虛擬機。容器內行程和宿主機共享同一個 Linux 核心，只是透過 namespace、cgroup、capability、seccomp、AppArmor/SELinux 等機制做隔離。

如果漏洞發生在使用者態服務裡，通常只影響某個容器或某個行程。但如果漏洞發生在核心裡，尤其是可以被非特權使用者觸發的核心漏洞，攻擊者可能從容器內部影響宿主機。

Copy Fail 的危險點就在這裡。很多平台允許使用者提交建置任務、執行腳本、啟動容器或執行外掛。攻擊者只要能在容器裡執行程式碼，就可能嘗試利用核心檔案複製路徑突破隔離。

高風險環境包括：

Kubernetes 叢集中的不可信工作負載；
CI/CD 平台的共享 Runner；
允許使用者上傳程式碼執行的沙箱平台；
多租戶 Linux 主機；
容器化 PaaS；
執行第三方外掛或擴充的系統。

如果這些環境裡的核心版本處於受影響範圍，而且缺少額外限制，風險就會明顯升高。

受影響範圍要看核心補丁狀態

這類漏洞的判斷不能只看發行版名稱。同一個 Ubuntu、Debian、RHEL、Fedora 或 Arch 版本，是否受影響取決於目前實際執行的核心套件，以及發行版是否已經回補補丁。

排查時應優先確認三件事：

目前執行核心版本；
發行版安全公告是否提到 CVE-2026-31431；
雲端廠商或託管平台是否已經完成宿主機核心修復。

可以先在系統上確認核心版本：

`1`	`uname -a`

然後查看發行版安全公告、核心 changelog 或雲端平台公告。不要只根據主版本號判斷是否安全，因為很多企業發行版會把安全補丁回補到舊版本核心裡。

臨時緩解思路

最可靠的修復方式仍然是更新核心。但在補丁無法立刻部署的環境裡，可以先降低暴露面。

常見緩解方向包括：

禁止不可信使用者執行特權容器；
避免給容器掛載敏感宿主機路徑；
收緊容器 capability，尤其不要隨意授予 CAP_SYS_ADMIN；
使用 seccomp、AppArmor 或 SELinux 限制危險系統呼叫和檔案存取；
將不可信工作負載遷移到隔離更強的虛擬機；
對 CI/CD Runner 做按任務銷毀，避免長期複用同一宿主機；
監控異常檔案寫入、權限變更和容器逃逸跡象。

這些措施不能替代補丁。它們的作用是降低攻擊成功率和影響面，特別是在補丁發布到生產環境之前爭取緩衝時間。

修復優先級

建議按環境風險排序處理。

優先修復：

對外提供容器執行能力的平台；
執行不可信程式碼的 CI/CD 節點；
多租戶 Kubernetes 節點；
有使用者自定義外掛或腳本執行能力的系統；
共享開發機、教學機、實驗平台。

相對低優先級：

單使用者桌面；
只執行可信服務的內網主機；
已經使用虛擬機隔離不可信程式碼的環境。

即便風險較低，也建議隨發行版更新核心。核心漏洞常常會被組合進更複雜的攻擊鏈裡，拖延補丁沒有太多收益。

給維運團隊的檢查清單

可以按下面順序處理：

盤點所有 Linux 主機和容器節點；
標記會執行不可信程式碼的機器；
檢查目前核心版本和發行版安全公告；
優先更新高風險節點；
對無法立即更新的節點啟用臨時隔離策略；
檢查容器執行時設定，移除不必要的特權和宿主機掛載；
更新後重啟節點，確認新核心已經實際生效；
保留變更記錄，方便後續稽核。

核心套件安裝完成並不代表系統已經執行在新核心上。更新後必須重啟，並再次確認：

`1`	`uname -a`

小結

Copy Fail / CVE-2026-31431 的重點不是某個應用崩潰，而是 Linux 核心檔案複製路徑中的權限邊界問題。它讓非特權程式碼有機會觸碰更高權限的資料寫入路徑，因此在容器和多租戶環境裡尤其值得重視。

處理這類漏洞時，最重要的是兩件事：

盡快跟進發行版或雲端廠商提供的核心補丁；
在補丁部署前限制不可信程式碼、特權容器和敏感宿主機掛載。

對個人桌面來說，它可能不是馬上需要恐慌的問題。但對執行容器平台、CI/CD、沙箱和共享主機的團隊來說，應該把它當作高優先級核心安全更新處理。

參考來源：

OpenAI 推出 Advanced Account Security：ChatGPT 和 Codex 帳號多了一層高強度保護

Fri, 01 May 2026 06:15:29 +0800

OpenAI 在 2026 年 4 月 30 日推出了 Advanced Account Security，這是面向 ChatGPT 帳號的可選進階安全設定。

它主要服務兩類使用者：一類是記者、民選官員、政治異議人士、研究人員等更容易遭遇定向攻擊的人；另一類是希望給 ChatGPT 和 Codex 帳號加上更強保護的安全敏感使用者。

這項功能開啟後，不只保護 ChatGPT，也會保護同一登入帳號下存取的 Codex。

為什麼 ChatGPT 帳號需要更高安全等級

現在很多人會把 ChatGPT 用在越來越私密、越來越高風險的工作裡。

一個 ChatGPT 帳號裡可能包含：

個人問題和長期對話
工作文件與專案上下文
已連接工具和工作流程
Codex 裡的程式碼與開發任務
企業、研究或安全相關材料

如果帳號被接管，損失不只是聊天記錄外洩。攻擊者還可能存取連接的工具、查看敏感上下文，甚至干擾使用者正在進行的工作。

所以 OpenAI 這次推出的不是一個普通登入選項，而是一組更嚴格的帳號保護措施。

Advanced Account Security 包含哪些保護

OpenAI 把這項能力放在 ChatGPT 網頁端帳號的 Security 設定裡，使用者可以主動開啟。

開啟後，它會從幾個方面提高帳號安全性。

第一，登入方式更強。

Advanced Account Security 要求使用 passkeys 或實體安全金鑰，並禁用基於密碼的登入。這樣做的目的，是讓更抗釣魚的登入方式成為預設選擇。

第二，帳號恢復更嚴格。

傳統帳號恢復經常依賴信箱或簡訊。如果攻擊者控制了使用者的信箱或手機號碼，就可能藉此重設帳號。為降低這個風險，Advanced Account Security 會禁用郵件和 SMS 恢復，改用更強的恢復方式，例如備用 passkeys、安全金鑰和恢復金鑰。

這裡有一個重要代價：開啟後，帳號恢復會更依賴使用者自己保管這些恢復方式。OpenAI 明確說明，已開啟該功能的使用者如果遺失恢復手段，OpenAI Support 無法協助恢復帳號。

第三，工作階段時間更短，管理更清楚。

OpenAI 會縮短登入工作階段，以降低裝置或活躍工作階段被盜用後的暴露窗口。使用者也會收到登入提醒，並可以查看和管理目前登入的裝置工作階段。

第四，自動排除訓練。

對處理敏感資訊的人來說，不讓對話用於模型訓練是一項重要隱私設定。開啟 Advanced Account Security 後，這個偏好會自動生效：這些帳號的對話不會用於訓練 OpenAI 模型。

與 Yubico 合作推廣實體安全金鑰

OpenAI 還宣布與 Yubico 合作，給使用者提供定製的安全金鑰組合。

其中包括：

YubiKey C Nano：適合長期插在筆電上，日常登入摩擦更小
YubiKey C NFC：適合作為備用，也方便在筆電和行動裝置之間使用

OpenAI 表示，使用者也可以使用其他符合 FIDO 標準的實體安全金鑰，或者使用軟體 passkeys。

這說明 Advanced Account Security 並不綁定某一種硬體，而是圍繞抗釣魚認證方式設計。

Cyber 可信存取使用者會被要求開啟

OpenAI 還提到，針對 Trusted Access for Cyber 的個人成員，如果他們要存取更強、更寬鬆的網路安全模型，從 2026 年 6 月 1 日開始將被要求開啟 Advanced Account Security。

組織使用者可以用另一種方式滿足要求：證明自己的單一登入流程已經採用抗釣魚認證。

這個安排很合理。越強的模型能力越需要更強的帳號保護，尤其是面向網路安全研究、漏洞分析和紅隊等場景時，帳號本身就會成為高價值目標。

適合誰開啟

這項功能不一定適合所有人。

如果只是普通聊天，且不想承擔更嚴格帳號恢復帶來的複雜性，可以先觀望。

但以下使用者值得認真考慮：

經常在 ChatGPT 中處理敏感工作材料的人
使用 Codex 處理私有程式碼倉庫的人
記者、公共事務人員、研究人員、企業高階主管等高風險使用者
網路安全從業者
已經習慣使用 passkeys 或實體安全金鑰的人
對帳號被釣魚、簡訊劫持或信箱接管特別敏感的人

開啟之前，最好先準備好備用 passkey、安全金鑰和恢復金鑰，並確認它們被妥善保存。否則，安全性提高的同時，帳號恢復難度也會明顯提高。

這對 AI 產品意味著什麼

Advanced Account Security 不是一個模型能力更新，但它反映了 AI 產品正在進入更高風險的使用階段。

當 ChatGPT 和 Codex 開始承載工作流程、程式碼、文件、企業連接器和長期上下文時，帳號就不再只是「登入聊天工具」的入口，而是 AI 工作環境的鑰匙。

這類產品越像個人工作台，帳號安全、恢復機制、工作階段管理和訓練資料控制就越重要。

OpenAI 這次把 passkeys、實體安全金鑰、恢復限制、工作階段管理和訓練排除放到同一個設定裡，方向是對的。它讓高風險使用者可以用一個明確入口，把帳號保護提升到更適合敏感工作的級別。

小結

Advanced Account Security 可以理解為 ChatGPT 和 Codex 的高安全模式。

它透過更強登入、更嚴格恢復、更短工作階段、登入提醒和自動排除訓練，降低帳號被接管後的風險。代價是使用者需要更認真地管理自己的恢復方式，因為開啟後傳統郵件和簡訊恢復不再可用，OpenAI Support 也無法替使用者兜底。

如果你已經把 ChatGPT 或 Codex 用在重要工作裡，尤其是涉及私有程式碼、敏感文件或高風險身份，這項功能值得關注。

參考連結：

Introducing Advanced Account Security - OpenAI

hackingtool：一站式安全工具集合的用途、風險和學習邊界

Fri, 01 May 2026 03:45:00 +0800

hackingtool 是一個把大量安全工具集中到一起的工具集合專案。

從 README 的描述看，它覆蓋的方向很廣，包括匿名工具、資訊收集、漏洞分析、Web 攻擊、無線網路、取證、payload、逆向工程、DDoS、遠端管理、釣魚相關工具等。它更像一個安全工具導航器，而不是一個只解決單一問題的小工具。

這類專案很容易被誤解，所以先說邊界：安全工具只能用於授權環境、實驗室、靶場、CTF 或自己的系統。不要把它用於未授權目標。本文只做專案定位和學習路線整理，不提供攻擊步驟、濫用命令或繞過指導。

它解決什麼問題

剛開始學習網路安全時，很多人會遇到一個問題：工具太多，不知道該從哪裡開始。

你可能聽過：

資訊收集工具
Web 漏洞掃描工具
密碼審計工具
無線網路測試工具
取證分析工具
逆向工程工具
payload 生成工具
匿名和代理工具

單獨看每一類，都能找到很多專案。問題是，新手很難判斷它們分別做什麼、適合什麼場景、風險在哪裡。

hackingtool 的價值就在於把這些工具按類別聚合，讓學習者先看到安全工具生態的大致版圖。

它不一定是每個工具的最佳安裝方式，也不一定適合生產環境，但適合用來建立初步認知：網路安全不是一個工具，而是一組目標、方法和邊界。

工具集合的優點

這類集合專案的優點很明顯。

第一，降低入門搜尋成本。

你不需要一開始就知道每個工具名。透過分類目錄，可以先知道安全學習大概有哪些方向。

第二，適合搭建實驗室。

如果你在本地虛擬機、Kali、Parrot、Ubuntu 實驗環境或 CTF 靶場裡學習，工具集合可以幫助你快速補齊常見工具。

第三，方便對比同類工具。

同一個方向通常有多個工具。比如資訊收集、Web 測試、密碼審計、取證分析，都有不同實現和適用場景。把它們放在一起，方便初學者橫向觀察。

第四，幫助理解安全鏈路。

真實安全測試不是「執行一個工具就結束」。通常會經歷資產識別、資訊收集、漏洞驗證、影響評估、修復建議和報告整理。工具分類能幫助你理解每個環節大概對應哪些能力。

也要看到風險

工具集合越大，風險越需要認真看。

第一，工具品質不一定一致。

集合專案可能收錄很多第三方工具，它們的維護狀態、程式碼品質、依賴安全、相容性和授權都不一樣。不要預設所有工具都安全可靠。

第二，安裝腳本可能有供應鏈風險。

安全工具通常需要較高權限、網路存取、系統依賴和外部下載。執行任何安裝腳本前，都應該先閱讀腳本內容，確認來源可信，最好在隔離環境裡測試。

第三，部分工具具有明顯攻擊屬性。

README 中涉及 DDoS、payload、釣魚、遠端存取等方向。這些工具在授權實驗室裡可以用於學習攻防原理，但在真實目標上濫用會造成嚴重法律和倫理問題。

第四，工具不能替代基礎知識。

只會執行工具，不理解網路協議、系統原理、Web 安全、權限模型和日誌分析，很容易做出錯誤判斷。工具輸出也可能誤報或漏報。

適合怎樣學習

如果你想用這類專案學習安全，更推薦按主題拆開，而不是一次性安裝所有東西。

可以從這些方向開始：

網路基礎：理解 IP、連接埠、DNS、HTTP、TLS
Linux 基礎：理解權限、程序、檔案系統、服務管理
Web 安全：理解認證、授權、輸入驗證、會話、常見漏洞
資訊收集：學習資產識別和公開資訊整理
漏洞驗證：只在本地靶場或授權系統中實驗
取證分析：學習日誌、磁碟、記憶體和流量證據
防禦視角：理解偵測、加固、修補和報告

這樣學會更穩。

工具應該服務於知識，而不是反過來讓工具牽著走。

適合的使用場景

hackingtool 更適合這些場景：

安全初學者了解工具分類
CTF 或靶場環境準備工具
搭建隔離實驗室
學習不同安全方向的工具生態
研究安全測試流程
對比同類工具的用途差異

它不適合：

對未授權目標進行掃描或攻擊
在生產機器上隨意安裝大量工具
把工具輸出直接當成安全結論
在不了解腳本內容時以高權限執行
把攻擊類工具用於真實網路環境

為什麼不建議一鍵全裝

很多工具集合都提供「一鍵安裝」的思路，但實際使用時要謹慎。

一鍵全裝的問題包括：

依賴衝突
系統環境被污染
下載源不可控
安裝大量你根本不會用的工具
難以維護和更新
很難審計每個工具做了什麼

更好的方式是按學習主題安裝。

今天學資訊收集，就只安裝相關工具；下週學 Web 安全，再補 Web 測試工具；做取證實驗時，再準備取證工具。這樣環境更乾淨，學習目標也更清楚。

如何安全地使用這類倉庫

第一，使用隔離環境。

建議在虛擬機、容器或專門的實驗機器裡使用，不要直接污染主力工作系統。

第二，只連接授權目標。

目標可以是本地靶場、CTF 平台、自己搭建的測試服務，或者明確授權的安全測試範圍。

第三，先讀腳本再執行。

不要複製 README 裡的命令就直接執行。先看安裝腳本、依賴來源、權限需求和網路存取行為。

第四，記錄實驗過程。

安全學習不只是跑工具。記錄輸入、輸出、判斷依據、誤報原因和修復建議，才能真正提升能力。

第五，學習防禦視角。

每學一個攻擊面，都應該同時理解對應的防禦方法：如何發現、如何加固、如何記錄證據、如何寫報告。

和 Kali Linux 有什麼區別

Kali Linux 是一個面向滲透測試和安全研究的發行版，已經內建並維護了大量安全工具。

hackingtool 更像一個工具安裝和分類集合。它可以幫助你認識工具生態，但它不是一個完整的安全發行版，也不等同於 Kali 的維護體系。

如果你是初學者，Kali、Parrot、Ubuntu 虛擬機加靶場環境，通常比在主機上一鍵安裝工具集合更穩。

如果你已經有自己的實驗環境，hackingtool 可以作為工具索引參考。

使用邊界

安全工具的邊界非常重要。

合法場景包括：

自己的實驗環境
CTF 和靶場
公司授權的安全測試
課程實驗
本地研究和防禦驗證

不合適的場景包括：

未授權掃描公網目標
對第三方網站進行漏洞嘗試
釣魚、盜號、繞過存取控制
干擾服務可用性
未經允許收集或利用他人資料

判斷標準很簡單：沒有明確授權，就不要測試。

適合怎樣的人

hackingtool 適合有學習目標的人，而不是只想「點一下就黑掉什麼」的人。

它適合：

網路安全初學者
CTF 學習者
安全實驗室搭建者
想了解工具分類的人
想把攻防知識和工具對應起來的人

如果你還不熟悉 Linux、網路基礎、Web 基礎和權限概念，建議先補基礎，再使用這類工具集合。否則很容易只記住命令，卻不理解結果。

參考

Z4nzu/hackingtool

最後一句

hackingtool 可以作為網路安全工具生態的入口，但它不應該被當成無邊界使用的攻擊工具箱。

真正有價值的安全學習，是在授權環境裡理解原理、驗證風險、學習防禦，並把工具輸出轉化成可解釋、可修復的安全結論。