通過高級靜態(tài)分析進(jìn)行特定于域的屬性檢查

眾所周知，高級靜態(tài)分析工具擅長發(fā)現(xiàn)程序中的一般缺陷。借助自定義的屬性檢查器，最終用戶還可以擴(kuò)展它們，以查找特定應(yīng)用程序特有的特定于域的錯誤。

先進(jìn)的靜態(tài)分析工具使用復(fù)雜的全程序、路徑敏感技術(shù)來發(fā)現(xiàn)深層語義問題，包括安全缺陷和安全漏洞。這些工具識別的幾個缺陷可以在CWE/SANS前25個最危險的編程錯誤中找到，其中列出了為了降低安全風(fēng)險而要避免的最重要的錯誤。

具體來說，開箱即用的高級靜態(tài)分析工具可以找到通用編程缺陷。來自靜態(tài)分析工具的典型通用報告可能會顯示警告，例如未初始化的變量、緩沖區(qū)溢出、無法訪問的條件和無法訪問的調(diào)用等;但是，并非所有安全漏洞或安全錯誤都是由一般問題引起的。許多缺陷是特定應(yīng)用所獨(dú)有的。

這些工具的一個經(jīng)常被低估的方面是它們是可擴(kuò)展的，因此通常也可以對其進(jìn)行配置或編程以查找違反特定于域的規(guī)則的情況。因此，如果開發(fā)團(tuán)隊(duì)有自己的內(nèi)部規(guī)則來使用專有API，或者要求程序員使用特定的習(xí)慣用語，那么通?？梢跃帉懸粋€檢查器來表示違反這些規(guī)則。因此，程序員通常只需很少的編程工作，就可以顯著增加他們從工具中獲得的價值。

一個常見的用例是當(dāng)發(fā)生錯誤并觸發(fā)漫長而痛苦的診斷和調(diào)試期時。找到缺陷后，明智的做法是首先在代碼中查找重復(fù)錯誤的其他位置，然后采取措施檢測錯誤是否再次發(fā)生。對現(xiàn)有代碼和新代碼運(yùn)行自定義檢查可能是實(shí)現(xiàn)此目的的有效、低成本方法。這些工具的工作原理以及如何自定義它們的檢查器是使用 CodeSonar 中的代碼片段描述的，盡管這些原則也可以與其他高級靜態(tài)分析工具一起使用。

高級靜態(tài)分析的工作原理

要了解擴(kuò)展的不同編寫方式，首先要了解什么是靜態(tài)分析，以及靜態(tài)分析工具如何在后臺工作。

靜態(tài)分析工具的工作方式與編譯器非常相似。他們將源代碼作為輸入，然后對其進(jìn)行解析并轉(zhuǎn)換為中間表示 （IR）。高級靜態(tài)分析工具架構(gòu)的框圖如圖 1 所示。編譯器將使用 IR 生成目標(biāo)代碼，而靜態(tài)分析工具保留 IR，而檢查器通常通過遍歷或查詢 IR 來實(shí)現(xiàn)，查找指示缺陷的特定屬性或模式。

圖1：高級靜態(tài)分析工具的架構(gòu)

高級工具從復(fù)雜的符號執(zhí)行技術(shù)中獲得強(qiáng)大功能，這些技術(shù)通過控制流圖探索路徑。這些算法跟蹤程序的抽象狀態(tài)，并知道如何使用該狀態(tài)來排除對不可行路徑的考慮。

特定于域的屬性的檢查器可以訪問這些表示形式，并以各種方式利用分析算法。

自定義檢查器

最終用戶如何創(chuàng)作自定義屬性檢查器？這在很大程度上取決于屬性的性質(zhì)，因此有幾種機(jī)制可用：

可以通過向配置文件添加指令來擴(kuò)展現(xiàn)有檢查器。

用戶可以向其代碼添加注釋，以指示分析查找某些屬性。如果用戶不希望干擾源代碼，則可以以面向方面的方式在側(cè)面完成這些注釋。

API 允許用戶訪問所有中間表示形式。通常，使用訪問者模式，允許擴(kuò)展利用分析已在執(zhí)行的遍歷。

讓我們仔細(xì)看看這些機(jī)制。

配置文件

這些先進(jìn)的靜態(tài)分析工具實(shí)現(xiàn)了數(shù)十個檢查器。通常，用戶需要一個與內(nèi)置檢查器略有不同的檢查器，并且其中許多檢查器都設(shè)計為可擴(kuò)展的。一類檢查器查找禁止使用的函數(shù)。例如，眾所周知，C 庫函數(shù) get 是不安全的。檢查器由一個階段實(shí)現(xiàn)，該階段查找對函數(shù)名稱的引用，然后將它們與一組正則表達(dá)式進(jìn)行匹配。通過向配置文件添加行來向此集合添加其他正則表達(dá)式是一件簡單的事情。

代碼注釋

編寫檢查器的第二種方法是向代碼添加注釋。

例如，假設(shè)有一個名為 foo 的內(nèi)部函數(shù)采用單個整數(shù)參數(shù)，并且當(dāng)此參數(shù)為 -1 時引入了潛在的安全漏洞。可以通過向foo主體添加一些代碼來實(shí)現(xiàn)對這種情況的檢查，如下所示：

void foo(int x)

{

#ifdef __CSURF__

csonar_trigger(x, “==”, -1,

“Dangerous call to foo()”);

#endif __CSURF__

…

}

#ifdef構(gòu)造可確保常規(guī)編譯器看不到此新代碼。但是，當(dāng)該工具分析此代碼時，會看到對csonar_trigger的調(diào)用。因此，此調(diào)用從未實(shí)際執(zhí)行，而是由工具解釋為對基礎(chǔ)分析引擎的指令。如果分析得出結(jié)論，可能滿足觸發(fā)條件，則它將發(fā)出帶有給定消息的警告。

大多數(shù)程序員不喜歡用這樣的注釋來混淆他們的代碼，所以有一種替代方法來實(shí)現(xiàn)這種檢查，允許它寫在單獨(dú)的文件中。當(dāng) foo 的源代碼不可用時，例如當(dāng)它位于第三方庫中時，此方法也適用。為此，檢查器的作者將編寫一個替換函數(shù)，如下所示：

void csonar_replace_foo(int x)

{

csonar_trigger(x, “==”, -1,

“Dangerous call to foo()”);

foo();

}

當(dāng)分析看到csonar_replace_foo的定義時，它會將代碼中的所有 foo 調(diào)用（csonar_replace_foo 內(nèi)部的調(diào)用除外）視為對 csonar_replace_foo 的調(diào)用。

此觸發(fā)器習(xí)慣用法適用于檢查時態(tài)屬性，尤其是函數(shù)調(diào)用序列。假設(shè)有一條規(guī)則說，在 foo 執(zhí)行時，永遠(yuǎn)不應(yīng)該調(diào)用 bar?？梢园慈缦路绞綄?shí)施檢查：

static int foo_is_executing = 0;

void csonar_replace_foo(int x) {

foo_is_executing = 1;

foo(x);

foo_is_executing = 0;

}

void csonar_replace_bar(void) {

csonar_trigger(foo_is_executing,

“==”, 1,

“Call to bar from foo”);

bar();

}

請注意，全局狀態(tài)變量用于記錄 foo 是否處于活動狀態(tài)。在輸入 foo 之前，它被設(shè)置為 1，然后在 foo 返回后重置為零。然后在 bar 中的觸發(fā)器中檢查此變量，如果設(shè)置為 1，將發(fā)出警告。

前面的示例演示如何檢查全局屬性。相同的機(jī)制可用于編寫對單個對象的屬性的檢查?？梢詫傩愿郊拥綄ο笠愿櫰錉顟B(tài)。

這種方法允許用戶幾乎像編寫動態(tài)檢查一樣編寫靜態(tài)檢查。這種檢查的 API 很小，語言是 C，所以有一個溫和的學(xué)習(xí)曲線。這種簡單性具有欺騙性：該技術(shù)可用于實(shí)現(xiàn)相當(dāng)復(fù)雜的檢查。

用于中間表示的 API

實(shí)現(xiàn)自定義檢查的最終方法是使用提供對基礎(chǔ)表示形式 （IR） 的訪問權(quán)限的 API。一家公司使用此 API 查找用于處理硬件錯誤的自定義習(xí)慣用法的沖突。

此 API 也可用于其他程序分析任務(wù)。例如，一家醫(yī)療設(shè)備公司主要使用一種工具，不僅識別其代碼中的潛在任務(wù)問題，而且還發(fā)出允許他們交互式探索堆棧配置屬性的信息。其他應(yīng)用程序包括收集代碼的自定義指標(biāo)和生成程序可視化工具的輸入。

可以使用訪問者模式編寫許多檢查 - 該函數(shù)作為給定類型的每個 IR 元素的回調(diào)調(diào)用?？梢詾榭刂屏鲌D和語法樹中的文件、標(biāo)識符、子程序和節(jié)點(diǎn)定義訪問者。訪問者的接口允許與構(gòu)造進(jìn)行模式匹配。

CodeSonar具有一種特殊的訪問者類型，在控制流圖的路徑探索期間調(diào)用該訪問者。這允許檢查器作者編寫復(fù)雜的檢查，以利用該工具的內(nèi)置路徑敏感程序分析功能。這種檢查器的一個關(guān)鍵方面是它使用分析部分，消除了對不可行路徑的探索，這會自動降低誤報結(jié)果的概率。

提高軟件質(zhì)量

先進(jìn)的靜態(tài)分析工具已成為軟件開發(fā)人員必不可少的工具，因?yàn)樗鼈兡軌虬l(fā)現(xiàn)嚴(yán)重的安全和安全缺陷。創(chuàng)作自定義檢查器是提高這些工具有效性的低成本方法。

審核編輯：郭婷