靜態代碼分析之C語言篇
一、序言
從本篇起，筆者將開啟c語言代碼安全分析篇章，為大家詳細剖析c語言靜態代碼分析的各種技術細節。
二、依賴分析
依賴分析是c語言靜態代碼分析中一個非常重要的環節，它的分析準確與否，關系到了后續的漏洞分析的準確性。
什么是依賴分析
依賴圖是源代碼文件與其依賴庫之間的依賴關系的一種圖形表示。我們知道，在c語言中，項目真正用到的一些組件庫一般只有在編譯的時候才能夠確定，它不像java項目，一份代碼，到處運行，而是一份代碼，多次編譯，因為很多時候，我們為了跨平臺的需要，需要給同一個組件準備不同的適配方案，這也是c語言項目被一些開發人員長期詬病的地方。在c/c++項目的分析工作中，我們首要解決的就是程序文件之間的依賴關系，因為這直接影響到了后續我們靜態代碼分析的準確性。
依賴圖的作用
根據生成的文件依賴圖，我們可以清晰而準確的知道整體項目的組織脈絡。在后續的符號識別和函數調用鏈生成階段，需要依靠依賴圖來找到目標庫文件，從而保證符號識別和函數調用鏈構建的準確性。
如何進行依賴分析
針對c/c++項目文件依賴圖的生成，業內的主流辦法是通過解析compile_commands.json文件中記錄的編譯命令來進行生成。詳情可參考pvs-stdio這款商業sca掃描器的技術說明文檔(pvs-studio.com)。而compile_commands.json文件可以通過編譯工具(make、ninja等)生成，具體的辦法步驟是：
1.收集編譯過程的輸出信息。
2.將輸出信息重定向到解析器，通過正則匹配的方式，生成compile_commands.json文件。
當然，cmake等變異工具本身也支持生產compile_commands.json文件。具體是在構建方案的時候，指定參數：-DCMAKE_EXPORT_COMPILE_COMMANDS=1。
那么，有了compile_commands.json文件之后要如何進行依賴分析呢？
我們先看下compile_commands.json文件的數據結構：
[
{
"directory": "/Users/pony/work/sourcehub/cmake-examples/01-basic/B-hello-headers/build",
"command": "/Library/Developer/CommandLineTools/usr/bin/cc -I/Users/pony/work/sourcehub/cmake-examples/01-basic/B-hello-headers/include -isysroot /Library/Developer/CommandLineTools/SDKs/MacOSX10.15.sdk -o CMakeFiles/hello_headers.dir/src/Hello.c.o -c /Users/pony/work/sourcehub/cmake-examples/01-basic/B-hello-headers/src/Hello.c",
"file": "/Users/pony/work/sourcehub/cmake-examples/01-basic/B-hello-headers/src/Hello.c"
},
{
"directory": "/Users/pony/work/sourcehub/cmake-examples/01-basic/B-hello-headers/build",
"command": "/Library/Developer/CommandLineTools/usr/bin/cc -I/Users/pony/work/sourcehub/cmake-examples/01-basic/B-hello-headers/include -isysroot /Library/Developer/CommandLineTools/SDKs/MacOSX10.15.sdk -o CMakeFiles/hello_headers.dir/src/main.c.o -c /Users/pony/work/sourcehub/cmake-examples/01-basic/B-hello-headers/src/main.c",
"file": "/Users/pony/work/sourcehub/cmake-examples/01-basic/B-hello-headers/src/main.c"
}
]
其中directory表示當前編譯目錄，command表示當前執行的編譯命令，file表示待編譯的源碼文件。其中，在command命令中，參數I后面跟的是當前源碼所依賴的頭文件目錄的路徑，編譯器在編譯的時候會在給定的這個目錄下搜索相關的頭文件。
但是，顯然只找到頭文件是不夠的，我們還需要找到函數的定義位置，這樣我們才能夠真正建立起函數調用所在文件和函數定義所在文件之間的關聯關系。下面我們為了更好的說明aurora代碼安全分析引擎是如何對c項目進行依賴分析的，下面，我們以一個c代碼項目為示例進行闡述。
項目目錄:
.
├── CMakeLists.txt
├── README.adoc
├── include
│ └── Hello.h
└── src
├── Hello.c
└── main.c
2 directories, 5 files
CMakeLists.txt
# Set the minimum version of CMake that can be used
# To find the cmake version run
# $ cmake --version
cmake_minimum_required(VERSION 3.5)
# Set the project name
project (hello_headers)
# Create a sources variable with a link to all c files to compile
set(SOURCES
src/Hello.c
src/main.c
)
# Add an executable with the above sources
add_executable(hello_headers ${SOURCES})
# Set the directories that should be included in the build command for this target
# when running g++ these will be included as -I/directory/path/
target_include_directories(hello_headers
PRIVATE
${PROJECT_SOURCE_DIR}/include
)
include/Hello.h
#ifndef __HELLO_H__
#define __HELLO_H__
void print();
#endif
src/Hello.c
#include "Hello.h"
void print()
{
printf("hello world.");
}
src/main.c
#include "Hello.h"
int main(int argc, char *argv[])
{
print();
return 0;
}
這個項目主要由一個主程序和一個組件構成，主程序中通過頭文件Hello.h對組件中定義的print函數進行調用。那么，首先明確，我們期望建立起來的依賴關系是main.c和Hello.c之間的依賴關系。通過對compile_commands文件的分析，我們已經可以知道main.c和Hello.c都和Hello.h是有依賴關系的，只不過一個是API調用，一個是API定義。那么我們是否可以直接說明這兩個文件是有依賴的呢？那顯然是不行的，因為我們無法確定Hello.c中是否是定義了main.c中調用的print函數。只有同時滿足在main.c中調用了Hello.h中聲明的print函數，且在Hello.c中定義了Hello.h中聲明的print函數，那么我們才能夠認為，main.c和Hello.c之間是存在依賴關系的，這樣，我們后續才能夠據此建立起函數之間的調用關系，即函數調用鏈(這對于全局數據流構建分析很重要)。
我們可以用下面這個示意圖來表示這個推導過程。
其中，依賴確定模塊一，通過對compile_commands.json文件及相關源碼的AST的分析，確定兩個源碼文件引入了同一個頭文件，依賴確定模塊二，通過分析是否同時導入相同頭文件且一方為函數調用，另一方為函數定義，確定main.c文件到Hello.c之間的依賴關系，而調用鏈確定模塊，通過分析main函數中是否包含對函數print的調用，進而確定main.c中的main函數和src/Hello.c中的print函數的調用關系。
三、代碼數據庫構建
代碼數據庫，顧名思義，存儲的代碼相關的一些數據。這里的代碼數據庫可以認為是第一層代碼屬性圖，我們一般會在其中存儲源代碼的AST表示形式。至于源代碼的AST表示形式，我們可以通過一些AST提取工具來獲取，比如eclipse提供的cdt工具，亦或者一些開源的前端解析工具，如antlr，均可以完成這部分工作。當然，如果我們利用這些工具提取ast，那么獲得的僅是一個ast unit class的集合，而為了后續展示方便，同時也為了能夠通過分布式架構進行高效的分析，我們還需要對這些ast unit類進行必要的初步解析工作，然后將其轉為json格式進行持久化存儲，這部分的處理流程可用下圖表示：
四、函數調用圖構建
什么是函數調用圖
函數調用圖是函數之間的調用關系的一種圖形表示形式。在進行過程間數據流分析的時候，我們需要依賴函數調用圖求解函數調用鏈，以便于沿著這個調用鏈進行過程間數據流分析。
如何進行函數調用圖構建
函數調用鏈構建需要建立在依賴分析的基礎之上。在依賴分析中其實已經對這部分進行了形象的闡述，這里就不做過多的贅述。總的來說，依托依賴分析的結果，我們可以獲得兩個源碼文件之間的依賴關系，然后基于此，再對這些源碼中的函數定義信息進行遍歷分析，判斷下函數調用語句的函數簽名和函數定義的函數簽名是否一致，即可構建我們后續分析所需的函數調用鏈。
五、控制流及數據流分析
什么是控制流及數據流
程序控制流表示的是程序的各個語句結構之間的控制關系，總的來說有兩種形式，一種是基本塊控制關系圖，另一種是表達式控制關系圖。前者注重在基本塊之間的控制關系，后者注重在表達式之間的控制關系。而數據流表示的是程序中數據的流動關系，其中，我們會比較關注變量的定義和引用關系，即def-use鏈，以及一些賦值語句引起的數據流動關系。
為什么要進行控制流和數據流分析
控制流分析和數據流分析是程序靜態分析中比較核心的分析環節，我們在進行代碼安全審計的時候，我們認定某一處存在漏洞，如sql注入漏洞，一般需要有比較完整的污點傳播路徑，才能夠比較有充分的理由其漏洞進行判定，而污點傳播路徑依賴于數據流分析，而數據流分析也依賴于控制流分析。總的來說，java和c的數據流分析的方法大同小異，針對java方面的控制流及數據流分析方法，我已在前一篇文章中進行了詳細的描述，這里就不做過多的贅述了，詳情見：《DevSecOps建設之白盒續篇 - FreeBuf網絡安全行業門戶》。
六、代碼安全分析
棧溢出漏洞
那么，我們如何將靜態代碼分析技術應用在代碼安全分析上呢？我們以pwnable.kr上的一個棧溢出靶場bof為例，詳細闡述aurora白盒引擎是如何進行c代碼安全分析的。漏洞代碼如下：
#include <stdio.h>
#include <string.h>
#include <stdlib.h>
void func(int key){
char overflowme[32];
printf("overflow me : ");
gets(overflowme); // smash me!
if(key == 0xcafebabe){
system("/bin/sh");
}
else{
printf("Nah..\n");
}
}
int main(int argc, char* argv[]){
func(0xdeadbeef);
return 0;
}
簡要說明：這是一段比較典型的棧溢出漏洞代碼，在函數func中，我們聲明并定義了一個字符數組overflowme，并給其分配了32個字節的內存空間。程序中調用gets函數，獲取命令行輸入流，如果字符流長度在overflowme這個變量定義的合法區間內，那么這個程序將按照正常的邏輯走，如果超過了overlfowme定義的合法區間，那么，在沒有對這個輸入流長度進行合法性校驗的前提下，將會造成棧溢出漏洞，覆蓋變量key的內存空間，影響預期的分支流程走勢，即走到if的then邏輯部分，執行system函數，反彈一個bash窗口。這個調用過程發生時，內存的棧幀分布示意圖如下：
其中，下層為func棧幀，上層為main棧幀，棧幀的排布由高地址向低地址排布，先調用的函數占據高地址，后調用的函數占據低地址，而數據寫入規則則是由低地址到高地址。我們在實際利用的時候，如果要改變if分支中的邏輯，可通過輸入以下payload實現攻擊：
payload="a"*52+ chr(0xbe) + chr(0xba) + chr(0xfe) +chr(0xca);
其中，chr(0xbe) + chr(0xba) + chr(0xfe) +chr(0xca)即為0xdeadbeef，而52表示key和overflow之間的距離，這些數據可以通過gdb調試獲得。通過給定overflowme超出其合法值范圍的payload，我們即可實現對原有邏輯的篡改。
那么，針對這種漏洞，我們要怎樣通過靜態分析方法進行檢測呢？
我們可以從棧溢出的原理出發，來思考我們的防護策略。我們知道，棧溢發生的本質原因是在對變量進行傳值的時候，未對輸入數據的字節長度進行合法性校驗。那么，我們在檢測的時候可以枚舉源代碼中的內存寫入操作的函數調用表達式(如gets、memcpy等)，通過分析其在進行內存寫入的時候，寫入數據的值的大小是否比聲明的區間大來判定其是否存在漏洞。那么，問題就集中在了對兩者值的大小分析(區間分析)上了。針對緩沖區大小，我們可以根據變量對應的def-use鏈找到變量定義的位置，然后結合其變量定義表達式中和變量區間定義相關的ast數據，進行綜合分析判定。針對輸入的數據的區間大小，我們也可以用類似方式進行分析。當然，區間的值可能并不一定是常量，如果要追求分析的準確性，那么就要對區間范圍進行進一步的約束求解。
七、區間分析
什么是區間分析
區間分析是指通過約束求解算法，對變量和表達式的取值范圍進行跟蹤，為進一步的程序分析提供精確的數據支持。
為什么要做區間分析
通過上文可知，我們在做一些代碼安全分析的時候，比如棧溢出分析，如果我們不能夠比較準確的分析緩沖區和輸入數據的區間大小，那么我們是無法準確地判斷是否存在棧溢出漏洞的。
如何做區間分析
學術上，針對區間分析早有很多相關的方法分析方法，如王雅文、宮云戰等在第五屆中國測試學術會議上發表的論文《區間運算在軟件缺陷檢測中的應用》中就提到了一種區間分析方法。論文中提出，可針對不同的變量類型設置不同的初始區間值，然后通過表達式區間分析、條件區間分析、控制流區間分析三個不同緯度對變量的取值范圍進行約束求解。
1. 表達式區間分析
如表達式3*(++i)，如果i的取值范圍是[1,1]，那么執行完3*(++i)之后，其取將范圍將變成:[6,6]。
2. 條件區間分析
例如:
if(x>2){
}
else{
}
區間分析在代碼質量領域的應用
區間分析，可以應用于程序中的不可達代碼塊檢測、代碼覆蓋率分析等。例如:
void func(){
int i=5;
if(i<0){
i++;
}
}
初始控制流圖：
轉為帶區間信息的控制流圖：
從帶區間的控制流圖中可以發現，在執行到stmt_3語句時，因為i<0這個條件的取值范圍是[-∞,-1]n[5,5]=?，所以i<0分支下的所有表達式語句上i的區間范圍會被設置為null，表示不可達到。統計出所有執行的語句數量及總語句數量即可計算得語句覆蓋率，計算公式為：可執行語句數量/語句總數。統計所有可達分支數量及總的分支數量即可計算得分支覆蓋率，計算公式為：可達分支/分支總數。
區間分析在代碼安全領域的應用
比如上面的那個溢出漏洞案例。我們可以得到其初始控制流圖為：
轉化為區間為帶區間信息的控制流圖：
其中在stmt_3(即語句gets(overflowme))中，overflowme的區間范圍易求得為[0,32]，而用戶輸入的數據的范圍是[0,+∞]，這里用1000作為缺省值，當然為了以防萬一，也可以設置大一點，顯而易見這里用戶輸入的數據的大小的區間范圍遠大于overflowme最大的取值32，那么這里是肯定存在溢出漏洞的。當然，要比較精確的判定溢出漏洞，我們還可以結合compile_commands.json中的編譯命令(如一些編譯時設定的堆棧溢出的防護策略)進行綜合判定。
八、CI流程自動化
一款靜態代碼安全分析工具，要好用，不僅要引擎能力足夠硬核，在流程方面也應該自動化，讓使用者能夠很方便的配置，很容易地集成到一些主流的CI piplines中。下面我們以gitlab ci，詳細闡述我們是如何實現c代碼自動化安全、代碼質量檢測。
以下是示例ci例子
# This file is a template, and might need editing before it works on your project.
# This is a sample GitLab CI/CD configuration file that should run without any modifications.
# It demonstrates a basic 3 stage CI/CD pipeline. Instead of real tests or scripts,
# it uses echo commands to simulate the pipeline execution.
#
# A pipeline is composed of independent jobs that run scripts, grouped into stages.
# Stages run in sequential order, but jobs within stages run in parallel.
#
# For more information, see: https://docs.gitlab.com/ee/ci/yaml/README.html#stages
stages: # List of stages for jobs, and their order of execution
- build
- test
- deploy
build-job: # This job runs in the build stage, which runs first.
image: ci_vtsmap:latest
stage: build
script:
- echo "Compiling the code..."
- mkdir build && cd build
- cmake -DCMAKE_EXPORT_COMPILE_COMMANDS=1 ..
- curl -F "file=@compile_commands.json" -F "user=${GITLAB_USER_NAME}" -F "projectname=${CI_PROJECT_NAME}" -F "language=c" -F "email=xxx@gmail.com" -F "type=git"-F "branch=${CI_COMMIT_BRANCH}" -F "commitid=${CI_COMMIT_SHA}" -F "gitaddr=${CI_PROJECT_URL}" -F “token=xxx” -x POST http://[domain]/pushjob/
- make .
- echo "Compile complete."
deploy-job: # This job runs in the deploy stage.
stage: deploy # It only runs when *both* jobs in the test stage complete successfully.
script:
- echo "Deploying application..."
- echo "Application successfully deployed."
其中，我們會在原有的ci腳本中加入兩行命令，一行時在原有的cmake命令上加上參數-DCMAKE_EXPORT_COMPILE_COMMANDS=1 來生成compile_commands.json文件，以便于后端的靜態分析引擎進行依賴分析。以下命令用于提交任務信息：
curl -F "file=@compile_commands.json" -F "user=${GITLAB_USER_NAME}" -F "projectname=${CI_PROJECT_NAME}" -F "language=c" -F "email=xxx@gmail.com" -F "type=git" -F "branch=${CI_COMMIT_BRANCH}" -F "commitid=${CI_COMMIT_SHA}" -F "gitaddr=${CI_PROJECT_URL}" -F “token=xxx” -x POST http://[domain]/pushjob/九、總結
綜合來看，c代碼靜態分析目前最主要的難點在于區間分析，這部分分析的準確性對后續的漏洞分析的準確性有很大的影響。所以在c代碼靜態分析方面，區間分析方面需要花比較大的功夫去鉆研，不僅要保證分析的分析的準確性，同時也要考慮到分析的效率，因為很多c代碼項目，如linux內核等，代碼量非常龐大，如果沒有一個比較合理的算法，加快代碼分析速度，那么接入到企業內部使用，其體驗感也是非常差的。當然，精度和速度兩者一般情況下是一種此消彼長的關系的，如何從中達到一個平衡，還需要不斷的進行測試和實踐。
王雅文，宮云戰，楊朝紅，肖慶，區間運算在軟件缺陷檢測中的應用，第五屆中國測試學術會議論文集，2008，51-52。
