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

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

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

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

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

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

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

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

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

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

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

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

自定義檢查器

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

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

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

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

讓我們仔細看看這些機制。

配置文件

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

代碼注釋

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

例如，假設(shè)有一個名為 foo 的內(nèi)部函數(shù)采用單個整數(shù)參數(shù)，并且當(dāng)此參數(shù)為 -1 時引入了潛在的安全漏洞?？梢酝ㄟ^向foo主體添加一些代碼來實現(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)用從未實際執(zhí)行，而是由工具解釋為對基礎(chǔ)分析引擎的指令。如果分析得出結(jié)論，可能滿足觸發(fā)條件，則它將發(fā)出帶有給定消息的警告。

大多數(shù)程序員不喜歡用這樣的注釋來混淆他們的代碼，所以有一種替代方法來實現(xiàn)這種檢查，允許它寫在單獨的文件中。當(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í)行時，永遠不應(yīng)該調(diào)用 bar。可以按如下方式實施檢查：

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ā)出警告。

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

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

用于中間表示的 API

實現(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é)點定義訪問者。訪問者的接口允許與構(gòu)造進行模式匹配。

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

提高軟件質(zhì)量

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

審核編輯：郭婷