為什麼程式碼重用仍然是一個安全噩夢

現代軟體應用程式是由數以千計的從公共資源庫中獲取的第三方元件拼接而成的。這種程式碼的重用對軟體行業有很大的好處，它減少了開發時間和成本，使開發人員能夠更快地增加功能，但由於複雜的依賴關係系統往往難以跟蹤，它也產生了重大的漏洞管理問題。

繼承自第三方程式碼的漏洞多年來一直困擾著應用程式，但在政府贊助的軟體供應鏈攻擊時代，這個問題比以往任何時候都更有意義。軟體組合分析工具可以幫助發現其中的一些風險，但微妙的依賴性盲點仍然存在，即使是有安全意識的開發人員也很難抓住所有繼承的缺陷。

來自ReversingLabs的安全研究人員最近對NuGet倉庫進行了掃描，發現有5萬個軟體包正在使用一個名為zlib的流行庫的過時和脆弱版本。他們中的許多人沒有明確地把它列為依賴關係。

依賴性跟蹤是一針見血的

為了發現所有的漏洞，開發人員不僅需要跟蹤他們在自己的應用程式中使用的元件，還需要跟蹤這些元件所基於的第三方庫和包。依賴關係鏈可以深入很多層。達姆施塔特大學的研究人員在2019年對npm資源庫進行的分析發現，平均來說，匯入一個JavaScript包會對39個不同維護者的79個其他包引入隱性信任。當時，研究人員還發現，近40%的軟體包依賴的程式碼至少有一個公開的漏洞。

一個問題是，只有與同一儲存庫上的軟體包有關的依賴關係才會被軟體包儲存庫及其相應的軟體包管理工具所追蹤。但這並不是第三方程式碼進入專案的唯一途徑。一些開發者靜態連結庫或手動編譯來自其他專案的程式碼，這些程式碼存在於軟體包庫之外，這些資訊不容易用自動掃描工具找到。

ReversingLabs發現超過50個NuGet軟體包包含主動利用的漏洞，因為它們捆綁了過時的和脆弱的7Zip、WinSCP和PuTTYgen版本。這些都是流行的壓縮或網路連線程式，它們不直接託管在NuGet上，但可能有其他開發者在NuGet上為它們建立的包裝包。

NuGet是.NET程式語言的主要倉庫，那裡託管的大多陣列件都是以ZIP檔案的形式傳送，副檔名為.nupkg，包含預編譯的Windows .DLL庫，旨在匯入其他軟體專案中。

ReversingLabs發現的一個易受攻擊的NuGet包名為WinSCPHelper，是WinSCP的一個封裝庫。它允許整合它的應用程式透過SFTP協議管理遠端伺服器上的檔案。WinSCPHelper自2017年以來沒有在NuGet上更新過，但最後一個版本自發布以來被下載了超過34000次，在過去6周內被下載了約700次。最新的WinSCP版本是5.17.10，包含一個關鍵的遠端程式碼執行漏洞的補丁，但與WinSCPHelper捆綁的版本是一個更老的版本--5.11.2。

"雖然在這種情況下，被分析的軟體包明確指出它使用了WinSCP，但它沒有在依賴列表中披露版本，你不能輕易發現哪些漏洞影響了它的基礎依賴，"研究人員說。"這是手工作業，仍然可以做到，但需要一些努力"。

識別無聲的漏洞

但追蹤依賴關係可能比這更難。以zlib為例，它是最廣泛使用的開源資料壓縮庫之一，最初寫於1995年。這個庫幾乎已經成為事實上的標準，並由其維護者作為原始碼提供。這意味著開發人員傾向於自己編譯它，並在他們的專案中靜態地連結它，由於它是如此無處不在，所以常常不提它的存在。

透過靜態檔案分析，ReversingLabs發現超過5萬個NuGet軟體包使用zlib 1.2.8版本，該版本釋出於2013年，包含四個高度或嚴重的漏洞。一些被識別的軟體包透過其他沒有明確列出依賴關係的第三方元件繼承了這個舊的zlib版本和它的漏洞，促使研究人員把這些稱為沉默的漏洞。

ReversingLabs提供的一個例子是一個名為DicomObjects的NuGet包，它實現了醫學中的數字成像和通訊(DICOM)協議。DICOM是一個用於傳輸和管理醫學成像資料的標準。它在醫院中被廣泛使用，並被許多成像裝置支援，如醫療掃描器、印表機、伺服器和工作站。

DicomObjects被醫療軟體開發者用來輕鬆構建DICOM解決方案，它有近54000次下載，由一家名為Medical Connections的英國公司維護。該軟體包將Microsoft.AspNet.WebApi.Client、Newtonsoft.Json和System.Net.Http列為依賴項，但據ReversingLabs稱，它還捆綁了一個名為ceTe.DynamicPDF.Viewer.40.x86.dll的商業PDF庫，但沒有明確提及。DynamicPDF Viewer在NuGet上被列為一個單獨的軟體包，但DicomObjects中捆綁的版本是一個更老的版本，包括zlib 1.2.8。

"這是最常見的軟體維護問題之一，"研究人員說。"開發者建立了一個軟體包，決定使用第三方軟體，但在隨後的更新過程中，依賴性被忽略了。在這種情況下，事情就更糟糕了，因為任何地方都沒有明確提到DicomObjects軟體包依賴於DynamicPDF.Viewer。我們沒有辦法知道DynamicPDF.Viewer依賴於有漏洞的zlib庫。以這種方式堆疊隱藏的依賴關係會導致多層次的無聲漏洞，並使軟體維護和審計的難度大大增加"。

Medical Connections沒有立即回應評論請求。

另一個例子是一個叫做librdkafka.redist的高度流行的軟體包，這是一個實現Apache Kafka協議的C庫。Apache Kafka是一個開源的高效能流處理框架，用於處理實時資料傳輸。librdkafka.redist包有1890萬次下載，其中312000次是2個月前釋出的最新版本1.7.0。這個版本的librdkafka.redist使用zlib 1.2.8，但在NuGet或GitHub的專案依賴列表中沒有明確說明。

這個問題在一年多以前就被報告在GitHub上的專案bug追蹤器上，目前被標記為要在1.8.0版本中修復。該專案首席開發者Magnus Edenhill審查了這四個zlib漏洞，並表示其中只有兩個適用於librdkafka，透過Kafka消耗的訊息成功利用這些漏洞的風險似乎非常低。Edenhill沒有立即回應評論請求。

其他13個NuGet軟體包依賴於librdkafka.redist，包括一些由一家名為Confluent的資料基礎設施公司開發的軟體包，該公司擁有許多大型企業客戶。

"安全軟體開發是一個複雜的問題，因為它涉及到開發的多個階段的許多參與者，"ReversingLabs的研究人員說。"無論你的公司生產什麼型別的軟體，遲早都需要將第三方的依賴關係納入你的解決方案。這將引入管理安全和程式碼質量風險的需要。軟體供應鏈攻擊對網路社群的威脅越來越大。它們是傳統漏洞的DDoS類似物"。

供應鏈風險

NuGet並不是唯一存在這種脆弱依賴問題的軟體包庫，人們可以說，不是由NuGet或其他庫來迫使開發者更關注這些問題。然而，有些平臺比其他平臺更積極主動。GitHub積極掃描其平臺上託管的公共程式碼庫，分析它們的依賴關係，如果這些依賴關係中有任何已知的漏洞，就通知其所有者。該公司維護一個公共諮詢資料庫，其中包括npm(JavaScript)、RubyGems(Ruby)、NuGet(.NET)、pip(Python)、Maven(Java)的已知漏洞，並剛剛宣佈支援Go模組。

開源治理公司Sonatype在其《2020年軟體供應鏈報告》中指出，下一代攻擊的數量同比增長了430%，駭客試圖主動向開源軟體專案注入惡意軟體，試圖毒害其依賴鏈上的更多專案和應用程式。駭客利用開源元件中的已知漏洞的傳統攻擊仍然強勁，但利用的時間已經減少，攻擊者在公開披露的幾天內就利用了新發現的漏洞。同時，有一半的公司需要一週以上的時間來了解這些漏洞，並在一週或更長時間後將緩解措施落實到位。

攻擊者顯然對利用軟體供應鏈很感興趣，但成千上萬的具有繼承性漏洞的軟體包仍在公共資源庫中，並作為企業軟體的基礎模組。