Video thumbnail for The Dumbest AI Security Flaw

AI安全漏洞:千萬別這樣做!Langflow程式碼驗證慘痛教訓

Summary

Language:

Quick Abstract

想知道新創公司如何因為過度依賴AI而陷入安全漏洞嗎? 我們將深入探討Langflow的案例,這是一個低代碼AI代理建構工具,它暴露了一個嚴重的遠端程式碼執行(RCE)漏洞。 了解為何驗證程式碼時執行程式碼是大忌,以及如何避免類似的災難。

  • 快速重點:

    • Langflow 是一個低代碼工具,允許使用者透過拖放介面建構 AI 代理,乍看之下好像技術很先進,但實際可能暗藏風險。

    • Langflow 有一個 API 端點 /apiv1/validate_code,本意是用來驗證使用者提交的 Python 程式碼,但實際上卻直接在伺服器上執行程式碼。

    • Horizon 3.ai 發現 Langflow 在驗證程式碼時未進行沙箱化或輸入清理,導致駭客可以利用惡意裝飾器(decorator)執行任意程式碼。

    • 此漏洞已在 Langflow 1.0.0 版本中修補,透過沙箱化程式碼執行來解決問題。

    • 重點警惕:在構建任何允許使用者提交程式碼的系統時,絕對不要直接執行不可信任的程式碼。 務必隔離、Docker 化,或採取其他安全措施。

    • 過度依賴 AI 且缺乏安全意識是主要問題,確保人類專家監督 AI 系統至關重要,以避免安全漏洞。

新創公司與 AI 的災難:Langflow 的慘痛教訓

讓我為你描繪一個畫面。你正在建立一家新創公司,剛從一位穿著 Patagonia 背心的名叫 Chad 的人那裡籌集了 1000 萬美元。你的簡報 deck 中提到了 47 次 AI,還有一張鋼鐵人的照片,因為你想顛覆智慧領域。很自然地,你把 GPT 塞進你的應用程式,添加一些流程圖,然後就完成了。你現在是一個企業數據代理工作流程的 AI 自動化平台。無論那是什麼意思。而這就是 Langflow 的用武之地。Langflow 是一種低代碼工具,它讓你看起來好像在做一些非常技術性的事情,而實際上你只是在畫一些色彩繽紛的方框,上面寫著「呼叫 OpenAI」和「查詢 MongoDB」。基本上,它就像一個用於構建 AI 代理的可視化腳本工具。

Langflow 的漏洞:一個關於任意程式碼執行的故事

現在,這是讓我捧腹大笑的部分。他們有一個端點,一個實際暴露的 API 端點,叫做 /apiv1/validate_code。聽起來無害,對吧?只是一個小小的驗證步驟,檢查程式碼是否合法,確保你沒有上傳一個將你的伺服器變成加密貨幣礦工的腳本。

  • 然而,他們忘記了一個小細節。當你驗證使用者提交的 Python 程式碼時,你實際上應該執行程式碼。

  • 但事實上,他們就是這麼做的。這個端點接受 Python 程式碼,然後在伺服器上解析和評估它,沒有沙盒化,沒有輸入清理,沒有隔離。只是直接在後端執行任意 Python 程式碼。

Langflow 的程式碼實際上解析了抽象語法樹(Abstract Syntax Tree,AST)。你知道的,就是 Python 用來將你的腳本分解成片段的東西,然後它遍歷 import 語句和函式定義,以檢查是否所有東西都符合預期的 API 結構。因為 Langflow 想要確保程式碼與他們的代理系統良好配合。這聽起來很聰明,理論上是這樣。但這就是事情開始失控的地方。

Python 裝飾器的陷阱

在 Python 中,定義一個函式不僅僅是儲存函式。如果在該函式上有一個裝飾器(decorator),你知道的,就是 def 上面的那一行,它會在定義期間立即執行。所以,一個惡意的駭客可以寫一些類似的東西,而 Langflow,在其驗證程式碼的崇高使命中,會評估該函式定義,然後就完了。裝飾器執行,payload 傳送,駭客進入系統。

  • 甚至不需要呼叫該函式。

這就是 Horizon 3.ai 發現漏洞的方式。他們上傳了一個帶有惡意裝飾器的腳本,獲得了遠端程式碼執行(Remote Code Execution,RCE),並在後端彈出了一個 shell。更糟糕的是,他們發現雖然容器顯示使用者不是 root,但群組 ID 是 root。而且,是的,這仍然非常非常糟糕。群組層級的存取權限仍然足以搞亂像是 /etc/、共享記憶體、日誌、進程等各種有趣的東西。

漏洞在野外:一個警示故事

這不是一些理論上的、我們本可以做到的攻擊。它真的發生了。像是 CISA 發布了一個警報。真正的駭客正在利用這個漏洞。Langflow 確實在 1.0.0 版本中修補了它,功勞歸功於他們。但老實說,這個修復只是他們最終沙盒化了程式碼,並確保它在驗證期間不執行裝飾器。

  • 這再次是他們從一開始就應該做的事情。

如果你曾經建立過任何使用者可以提交程式碼的系統,即使是 CTF、程式碼裁判、playground 等,你都知道第一個規則是永遠不要直接執行不受信任的程式碼,不要在你的機器上,甚至不要在你表弟的 Raspberry Pi 上。你隔離它,Docker 化它,監禁它,用火燒它。

AI 的問題:缺乏理解

最瘋狂的部分?只要看看 Langflow 的驗證程式碼,像是實際的格式化、奇怪的註解間距、塊狀縮排。它看起來像是 AI 生成的。這就是我說 AI 不是問題所在的意思。

  • 但將 AI 應用於所有事情,而不理解它在做什麼,絕對是問題。

你不能讓 AI 編寫一半的後端程式碼,然後在它忘記安全 101 時感到震驚,比如「不要直接在 production 環境上執行陌生程式碼」。那甚至不是安全 101,那是常識。想像一下,我正在進行手術,但整個手術由一個 AI 助理領導,它說「將手術刀插入眼窩」。如果我盲目地遵循它,因為模型最懂,那不是 AI 的錯,而是我沒有檢查計算就信任它的錯。這就是這裡發生的事情。

AI 正被視為某種不需要監督的神奇預言機。這是一個問題。

結論與警告

那麼,這裡的教訓是什麼?如果你正在構建一個 AI 工具,很好,去做吧。這很酷。但是,請為了 root 存取的緣故,確保有一個人真正理解幕後發生了什麼。你無法透過自動化來擺脫責任。如果你是一個觀看此影片的駭客,請始終始終檢查 AI 工具如何處理程式碼輸入。因為 90% 的新創公司都在衝刺 MVP,並跳過了保護其端點的部分。

  • 如果你知道如何在 AST 解析期間觸發 Python 特性,比如裝飾器,你已經領先兩步了。

總之,去修補你的東西。去構建酷炫的東西,如果你好奇,去看看 Langflow 1.0.0 版本。但是,嗯,也許不要上傳任何裝飾器,好嗎?

Was this summary helpful?

Quick Actions

Watch on YouTube

Related Summaries

No related summaries found.

Summarize a New YouTube Video

Enter a YouTube video URL below to get a quick summary and key takeaways.