|
作者：Shawn Prestridge，IAR資深現場應用工程師 / 美國FAE團隊負責人 安全一直都是一個非常熱門的話題，似乎每周都會聽到這樣的消息：某某公司如何被入侵，數百萬用戶的數據被泄露。 我們看到這么多的安全問題，部分原因在于我們對待安全的方式：安全性通常被認為是事后考慮的問題，是在開發結束時才添加到設備上的東西。然而，復雜的系統，尤其是嵌入式系統，有一個很大的攻擊面，這讓攻擊者有機可乘，能夠在“盔甲”上找到破綻。如果你去研究大部分黑客試圖入侵系統的方式，你很快就會發現，在他們的武器庫中，他們最喜歡的手段就是尋找和利用設備的軟件漏洞。 如果軟件漏洞是黑客所利用的入口，那么我們就需要提高自己的代碼質量來解決這個問題。但是，這個問題有多嚴重，我們能做什么來解決它呢？ 代碼漏洞容易成為黑客的目標 代碼質量糟糕實際上是一個普遍存在的問題，而且有相當多的證據支持這樣的說法：糟糕的編碼直接導致了漏洞。雖然許多軟件工程專家多年來一直在宣揚這一點，但人們第一次真正意識到這一點也許是在2001年，當時紅色代碼（Code Red）蠕蟲對微軟的互聯網信息服務（IIS）施加了緩沖區溢出攻擊。[1]雖然第一個有記載的緩沖區溢出攻擊發生在1988年，針對的是Unix的finger指令，但對普通人的影響十分有限，因此沒有上頭條新聞。 由于紅色代碼造成了大規模的互聯網減速，并在新聞報道中鋪天蓋地的傳播，突然間，我們隨處都能看到緩沖區溢出攻擊的增加，看上去安全研究人員和黑客都在各種系統（包括嵌入式系統）中到處尋找這些漏洞。利用緩沖區溢出攻擊，黑客可以在受影響的系統上運行他們想要運行的任何代碼，其目標是使用固定長度的緩沖區來保存文本或數據的一切代碼。黑客將緩沖區空間填充到最大，然后在合法緩沖區空間的末端寫下可執行代碼。然后，被攻擊的系統就會執行緩沖區末端的代碼，在許多情況下，這就可以使攻擊者為所欲為了。[2] 這種類型的攻擊之所以成為緊急事件，是因為當時檢查和執行緩沖區限制的編碼并不普遍，但現在許多編碼標準，如mitre.org的通用缺陷列表（Common Weakness Enumeration，CWE），都建議檢查緩沖區是否存在這種類型的漏洞。[3]遺憾的是，開發人員在編寫代碼時普遍都不去尋找這個問題，通常需要代碼分析工具來發現這些問題，這樣開發人員才會意識到問題的存在并加以修復。像這樣一個簡單的代碼質量改進，就可以消除黑客最常使用的手段之一，從而大大提高代碼的安全性。因此，檢查并執行代碼中的緩沖區長度，這樣的編碼才是好編碼。 不僅僅是緩沖區溢出 然而，問題不僅僅在于緩沖區溢出，這實際上是一個系統性問題，草率的編碼通常會導致無數的安全漏洞，而黑客可以利用這些漏洞來入侵系統。美國軟件工程學會（SEI）發表的一篇論文將這一點說得非常清楚： “......質量性能指標為確定高質量產品、預測安全和保障結果提供了依據。通用缺陷列表（CWE）中的許多內容，如編程語言結構的不當使用、緩沖區溢出、驗證輸入值失敗等，都可能與低質量的編碼和開發過程有關。提高代碼質量是解決一些軟件安全問題的必要條件。”[4] 該論文還指出，因為許多安全問題是由軟件漏洞引起的，因此可以像處理更普通的編碼漏洞一樣處理安全問題，您可以應用傳統的質量保證技術來幫助解決至少一部分安全問題。 既然正常的軟件質量保證過程可以讓我們估計系統中剩余的漏洞數量，那么可以對安全漏洞做同樣的事情嗎？雖然SEI沒有確認代碼質量和安全性之間的數學關系，但他們確實指出，1%到5%的軟件漏洞是安全漏洞，并繼續指出，他們的證據表明當安全漏洞被追蹤時，他們可以準確地估計系統中的代碼質量水平。[4]這最終表明，代碼質量是安全的必要條件（但不是充分條件），真正讓“安全性可以被視為開發結束時才添加到設備上的東西”這一概念不攻自破。相反，安全性必須貫穿項目的DNA，從設計到編碼，一直到生產。 編碼標準可提供很大的幫助 許多最常見的安全漏洞都在諸如mitre.org的通用缺陷列表等編碼標準中得到了解決，并指出了需要關注的其他方面，如除零錯誤、數據注入、循環不規則、空指針利用和字符串解析錯誤。MISRA C和MISRA C++還提倡編碼的安全性和可靠性，以防止安全漏洞滲入你的代碼。雖然這些編碼標準可以捕捉到許多常見的漏洞，但開發人員在編寫代碼時必須考慮得更長遠：黑客是如何利用我剛剛編寫的代碼的？漏洞在哪里？我是否對輸入會是什么樣子以及輸出會如何使用做了假設？一個好的經驗法則是，如果你在做假設，那么這些假設應該變成代碼，以確保你所期待的東西實際上就是你所要得到的。如果你不這樣做，那么黑客就會出手了。 但是開源軟件呢？在設計中使用開源組件的典型論點依賴于“已在使用中被證明”（proven in use）的論點：這么多人使用它，它一定是好的。SEI的同一篇論文對于這個問題也有一些闡述： “除了免費之外，開源所宣揚的好處之一，就是認為‘有很多人關注源代碼意味著安全問題可以很快被發現，任何人都可以修復漏洞，不需要依賴供應商’。然而，現實情況是，如果沒能有紀律地、一致地把關注點放在消除漏洞上，安全漏洞和其他漏洞將出現在代碼中。”[4] 換句話說，SEI認為，“已在使用中被證明”的論點毫無意義，并且在將質量保證應用于開源代碼時，會讓人想起Anybody、Somebody、Nobody和Everybody的故事。此外，你的測試并不足以證明代碼是令人滿意的。SEI表示，像CWE這樣的代碼質量標準可以發現你代碼中的問題，而這些問題往往不會在標準測試中被發現，通常只有在黑客利用漏洞時才會被發現。[4]為了證明這一點，2020年5月，普渡大學的研究人員展示了在Linux、macOS、Windows和FreeBSD中使用的開源USB堆棧的26個漏洞。[5]所以，談及安全性時，代碼質量是關鍵，并且所有代碼都很重要。 代碼分析工具有助于遵守標準 在解決代碼質量問題上，我們可以做些什么來提高自己應用程序的安全性呢？簡單的答案就是使用代碼分析工具，這些工具有兩種基本類型：靜態分析工具和運行時（或動態）分析工具，靜態分析只查看應用程序的源代碼，而運行時分析則是對代碼進行檢測，尋找空指針和數據注入方法等漏洞。IAR可以同時提供這兩種工具，包括靜態分析工具IAR C-STAT和運行時分析工具IAR C-RUN，它們都完全集成在IAR Embedded Workbench開發環境中。高質量的代碼分析工具包括對CWE、MISRA和CERT C的檢查。CERT C是另外一種編碼標準，旨在促進編碼安全。這三個規則集共同構成了一個優質組合，有助于實現可提升安全性的編碼：一些規則集與其他規則集有重合之處，但也提供了一些獨特的功能，可以幫助確保你的代碼具有高度的安全性。使用這些標準也有助于確保你擁有最高的代碼質量，甚至可能發現代碼中的一些潛在漏洞。 高質量的代碼就是安全的代碼 保證代碼質量才能確保代碼安全。不要把代碼質量的責任推給別人，因為別人的漏洞很可能給你帶來安全性方面的噩夢。但希望還是有的，因為代碼分析工具可以幫助你在漏洞找麻煩之前迅速發現問題。通往安全的道路總是要經過代碼質量這一關口。 參考資料 [1] https://www.caida.org/research/security/code-red/ [2] https://malware.wikia.org/wiki/Buffer_overflow [3] https://cwe.mitre.org/data/definitions/121.html [4] https://resources.sei.cmu.edu/as ... _004_001_428597.pdf [5] https://www.techradar.com/news/u ... especially-on-linux |
