作者 | 愛吃小魚干

小編 | 吃不飽

01嵌入式軟件應用程序所面臨的日益增多的網(wǎng)絡威脅

嵌入式軟件應用面臨著越來越多的安全問題，在任何現(xiàn)代軟件開發(fā)環(huán)境中，考慮安全性都是非常重要的。即使經(jīng)過最好的審查和測試的軟件也可能存在BUG，而這些BUG可以讓惡意用戶進入系統(tǒng)并造成巨大的物理和財務損失。
其攻擊范圍涵蓋很多領域：從機場的調(diào)度系統(tǒng)到醫(yī)療設備都可能受到攻擊，特別值得關注的是日益增加的自動駕駛汽車或連接汽車、列車和飛機等計算機控制系統(tǒng)。任何與外界通信的系統(tǒng)都面臨著風險，例如汽車可能被盜，更糟糕的情況是車輛的控制權被奪取。

Q

那么，BUG是如何進入系統(tǒng)的呢？

C和C++語言存在未定義的行為和不確定的行為，這可能會導致問題，尤其是對于沒有經(jīng)驗的開發(fā)人員來說，他們可能不知道代碼實際上并沒有執(zhí)行他們預期的操作。此類錯誤可能會導致開發(fā)者錯誤地認為一切都很正常，因為以前使用過該代碼，所以不需要重新驗證。但實際上并非如此。代碼的優(yōu)化可能看起來是一件好事，占用更少的空間，但代碼優(yōu)化可能會刪除優(yōu)化器認為不必要但卻對安全至關重要的檢查，例如除以零和不可達代碼檢測。外部庫可能包含BUG，但是采用的代碼可能沒有經(jīng)過驗證。因此，在使用外部庫時，重要的是檢查公開BUG的已知數(shù)據(jù)庫，例如CV。而任何使用動態(tài)內(nèi)存的地方都可能導致問題，特別是像內(nèi)存泄漏之類的問題。

更多的安全漏洞是由于假設輸入數(shù)據(jù)格式正確且無需驗證，導致出現(xiàn)數(shù)據(jù)緩沖區(qū)溢出和使用未分配動態(tài)內(nèi)存（即所謂的“use after free”）等問題。盡管人們普遍認識到這些安全問題可能會出現(xiàn)，但它們并沒有得到足夠的關注和解決。原因可能有很多，但最主要的原因是之前沒有真正推動改變，增加新功能比花費時間檢查安全問題更為重要?？梢酝ㄟ^教育開發(fā)人員貫穿軟件開發(fā)生命周期考慮安全、改進流程和工具來提高檢測安全漏洞的信心，以及針對安全的測試，來改善這種情況。

02CERT C和C++如何檢測軟件安全問題
如今可能有實施軟件安全的愿望，那么如何實現(xiàn)呢？我們將看看嵌入式系統(tǒng)中使用的語言，以及如何使用C和C++來檢測這些語言引起的安全問題。歷史上，嵌入式系統(tǒng)是用匯編語言編寫的，但現(xiàn)在情況已經(jīng)改變，大多數(shù)關鍵系統(tǒng)都是用C或C++編寫的。C++正在變得越來越受歡迎，但當前C仍是首選語言。然而，這兩種語言都存在安全問題。

White Source知識庫顯示，在過去十年中發(fā)現(xiàn)的開源代碼安全漏洞中，47％是C，6％是C++。這可能會導致人們認為C本質(zhì)上比其他語言更容易受到攻擊，但事實并非如此。因為C語言編寫的代碼數(shù)量比任何其他語言都多，并且時間跨度較長，因此發(fā)現(xiàn)漏洞的機會更多。而在過去五年中發(fā)現(xiàn)了大量漏洞是好事情。高危漏洞的高比例（36％）在C++中被發(fā)現(xiàn)，然后是C（26％）。但需要注意的是，隨著C++變得越來越流行，也會有更多的機會在兩種語言中發(fā)現(xiàn)漏洞，因此需要適當評估這些數(shù)據(jù)。

在計算機安全中，最常見的漏洞是緩沖區(qū)溢出和輸入驗證。緩沖區(qū)溢出是一個非常嚴重的問題，可能會導致嚴重的后果。C和C++特別容易受到溢出攻擊的影響，因為它們將字符串定義為未終止的字符數(shù)組，沒有隱式進行邊界檢查，即使開發(fā)人員認為已經(jīng)進行了檢查，標準庫函數(shù)對字符串也不執(zhí)行任何邊界檢查。在某些函數(shù)（如向量、點、A-T）中，C++進行了一些改進，并通過默認進行了邊界檢查。漏洞代碼允許惡意用戶覆蓋內(nèi)存中的其他值，例如CPU必須執(zhí)行的指令，從而更改代碼的行為。

Q

關于緩沖區(qū)溢出

那就不得不提到兩個常見的函數(shù)：strcpy和gets。這兩個函數(shù)都存在潛在的安全風險。如果輸入字符串超過目標數(shù)組的預定義長度，則strcpy函數(shù)會導致緩沖區(qū)溢出；而gets函數(shù)則永遠不能被安全地使用，因為gets函數(shù)沒有邊界檢查，當輸入的字符串長度大于目標數(shù)組的長度時，將發(fā)生緩沖區(qū)溢出，可能會導致程序運行異?；虮蝗肭终呃谩?/p>

此外，未受限制的格式化輸出字符串也可能會導致安全漏洞。這種漏洞是由于應用程序將輸入字符串的數(shù)據(jù)作為命令進行評估。如果惡意用戶可以完全或部分地控制格式化字符串的內(nèi)容，則可能會導致應用程序崩潰、堆棧內(nèi)容泄露、任意內(nèi)存寫入等后果。此外，攻擊者還可以執(zhí)行任意代碼并以易受攻擊進程的權限運行，從而破壞系統(tǒng)的安全和穩(wěn)定性。
即使是最有經(jīng)驗的程序員也可能犯錯。研究表明，他們通常只能以約50% 的效率發(fā)現(xiàn)自己的錯誤。那么如何確保安全問題，例如緩沖區(qū)溢出的情況不會出現(xiàn)在最終產(chǎn)品中呢？編譯器可能會看到顯而易見的起點，但它可能僅實現(xiàn)語言標準的子集，語言標準的解釋可能因編譯器而異，這可能導致未來的移植或語義錯誤。最好的方法是根據(jù)編碼標準對代碼進行檢查，例如CERT C或CERT C++。正如我們所看到的，C和C++都具有未定義和未指定的行為，應該避免使用。而編碼標準正提供了一種做到這一點的方法。

編碼標準是一組規(guī)則，通常由一個團隊根據(jù)多年的經(jīng)驗制定，可以讓開發(fā)人員對其代碼更有信心。通過使用編碼標準遵循一組規(guī)則，降低引入錯誤的可能性，使代碼更易于維護。任何安全系統(tǒng)的起點都是使用防御性實現(xiàn)技術，使軟件即使在面臨不利情況時也能繼續(xù)運行。公認的編碼標準意味著其已經(jīng)考慮了常見的使用情況，因為C和C++都具有可能導致關鍵或未指定行為的特性。編碼標準因此定義了一個語言子集，以防止使用會導致此類行為的構造方式。此外，編碼標準將實現(xiàn)強類型，它確保對語言數(shù)據(jù)類型有所了解，從而防止某些類別的編程錯誤。

CERT部門協(xié)助開發(fā)的編碼標準專注于安全，它們被認為是一個全面的程序安全標準，并在多個行業(yè)中使用。該標準由一個在線社區(qū)開發(fā)，有單獨的標準適用于C、C++和Java。然而，由于C和C++之間存在重疊，許多CERT C規(guī)則已經(jīng)包括在內(nèi)。只需添加一些額外的規(guī)則，便可關注C++語言中沒有完全覆蓋的部分。如何通過限制使用某些庫函數(shù)來創(chuàng)建一個安全的C語言子集，以提高代碼的安全性？這可以通過引入一些規(guī)則來實現(xiàn)，比如INTC和A-R等，這些規(guī)則旨在防止常見的安全問題，例如緩沖區(qū)溢出和輸入驗證等。ARR30-C:不要形成或使用超出邊界的指針或數(shù)組。如果使用越界指針或數(shù)組，就可能會導致程序錯誤和安全漏洞。因此，在編寫程序時，應該確保所有指針和數(shù)組的訪問都在其有效范圍內(nèi)。如果需要進行指針或數(shù)組的操作，應該先檢查其有效范圍，再進行后續(xù)的處理。這樣可以避免因為越界訪問而導致的程序錯誤和安全漏洞。例如，如果使用指針訪問數(shù)組元素時，應該先檢查指針是否指向數(shù)組的有效范圍內(nèi)，再進行訪問操作。如果指針越界，就可能會導致程序崩潰或者被攻擊者利用。因此，ARR30-C規(guī)則的實踐可以提高程序的安全性和穩(wěn)定性。ARR38-C:保證庫函數(shù)不會形成無效指針。它要求在使用庫函數(shù)時，必須保證傳遞給函數(shù)的指針參數(shù)是有效的，即指向已分配的內(nèi)存區(qū)域或NULL指針。如果傳遞給函數(shù)的指針參數(shù)是無效的，那么就可能會出現(xiàn)程序錯誤和安全漏洞。
因此，在使用庫函數(shù)時，應該先檢查傳遞給函數(shù)的指針參數(shù)是否有效，再進行后續(xù)的處理。這樣可以避免因為傳遞無效指針而導致的程序錯誤和安全漏洞。例如，如果使用strcpy()函數(shù)將一個字符串復制到另一個字符串中，那么應該先檢查目標字符串的指針是否有效，再進行復制操作。如果目標字符串的指針無效，那么就可能會導致程序崩潰或者被攻擊者利用。因此，ARR38-C規(guī)則的實踐可以提高程序的安全性和穩(wěn)定性。
EXP39-C: 不要通過不兼容類型的指針訪問變量。如果使用不兼容類型的指針訪問變量，就可能會導致程序錯誤和安全漏洞。因此，在訪問變量時，應該使用與變量類型兼容的指針。如果需要使用不兼容類型的指針，可以通過類型轉換來實現(xiàn)。但是，在進行類型轉換時，需要確保轉換后的指針仍然指向有效的內(nèi)存區(qū)域，否則就可能會出現(xiàn)程序錯誤和安全漏洞。因此，EXP39-C規(guī)則的實踐可以提高程序的安全性和穩(wěn)定性。
FIO37-C: 在使用fgets()或fgetws()函數(shù)讀取輸入時，不要假定函數(shù)返回的字符串非空。因為這兩個函數(shù)在讀取輸入時可能會遇到文件結束符或讀取錯誤等情況，導致返回的字符串為空。如果程序在使用fgets()或fgetws()函數(shù)時假定返回的字符串非空，那么就可能會出現(xiàn)程序錯誤和安全漏洞。因此，在使用fgets()或fgetws()函數(shù)時，應該先檢查返回的字符串是否為空，再進行后續(xù)的處理。這樣可以避免因為假定字符串非空而導致的程序錯誤和安全漏洞。
STR31-C: 確保字符串存儲空間足夠容納字符數(shù)據(jù)和空字符終止符。這條規(guī)則的目的是防止緩沖區(qū)溢出和其他安全漏洞，從而提高代碼的安全性和可靠性。具體實現(xiàn)方法包括使用安全的字符串函數(shù)、檢查字符串長度和緩沖區(qū)大小、避免使用不安全的字符串拼接等。在編寫代碼時，應該遵循這條規(guī)則，并結合實際情況選擇相應的實現(xiàn)方法，以確保代碼的安全性和可靠性。STR32-C: 不要將非零終止字符序列傳遞給期望字符串的庫函數(shù)。旨在防止將非空字符終止的字符序列傳遞給期望字符串的庫函數(shù)。這條規(guī)則的目的是防止緩沖區(qū)溢出和其他安全漏洞，從而提高代碼的安全性和可靠性。具體實現(xiàn)方法包括使用安全的字符串函數(shù)、檢查字符串長度和緩沖區(qū)大小、避免使用不安全的字符串拼接等。在編寫代碼時，應該遵循這條規(guī)則，并結合實際情況選擇相應的實現(xiàn)方法，以確保代碼的安全性和可靠性。

03靜態(tài)代碼分析工具如何有效地實現(xiàn)安全編碼標準？

如何實施編碼標準以確保代碼的正確性和合規(guī)性呢？CERT C標準規(guī)定了確定性、不確定性和合規(guī)性的要求，并強制要求代碼不得違反任何規(guī)則。同時，建議遵循推薦操作以便更容易符合規(guī)則。為了檢查代碼是否違反規(guī)則，該標準建議使用靜態(tài)代碼分析工具。

在軟件開發(fā)生命周期中，手動和自動代碼審查都有其適用的場景，例如自動化工具無法知道代碼的實際意圖。然而，手動代碼審查的結果會受到審核人員專業(yè)知識的影響。靜態(tài)代碼分析可以檢查很少被控制的代碼片段，這些代碼片段通常無法通過其他方法測試。這可以找出異常處理程序或日志系統(tǒng)中的缺陷。與手動代碼審查相比，其速度更快，而且不占用開發(fā)人員的時間，使他們能夠更專注于開發(fā)。開發(fā)者廣泛認為手動審核和自動靜態(tài)代碼分析的結合是最有效的方式，因為這是識別漏洞和弱點的最佳方式，CERT C 和CERT C++ 都應該使用靜態(tài)代碼分析工具，最好是行業(yè)標準的工具，如Helix QAC，其對CERT編碼規(guī)范的覆蓋度達到100%。這款Perforce的靜態(tài)代碼分析工具可以驗證代碼符合編碼指南，并提供這種符合性的證據(jù)，以滿足網(wǎng)絡安全要求。Helix QAC 具有完整的第三方 C 和 C++ 語言庫的覆蓋，這使得開發(fā)人員更容易驗證軟件是否免受常見代碼安全漏洞的影響。

04總結
總之，實施編碼標準是確保代碼質(zhì)量的重要步驟，它可以幫助開發(fā)人員避免常見的錯誤和漏洞，從而提高軟件的可靠性和安全性。同時，使用靜態(tài)分析工具進行全面的代碼審查可以進一步加強代碼的正確性和符合性。