嵌入式代碼可能存在的致命漏洞

時間：2021-01-08 15:57:31

關鍵字：嵌入式代碼漏洞

手機看文章

掃描二維碼
隨時隨地手機看文章

[導讀]隨著互聯(lián)網的發(fā)展，嵌入式設備正分布在一個充滿可以被攻擊者利用的源代碼級安全漏洞的環(huán)境中。

來源 | 電子伊甸園

微信公眾號 | 嵌入式專欄

隨著互聯(lián)網的發(fā)展，嵌入式設備正分布在一個充滿可以被攻擊者利用的源代碼級安全漏洞的環(huán)境中。因此，嵌入式軟件開發(fā)人員應該了解不同類型的安全漏洞——特別是代碼注入。
術語“代碼注入”意味著對程序的常規(guī)數(shù)據(jù)輸入可以被制作成“包含代碼”，并且該程序可以被欺騙來執(zhí)行該代碼。 代碼注入缺陷意味著黑客可以劫持現(xiàn)有進程，并以與原始進程相同的權限執(zhí)行任何他們喜歡的代碼。
在許多嵌入式系統(tǒng)中，進程需要以最高的權限運行，因此成功的代碼注入攻擊可以完全控制機器以及竊取數(shù)據(jù)，導致設備發(fā)生故障，將其作為其僵尸網絡成員或使其永久無法使用。
代碼注入漏洞的關鍵方面是：

該程序從輸入通道讀取數(shù)據(jù)

該程序將數(shù)據(jù)視為代碼并對其進行編譯

在大多數(shù)情況下，程序故意像執(zhí)行代碼一樣執(zhí)行數(shù)據(jù)是不尋常的，但將數(shù)據(jù)用于構造有意執(zhí)行的對象卻很常見。

1 格式化字符串漏洞 大多數(shù)C程序員熟悉printf函數(shù)。大體上，這些格式字符串后跟一個其他參數(shù)的列表，并且該格式字符串被解釋為一組指令，用于將剩余的參數(shù)呈現(xiàn)為字符串。大多數(shù)用戶知道如何編寫最常用的格式說明符：例如字符串，小數(shù)和浮點數(shù)——％s，％d，％f——但是不知道還有其他格式字符串指令可以被濫用。
以下是printf函數(shù)通常被濫用的一種方式。有些程序員習慣編譯字符串如下：

printf（str）;

雖然這將在大部分時間內都具有所期望的效果，但它是錯誤的，因為printf的第一個參數(shù)將被編譯為格式字符串。所以，如果str包含任何格式說明符，它們就將被這樣編譯。例如，如果str包含'％d'，它會將printf參數(shù)列表中的下一個值解釋為整數(shù)，并將其轉換為字符串。在這種情況下，沒有更多的參數(shù)，但機器在執(zhí)行的時候并不了解這一點; 它所知道的全部是，函數(shù)的一些參數(shù)已經被推送到堆棧。
因為在C運行時沒有機制可以告訴機器已經沒有更多的參數(shù)了，所以printf將簡單地選擇恰好在堆棧中的下一個項目，將其編譯為一個整數(shù)并打印出來。很容易看出，這可以用來從棧中打印任意數(shù)量的信息。例如，如果str包含'％d％d％d％d'，則將會打印堆棧上接下來四個字的值。
雖然這是一個代碼注入安全漏洞，但由于它唯一可能造成的傷害就是可以被用來獲取棧中的數(shù)據(jù)，所以它還是可以被原諒的。可如果位于那里的是敏感數(shù)據(jù)（如密碼或證書密鑰），情況就會變得很糟；而且由于攻擊者還可以在那里寫入任意內存地址，因此情況還可能會變得更糟。

使這種糟糕情況的發(fā)生成為可能的是格式說明符'％n'。通常，相應的參數(shù)是指向整數(shù)的指針。當格式字符串為了建立結果字符串而被編譯時，一遇到'％n'，到目前為止寫入的字節(jié)數(shù)就被放置到由該指針所指示的存儲單元中了。例如，在下面的printf完成之后，i中的值將為4：

printf（“1234％n”，＆i）;

如果函數(shù)的實際參數(shù)比格式說明符更少，那么printf會將任何在堆棧上的數(shù)據(jù)作為參數(shù)編譯。因此，如果攻擊者可以控制格式字符串，那么它們可以將基本上任意的值寫入堆棧位置。因為堆棧是局部變量所在的位置，所以它們的值可以被改變。如果這些變量中有一些是指針，那么這個平臺甚至可以到達其他非堆棧地址。
真正對攻擊者來說有價值的目標是讓攻擊者控制程序的執(zhí)行部分。如果一個局部變量是一個函數(shù)指針，則攻擊者可以通過該指針的后續(xù)調用來編寫代碼，實現(xiàn)自己的目標。當函數(shù)返回時，攻擊者還可以將指令要被送達的地址覆蓋重寫。

2 避免代碼注入

避免代碼注入的最佳方法是通過設計。如果您可以使用一種永遠不會出現(xiàn)漏洞的語言，那么這是最好的因為您的代碼在構建時就是對一切攻擊免疫的?；蛘吣梢酝ㄟ^設計代碼來禁止可能導致這些問題的接口。不幸的是，在嵌入式系統(tǒng)中，這些選擇并不總是可行的。即使C是一種危險的語言，充斥著漏洞，但它仍然是許多組織架構的首選語言。鑒于此，開發(fā)人員應該了解其他避免代碼注入的方法。
應該遵循的兩個黃金規(guī)則以防止代碼注入漏洞： 1.如果你可以避免的話，盡量不要將數(shù)據(jù)像代碼一樣編譯； 2.如果你無法避免的話，請確保在使用數(shù)據(jù)之前驗證數(shù)據(jù)是否良好。
為避免格式字符串的漏洞，這些規(guī)則中的第一個是最合適的; 你可以編寫代碼如下：

printf（“％s”，str）;

這樣，str的內容只被視為數(shù)據(jù)。這是最不費腦子的辦法，只要你能找到所有應該做出這種修改的地方。但這對于大型程序來說可能是棘手的，特別是對于第三方代碼庫。

3 測試漏洞

測試這些類型的漏洞可能很困難; 即使能實現(xiàn)非常高的代碼覆蓋率的測試也不能觸發(fā)這些問題。測試安全漏洞時，測試人員必須采取一個攻擊者的心態(tài)。諸如模糊測試的技術可能是有用的，但是該技術通常太隨機，無法高度可靠。
靜態(tài)分析可以有效地發(fā)現(xiàn)代碼注入漏洞。注意到早期生成的靜態(tài)分析工具（如lint及其后代衍生產品）很不擅長發(fā)現(xiàn)這樣的漏洞，因為想要實現(xiàn)精確的查找漏洞就需要完成整個程序的路徑敏感分析。
最近出現(xiàn)的先進的靜態(tài)分析工具更加有效。靜態(tài)分析工具廠商對于哪些接口有危險，尋找目標的知識基礎以及如何有效地進行這些工作已經積累了豐富的經驗。
這里使用的關鍵技術是污染分析或危險信息流分析。這些工具通過首先識別潛在風險數(shù)據(jù)的來源，并對信息進行追蹤，了解信息是如何通過代碼不經過驗證就流入正在使用的位置的。同時這也是能實現(xiàn)整個流程可視化的最好工具。

4 結論

代碼注入漏洞是危險的安全問題，因為它們可能允許攻擊者中斷程序，有時甚至完全控制程序。那些關心如何在一個充滿潛在惡意的互聯(lián)網環(huán)境中確保他們的嵌入式代碼能夠安全使用的開發(fā)人員，應該將這樣的代碼注入漏洞，在開發(fā)周期和嚴格的代碼檢查中盡早消除。而上面提到的高級靜態(tài)分析工具是被推薦使用的。

來源：

http://www.newelectronics.co.uk/electronics-technology/code-injection-a-common-vulnerability/150031/