據(jù)Cyber Security News消息，因?yàn)镻ython 包安裝過程方面的嚴(yán)重失誤，Amazon Web Services （AWS） 在過去四年中通過其 Neuron SDK 三次引入了相同的遠(yuǎn)程代碼執(zhí)行 （RCE） 漏洞。

該問題于 2022 年 4 月首次被發(fā)現(xiàn)，當(dāng)時(shí) Giraffe Security 標(biāo)記了 AWS 的 Neuron SDK 中的一個(gè)漏洞，該開發(fā)工具包是一組 Python 庫，可在 AWS 的專用硬件上啟用機(jī)器學(xué)習(xí)工作負(fù)載。

該問題源于 AWS 的官方安裝說明和文檔，其中建議使用如下命令：

pip install transformers-neuronx --extra-index-url=https://pip.repos.neuron.amazonaws.com

乍一看，該命令似乎很簡單，指示 Python 的軟件包管理器從特定于 AWS 的存儲(chǔ)庫 （） 安裝軟件包。但是，這種方法包含根植于如何處理參數(shù)的隱藏危險(xiǎn)。

piptransformers-neuronxhttps://pip.repos.neuron.amazonaws.compip

該參數(shù)并不專門將包下載限制為指定的私有存儲(chǔ)庫，相反，它允許在默認(rèn)的公共 PyPi 存儲(chǔ)庫中搜索包，如果在指定索引中找不到包，執(zhí)行退回操作。這會(huì)產(chǎn)生一個(gè)嚴(yán)重漏洞：攻擊者可以將同名的包上傳到 PyPi，誘騙用戶下載和執(zhí)行惡意代碼。

2022年， Giraffe Security 通過在 PyPi 上聲明未受保護(hù)的 AWS 軟件包名稱（如 mx-neuron）確認(rèn)了這一漏洞，并通過 AWS 的漏洞賞金計(jì)劃報(bào)告了這一漏洞。AWS 迅速解決了這個(gè)問題做出反應(yīng)，將受影響軟件包的 "假 "版本上傳到 PyPi，防止了進(jìn)一步的利用。 然而，問題的根源——對 --extra-index-url 參數(shù)的錯(cuò)誤依賴仍未得到解決。

2022 年的進(jìn)一步研究顯示，這并非此類漏洞的首次出現(xiàn)。 來自開源軟件數(shù)據(jù)庫 libraries.io 的歷史數(shù)據(jù)顯示，AWS 的 torch-neuron 軟件包在 2020 年也曾暴露過類似的漏洞，這表明也曾出現(xiàn)過同樣的依賴關(guān)系混亂風(fēng)險(xiǎn)。當(dāng)時(shí)，一名安全研究人員將該程序包的多個(gè)版本上傳到 PyPi 以突出顯示該漏洞，迫使 AWS 采取糾正措施。

盡已多次發(fā)出警告并進(jìn)行了修復(fù)，但 Giraffe Security 在 2024 年 12 月進(jìn)行的最新調(diào)查顯示，AWS 再次引入了相同的漏洞。

Amazon 一再的失誤引發(fā)了人們的質(zhì)疑。一方面，Amazon 對過去漏洞報(bào)告的快速反應(yīng)表明確實(shí)有認(rèn)真對待漏洞，但同樣的漏洞反復(fù)出現(xiàn)，說明缺乏系統(tǒng)性的防范流程。這種情況凸顯了一個(gè)重要的安全教訓(xùn)：即使是像 AWS 官方文檔這樣的可信來源也不一定安全。

雖然這個(gè)反復(fù)出現(xiàn)的問題看似是一個(gè)小眾漏洞，但它對云生態(tài)系統(tǒng)的安全具有更廣泛的影響。依賴關(guān)系混亂攻擊已成為一個(gè)日益令人擔(dān)憂的問題，尤其是當(dāng)越來越多的組織依賴于私有軟件包注冊中心和 PyPi 或 npm 等公共軟件源的情況下。 降低這些風(fēng)險(xiǎn)的責(zé)任不僅在于最終用戶，也在于 AWS 等服務(wù)提供商，他們必須確保其工具和文檔遵循安全最佳實(shí)踐。

盡管 Giraffe Security 曾多次嘗試聯(lián)系亞馬遜以征求意見，但一直沒有得到回應(yīng)。 作為全球最大的云服務(wù)提供商之一，AWS 在這一事件中未拿出強(qiáng)有力永久性解決方案的情況頗令人意外。