高 慶 陳 靜 許 平 張世琨

1(北京大學軟件工程國家工程研究中心 北京 100871)2(北京北大軟件工程股份有限公司 北京 100080)3(中國電子科技集團公司第三十研究所 成都 610041)

近年來，隨著計算機技術的發(fā)展，嵌入式系統(tǒng)在航空航天、核能、交通等安全攸關領域的應用越來越廣泛.特別是隨著工業(yè)互聯網的發(fā)展，工業(yè)嵌入式軟件呈井噴式的發(fā)展.由于軟件功能的日益強大，軟件正在逐步取代部分硬件的功能，嵌入式軟件的規(guī)模及復雜程度急劇增加，在安全關鍵的航空航天、汽車以及工業(yè)控制等領域的用戶對嵌入式軟件質量要求更加嚴格，使用過程中對嵌入式軟件缺陷的容忍度越來越低[1].

隨著工業(yè)化和信息化的深度融合，針對工業(yè)互聯網的安全事件頻發(fā)，越來越多的攻擊者把攻擊目標鎖定在國家關鍵工業(yè)基礎設施上.從2000年開始，針對工業(yè)控制系統(tǒng)的惡意攻擊事件越發(fā)頻繁，工業(yè)控制軟件一旦出現缺陷，將導致不可估量的災難.例如：1997年9月美國艦船由于軟件非法計算導致推進系統(tǒng)運轉失敗；2004年，F22戰(zhàn)斗機試飛時FCS軟件缺陷導致墜機；2006年，火星全球探勘者號的內存地址錯誤導致衛(wèi)星失聯；2016年7月美國西南航空調度系統(tǒng)由于軟件緩沖區(qū)溢出導致系統(tǒng)崩潰，影響了7 000次航班的飛行；2019年3月，委內瑞拉南部玻利瓦爾州的一座主要水電站發(fā)生故障，導致大規(guī)模停電事件，影響18個州.近年來自動駕駛汽車的故障也造成很多交通事故[2].

工業(yè)嵌入式軟件運行時間久、強度大，對安全性、可靠性以及資源的節(jié)省方面都有更多的要求，對工業(yè)嵌入式系統(tǒng)的安全性分析提出了新的挑戰(zhàn)[3].許多嵌入式軟件開發(fā)人員認為，嵌入式系統(tǒng)的安全性應該在系統(tǒng)級別上處理，或者由嵌入式硬件來處理，這種防御是不夠的，嵌入式系統(tǒng)的開發(fā)者需要通過處理嵌入式軟件中的漏洞來建立第3道防線.

1 嵌入式軟件的安全特點

嵌入式系統(tǒng)通常由硬件層、驅動層和軟件層組成[4].嵌入式軟件大體上可分為3類：嵌入式操作系統(tǒng)、嵌入式支撐軟件和嵌入式應用軟件.嵌入式操作系統(tǒng)主要用于控制、管理系統(tǒng)資源的軟件，如Windows CE，Palm OS，Linux，VxWorks，pSoS，QNX，OS-9，LynxOS等；支撐軟件是指用于輔助軟件開發(fā)的軟件工具集、交叉開發(fā)工具、軟件測試工具等；應用軟件是嵌入式軟件中面向用戶體驗的軟件，一般針對特定應用領域、完成一定功能，達到用戶的預期目的.嵌入式應用軟件種類最多，它不僅要求準確性、安全性、穩(wěn)定性等方面能夠滿足實際應用的要求，而且還要盡可能地進行優(yōu)化，以減少對系統(tǒng)資源的消耗，降低硬件成本[2].

嵌入式軟件的專用性很強，為滿足特定的領域需求，要求功能精簡，這樣有利于控制成本，并且可以更好地保證安全.多數嵌入式軟件固化在芯片或單片機上，提供的內核資源相對有限，所以要求嵌入式軟件保持效率高、冗余小、功率均衡，不完善的嵌入式軟件很容易出現內存問題，導致運行時出現非預期的狀況.

嵌入式軟件具有高實時性的特點.一方面對嵌入式軟件的質量、可靠性和安全性有很高的要求，因為一旦軟件固化后就很難發(fā)現、調試和修改軟件中的缺陷，比如由于緩沖區(qū)溢出等代碼缺陷帶來的安全隱患將更加難以修復[5]；另一方面也對嵌入式軟件運行時的實時性有比較嚴格的要求，對軟件使用的場景、時間、體積、功耗有嚴格要求.如果嵌入式軟件實時性差，會導致嚴重后果，如核電站控制、航天器入軌、飛行控制、航空發(fā)動機控制等，均要求時間比較精準[1].

工業(yè)互聯網軟件除了面向產品生產的研發(fā)軟件、管理軟件等，很大一部分是自動化控制軟件或者面向裝置級的嵌入式軟件[6]，即工業(yè)嵌入式軟件.工業(yè)控制的設備、協議、嵌入式軟件和系統(tǒng)在互聯網上暴露問題是工業(yè)互聯網安全的一個基本問題，直接面臨互聯網上的各類攻擊.對于工業(yè)嵌入式軟件而言，最大的風險來自安全漏洞，包括開發(fā)過程中編碼不符合安全規(guī)范而導致的軟件本身的漏洞，以及由于大量使用不安全的第三方組件而出現的安全漏洞[7]，第三方組件的安全性和可控性問題日漸突出，一旦出現漏洞就會影響大量的工業(yè)產品[8]，直接關系工業(yè)生產的成敗.

2 嵌入式軟件編碼標準對比

C語言是嵌入式軟件開發(fā)最常用的一種語言[9]，C語言運行效率非常高并且可以方便訪問硬件.然而，C語言在不同的編譯器編譯時會出現不同的結果，從而導致不可預期的問題，這是一個極大的隱患.隨著工業(yè)嵌入式軟件程序的日益復雜，軟件的代碼行數越來越多，如：NASA航天飛機的機載系統(tǒng)有近50萬行代碼，地面控制和處理也有35萬行代碼；一般的車輛控制系統(tǒng)有數百萬行代碼甚至上億行代碼.除了C語言，C++語言也越來越多地用于嵌入式軟件開發(fā)中，如美國的F-35戰(zhàn)斗機的控制系統(tǒng)就是采用C++語言編碼，其機載和地面的嵌入式系統(tǒng)代碼高達1 500萬行.隨著工業(yè)嵌入式軟件代碼規(guī)模越來越大，越來越多的嵌入式關鍵系統(tǒng)已經成為軟件密集型系統(tǒng)[3].保證工業(yè)嵌入式軟件代碼安全成為越來越嚴峻的問題.

2.1 嵌入式軟件編碼標準發(fā)展歷史

為了保證嵌入式軟件代碼的安全性、可靠性和可維護性，嵌入式軟件的編碼標準也越來越重要[2].國際上已經制定了面向多個工業(yè)行業(yè)的安全標準，在《IEC 6150電氣/電子/可編程電子安全系統(tǒng)的功能安全標準》《ISO 26262道路車輛功能安全標準》《CENELEC EN 50128鐵路應用-通信，信號和處理系統(tǒng)-軟件鐵路控制和保護系統(tǒng)標準》《RTCA DO-178B/C機載軟件適航標準》中都提出要通過嵌入式開發(fā)語言的編碼標準，來驗證嵌入式軟件安全性的原則.在嵌入式軟件開發(fā)過程中，軟件開發(fā)人員嚴格按照安全編碼標準進行編碼實施，可以在編碼階段預防安全缺陷的產生[10]，并且可以提升安全缺陷的修復效率，在軟件開發(fā)過程的源頭減少安全缺陷，這是避免嵌入式系統(tǒng)在實際應用環(huán)境下被攻擊的有效方法之一.隨著工業(yè)軟件的發(fā)展，嵌入式軟件安全編碼標準也在不斷的發(fā)展，其發(fā)展過程如圖1所示:

目前在工業(yè)嵌入式軟件開發(fā)中使用比較廣泛的安全編碼標準是MISRA C和MISRA C++[10]，其主要來源于福特和羅孚汽車公司的C開發(fā)標準，以及美國的聯合攻擊機、英國國防部的C++編碼標準.MISRA 中的規(guī)則條目通過不斷的更新和更正，成為了最新的MISRA C：2012以及MISRA C++：2008.為了補充嵌入式軟件安全編碼標準中風格類的編碼規(guī)則，美國BARR組織推出了BARR C標準用于補充MISRA C：2012標準[12].2020年在德國召開的Embedded World會議上，BARR C：2018和MISRA C：2012協同作用的主題中提到BARR嵌入式C編碼標準可以幫助嵌入式軟件開發(fā)人員在進行調試時，去除嵌入式軟件的代碼錯誤，提升其可維護性和可移植性，幫助企業(yè)和個人開發(fā)出高可靠性的嵌入式軟件[12]，從而進一步提升軟件的安全性.近年來，隨著汽車工業(yè)的發(fā)展，汽車嵌入式軟件需求越來越多，汽車電子標準組織AUTOSAR開發(fā)聯盟提出了AUTOSAR C++編碼標準，這套標準的規(guī)則主要來源于MISRA C++：2018以及HICPP規(guī)范.MISRA C/C++工作組成員Rozenau在2019年曾提出MISRA C++標準和AUTOSAR C++標準的檢測規(guī)則密不可分，并計劃將AUTOSAR C++與MISRA C++相互補充[13].AUTOSAR C++的出現極大推動了工業(yè)嵌入式軟件安全編碼標準的發(fā)展.

AUTOSAR C++還借鑒了CERT C和CERT C++安全編碼標準，CERT是由軟件工程研究所(SEI)為嵌入式開發(fā)人員創(chuàng)建的.專家從CERT C中提取出一套適用于靜態(tài)分析技術的規(guī)則集，成為ISO/IEC TS 17961《C安全編碼規(guī)則》.標準中提出45條適用于工業(yè)嵌入式軟件的編碼標準，一旦違背這些標準，會導致系統(tǒng)崩潰等問題[14].CERT C和CERT C++安全編碼標準都收錄于CWETM(Common Weakness Enumeration)表中.CWE表是由美國國家安全局首先倡議的戰(zhàn)略行動，其中收錄了大部分已發(fā)現的軟硬件安全漏洞.在每年最嚴重的CWE TOP 25中至少有10個都是嵌入式軟件開發(fā)相關的安全漏洞，這些條目長年被排在CWE TOP 25中，需要相關人員在嵌入式軟件開發(fā)中高度重視并且提早解決.CWE TOP 25中的嵌入式軟件開發(fā)安全漏洞如表1所示：

表1 CWE TOP 25中的嵌入式軟件開發(fā)安全漏洞

隨著國內嵌入式軟件的發(fā)展，國內推出了工業(yè)嵌入式軟件標準GB/T 28169—2011《嵌入式軟件C語言編碼規(guī)范》，但是目前應用不是很廣泛.GB/T 28169 C—2011中包含一些針對嵌入式軟件特定的規(guī)則，如中斷、寄存器缺陷、硬件系統(tǒng)初始化等.

2.2 安全編碼標準對比

針對MISRA C++：2008、MISRA C：2012、BARR C：2018、AUTOSAR C++、CERT C/C++、ISO/IE TS 17961 C、CWE表、GB/T 28169 C—2011這些目前比較常見的國內外嵌入式軟件安全編碼標準，從發(fā)起圖家和地區(qū)、發(fā)布時間及情況、發(fā)布組織、規(guī)則數目、適用領域以及規(guī)則集特點進行對比，如表2所示.

表2 嵌入式軟件安全編碼標準對比

這些常用的嵌入式軟件安全編碼標準之間，在具體規(guī)則項上也有一定的關聯和覆蓋，如圖2所示.

圖2 嵌入式軟件安全編碼標準關聯關系[12-16]

3 嵌入式軟件開發(fā)安全漏洞模式

本文基于對嵌入式軟件安全編碼標準的研究，進一步對標準之間的關聯關系進行詳細的分析、比較和去重，篩選和抽取出工業(yè)嵌入式軟件開發(fā)安全漏洞模式清單.漏洞模式共分為3大類，即嵌入式軟件特有安全漏洞模式、通用類嚴重缺陷模式和其他缺陷模式，每種大類下包含若干種缺陷模式小類.通過進一步分析缺陷模式中各種情況，參考國內外各套安全編碼標準的詳細內容抽取出若干具體的模式檢測規(guī)則.

3.1 嵌入式軟件特有安全漏洞模式

嵌入式特有模式主要與嵌入式軟件密切相關，例如硬件初始化、并發(fā)性、原子性、中斷等嵌入式特定情況相關的一些缺陷模式，這些缺陷模式主要來自于GB/T 28169—2011《嵌入式軟件C語言編碼規(guī)范》，是與嵌入式系統(tǒng)硬件相關或者是嵌入式軟件中特有的編程用法，在嵌入式軟件中出現這些缺陷后，會導致嵌入式系統(tǒng)崩潰等問題.這類模式包括8種缺陷模式小類、26種模式檢測規(guī)則，如表3所示：

表3 嵌入式軟件特有安全漏洞模式

這些模式檢測規(guī)則是規(guī)定編碼的詳細條目描述，針對每種模式具體的檢測規(guī)則舉例，如果使用靜態(tài)代碼分析技術對被測嵌入式軟件代碼進行檢測，就要首先對規(guī)則進行詳細說明，以及添加正確和錯誤例子代碼，建立完整的安全漏洞模式知識庫，如表3中，序號“1”中“寄存器缺陷”的漏洞模式規(guī)則舉例“中斷處理程序和主程序寄存器組沖突”，是指在中斷函數中調用其他函數，必須和中斷函數使用相同的寄存器組.這是因為主程序默認使用的寄存器為BANK0，如果中斷函數沒有通過using指定寄存器組或者指定了相同的寄存器組，則不會發(fā)生沖突；如果中斷函數通過using指定了不同的寄存器組，則被調用的函數需要放在#pragma NOAREGS和#pragma AREGS控制參數對中，該參數對的意義是使編譯器不要對該函數使用絕對寄存器尋址.當沒有用NOAREGS參數作明確的聲明，編譯器將絕對寄存器尋址方式訪問函數選定(即使用using或REGISTERBANK指定)的寄存器組，當函數假定的和實際所選的寄存器組不同時將產生不可預知的結果，從而可能出現參數傳遞錯誤，返回值可能會在錯誤的寄存器組中.

3.2 通用類嚴重缺陷模式

除了嵌入式特有的模式，還有一些安全漏洞模式在所有C/C++語言開發(fā)的軟件中都通用，并且在嵌入式軟件中錯誤使用會導致嚴重的問題，如導致嵌入式系統(tǒng)崩潰或者拒絕服務等嚴重后果.這類缺陷模式歸為通用類嚴重缺陷模式，這類缺陷模式在各個編碼標準中都可能出現，可以用于C/C++語言編寫的各類應用軟件代碼的檢測中.這類嚴重缺陷包括20種模式小類、89種模式檢測規(guī)則，如表4所示：

表4 通用類嚴重缺陷模式

通用類嚴重缺陷模式也要在安全漏洞模式庫中進行建立，如表4序號2中的“動態(tài)鏈接庫”的漏洞模式檢測規(guī)則“調用外部文件未使用完整路徑”，指的是在應用程序加載外部庫時，代碼應該使用完全限定的路徑，這一點很重要.如果指定了不完全限定的路徑，則惡意攻擊者就可以控制搜索路徑，并且將其用作遠程執(zhí)行任意代碼的載體，某些 API(例如 SearchPath)也提供可用于惡意攻擊的載體，它們會嘗試從非預期的源目錄中加載庫，這些類型的威脅稱為二進制植入或DLL預加載攻擊.比如直接使用相對路徑調用外部文件，寫成LoadLibrary(“external_library.dll”).這會導致相對路徑可能被惡意攻擊者利用以執(zhí)行任意代碼.應該改為在調用外部文件時使用完整路徑，寫成 LoadLibrary(“C:/libs/external_library.dll”).

表4中序號17中的“密碼權限”的漏洞模式檢測規(guī)則“明文存儲密碼”也是很常見的一種嚴重安全漏洞模式.2018年10月9日，美國政府問責局發(fā)布了題為“WEAPON SYSTEMS CYBERSECURITY-Just Beginning to Grapple with Scale of Vulnerabilities”的報告中提到美國國防部大部分正在開發(fā)的武器嵌入式系統(tǒng)中都存在安全漏洞，最多的安全漏洞就是密碼被非法獲取.當密碼以純文本格式存儲在應用程序的屬性或配置文件中時，任何可以讀取該文件的人都可以訪問受密碼保護的資源，極大地危及整個嵌入式系統(tǒng)的安全.應該避免將密碼存儲在易于訪問的位置，也不要使用純文本格式存儲任何敏感信息，并使用合適的加密方法對密碼進行加密.

能展示日常工作情況。競賽是崗位練兵活動中又一大內容，通過競賽的形式，模擬住宅火災救援、林地火情控制等等，在競賽時“濫竽充數”、“混水摸魚”是行不通的，日常的工作情況將真實的反映在考官的面前，或優(yōu)或劣的工作情況得到了有效展示，通過競賽形式，促使了員工立足崗位，苦練過硬本領、學技術，練絕活，干一流，爭第一，爭當崗位能手的自覺性。

3.3 其他缺陷模式

其他缺陷模式檢測規(guī)則有300多種，主要針對函數、變量、循環(huán)、跳轉等編碼風格、樣式規(guī)范性的一些要求，這一類缺陷模式也來源于各個編碼標準.如果在嵌入式軟件的編碼過程中出現其他類的缺陷模式，一般不會導致嚴重的后果，但是會讓代碼存在潛在隱患，并且導致嵌入式軟件的代碼不容易維護.如函數類的“有返回值的函數中return必須帶有返回值”這條規(guī)則在MISRA2012和CWE的編碼標準中都有提到.這條規(guī)則是指函數類型不是void，但是函數內的return并沒有返回值，那么返回值就未被賦值，這可能導致使用未初始化的內存.當返回值在其他地方被用到時，會導致未知的錯誤.

4 工業(yè)嵌入式軟件安全漏洞檢測技術

工業(yè)嵌入式軟件安全漏洞可以通過靜態(tài)分析和動態(tài)分析2類技術進行檢測.其中：動態(tài)分析結合程序運行行為進行檢測，一般不需要指定漏洞模式，只要程序運行時滿足某個條件(如程序崩潰)就可以發(fā)現安全漏洞；代碼靜態(tài)分析技術在不運行程序的情況下對代碼進行分析，通常以安全漏洞模式為輸入，可用于檢測嵌入式軟件中特定模式的安全漏洞.下面對靜態(tài)分析技術進行介紹.

代碼靜態(tài)分析技術越來越被認為是高級編程語言的高性能實現和驗證系統(tǒng)的基本工具[17].代碼靜態(tài)分析技術主要分為基于語法和基于路徑遍歷2類靜態(tài)分析技術，其中基于路徑遍歷的分析技術以語法分析為基礎，進一步分析程序中變量之間的控制流和數據流關系.接下來以2類嵌入式軟件漏洞模式為例，介紹對應的分析方法.

對于中斷規(guī)范這種規(guī)則類的漏洞模式，基于語法即可準確分析.根據用戶指定的中斷服務程序，對代碼進行詞法、語法分析，生成抽象語法樹，樹中的各個結點表示函數、語句、表達式、變量等不同類型的程序元素，邊表示各個程序元素之間的包含關系.然后，對抽象語法樹進行遍歷.對于函數定義類型和語句類型的樹結點，檢查定義中的返回類型聲明是否存在，或者語句是否為返回語句，若是即違反“中斷服務程序不應帶有返回值”的規(guī)范；對于函數調用類型的樹結點，若存在被調用函數名為printf，malloc的函數，即違反“不應在中斷服務程序中使用printf，malloc等函數”的規(guī)范.

對于其他大多數的漏洞模式，僅基于語法不能準確分析.例如，對于“可疑的空指針解引用”這種漏洞，必須同時具備以下4個要素：1)在程序中的某個語句Si定義了空指針；2)在程序另一個語句Sj存在該指針的解引用；3)存在Si到Sj的路徑且實際可達；4)在所有可達路徑中，不存在1條賦值語句，使該指針一定被賦值為非空值.可以看出，僅靠抽象語法樹上的信息不足以準確分析出以上信息，需要基于抽象語法樹進行關于程序路徑的進一步分析，稱為基于路徑遍歷的分析技術，主要包括值流分析[18]和符號執(zhí)行[19]2類.

對于值流分析，分為以下3個步驟：

步驟1.構建控制流圖、函數調用圖、指針分析圖等若干種基礎程序模型，描述函數內語句執(zhí)行順序、函數間調用、程序指針指向等關系.

步驟2.基于以上程序模型，構建值流圖或值依賴圖等綜合圖模型，表達變量之間的控制流及數據流依賴關系.其中，控制流表達程序語句之間執(zhí)行順序的依賴關系，數據流表達變量之間在定義-使用上的依賴關系.圖中的每個結點表示語句中的變量，邊表示變量之間的數據流關系，邊上標記數據流存在的條件，為約束表達式，描述了控制流關系.

步驟3.基于所分析的"可疑的空指針解引用"模式的4個要素，在綜合圖模型中進行定位和搜索，圖模型中的結點可對應到程序語句，有向邊對應到程序中的控制流和數據流傳遞關系.首先，對于每個指針P，在圖模型中檢查是否存在使其可能為空的賦值，并將對應結點記為N1；然后，進一步在綜合圖模型中計算從N1出發(fā)的所有路徑，所得路徑即為程序切片；繼而，檢查所得程序切片中的結點，是否存在對指針P的解引用，若存在則將該結點記為N2，并計算結點N1到達結點N2所需要滿足的約束表達式，因N1到N2之間可能存在多條路徑，這里對約束條件采用同一路徑取交、不同路徑取并的計算方法；最后，使用SMT約束求解技術，對前序步驟中所得的約束表達式進行求解，若結果為真，則判定存在對應漏洞，報告相應的路徑和可疑的空指針定義點及使用點.

對于其他嵌入式安全漏洞模式，分析技術相似.其中步驟1和步驟2的計算結果為共性的模型，在不同的模式之間可以復用；步驟3特定于每種漏洞模式，但通常都涉及到圖中關鍵結點識別、路徑計算、約束求解這3個子步驟.

符號執(zhí)行技術同樣可以檢測這些模式，類似于值流分析，需要構建控制流圖.與值流分析側重于通過數據流分析漏洞不同，符號執(zhí)行更側重從控制流的角度分析漏洞.其將變量用符號表示，按照程序的執(zhí)行過程，對程序進行模擬執(zhí)行，記錄每條語句執(zhí)行后程序中各個變量符號和約束表達式等程序狀態(tài)的變化.對于“可疑的空指針解引用”模式，當依次監(jiān)測到可疑空指針賦值和對該指針進行解引用的語句執(zhí)行后，對所記錄的約束表達式進行求解，即可發(fā)現是否存在一條可達的路徑，進而判斷是否存在該漏洞.

可以看出，值流分析和符號執(zhí)行都使用了約束求解的技術，該技術在大規(guī)模程序中會有約束表達式過于復雜導致無法求解的問題.此外，嵌入式程序本身的靜態(tài)分析模型構建過程也因為程序的復雜性，在跨函數、域敏感、上下文敏感等場景上，必須犧牲部分精度，以達到可接受的分析效率.因此，靜態(tài)分析的結果不能保證正確，其對漏洞檢測的誤報率、漏報率和檢測效率也是衡量不同檢測技術的關鍵指標.不同的技術路線都有其優(yōu)化方法[20-23]，并可持續(xù)改進，以期在滿足一定檢測效率的基礎上，盡可能降低誤報和漏報.

5 結 語

本文介紹了工業(yè)嵌入式軟件的安全特點，并對工業(yè)嵌入式軟件相關的最常用的C，C++的國內外安全編碼標準MISRA C，CERT C，GB/T 28169等進行說明，從各個標準的發(fā)展過程、標準特點以及各標準之間關聯覆蓋關系進行分析，進而提出一套適用于工業(yè)嵌入式軟件的安全漏洞模式清單，模式分為3大類，包括：嵌入式特有的安全漏洞模式、通用類嚴重缺陷模式以及規(guī)范性的其他缺陷模式.最后介紹了基于語法和基于路徑遍歷2類靜態(tài)分析技術對這些安全漏洞模式的代碼檢測實現，并針對一些工業(yè)嵌入式軟件開發(fā)安全漏洞模式的分析檢測實現進行詳細說明.通過使用靜態(tài)分析技術，對工業(yè)嵌入式軟件進行安全漏洞模式分析和檢測，在軟件開發(fā)過程的源頭發(fā)現編碼安全問題并得到及時解決，可以更好保證工業(yè)軟件的安全，進一步推動工業(yè)軟件的發(fā)展和工業(yè)互聯網的發(fā)展.