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