Cybersec

Intro 原論文 : Learning to Detect Memory-Related Vulnerabilities Motivation Memory-related Vulnerability可以大致理解為CTF中的Pwn相關Bug Pattern (Overflow, Use After Free, Out Of Bound, …)，也有一些其他的例如Memory Leak， 不過大多數的類型都涵蓋在Pwn的類別。而在對CVE的分析中發現，在其中被回報的漏洞有四成左右都是記憶體相關弱點，因此成為許多研究的目標，主要可以劃分為以下幾個面向 : Core Problem : 記憶體弱點的重要性以及危害性。記憶體弱點大多數時候都可以造成RCE (假如是在Stack上甚至可以很簡單的控Return Address)或是DoS (讓服務崩潰) Context : 記憶體弱點出現的地方大多數都是C/C++這種低階語言，因為支援手動、未被抽象化封裝的記憶體管理(malloc, free)，相比高階語言更加脆弱(error-prone) Goal : 在開發階段就及早偵測漏洞，去避免後續維護的成本。以藍芽為例，藍芽標準可能會有未定義行為(需要SDK去進行定義)，再往下又會有硬體製造商SDK的軟體錯誤以及開發者所撰寫程式碼的錯誤。 在整條供應鏈中只要任何一個環節出現弱點，都會對下游的軟體造成重大危害，就算下游針對不安全的SDK進行防禦(Sandbox, Seccomp, …)仍然有可能被攻破(Tesla in Pwn2Own 2023，參考 影片)。 因此及早偵測漏洞成為有價值的研究點 Existing Approaches 目前主流的漏洞分析主要為以下幾個方式 : 傳統的Static Analysis : 通常就是漏洞研究員在做的事，不過人工分析往往離不開以下幾個問題 : 極度仰賴既定的Pattern去做分析，可能沒辦法覆蓋所有可能的弱點 需要大量知識，若經驗不足可能無法正確識別漏洞，且需要花費成本去研究新的弱點(發現新的利用手法) 當Codebase變得相當大，分析工作的難度會急遽上升 基於深度學習的自動化分析 : 主要用來克服人工定義、辨識Bug pattern的困難，但往往無法發揮很好的效果 : 對於整體上下文的理解不足 : 深度學習在一個單位內通常只能處理少部分的程式碼片段(基本上大多數時候涵蓋範圍不會超過一個函數)，但記憶體漏洞通常會需要對多個函數的行為做分析 (例如經典的Heap選單題)，很多Bug難以透過分析一個小片段就去斷言是否存在，例如RNN或是NLP，他們就不是為了拿來處理這類問題的。 難以捕捉多粒度特徵 : 如同上一點說的，但有人想到可以用AST這種控制流的圖丟給GNN學習。這樣的作法又引起另外一個問題 : 當你把整支程式的AST丟給一個GNN， 又會遇到GNN自己本身在大規模的圖難以克服的問題，例如Oversmoothing，或是難以學習長期相依性 錯雜流程圖的相關問題 : 不同類型的抽象化(CPG, SDG)的Edge定義不同，但基於GNN的方法又只是用一些很簡單的分類法，導致難以準確的捕捉語意 MVD+ 結合小規模的學習(Code Slice)以及大規模(AST, CFG, …)的分析框架，解決了上述的三個問題 : ...

前言 眾所周知，glibc在2.24引入vtable檢查，使針對vtable的攻擊手段如FSOP, House of Orange等攻擊手法失效，不過很快有一條新的利用鏈被發現，就是FILE成員中的 _wide_data段，在glibc執行_wide_data上vtable的函式時，並不會進行vtable進行檢查，因此衍生出如House of Apple等可以在高版本(>=2.35)通殺的利用手段． 本文主要探討在glibc 2.31環境下利用_wide_data進行vtable劫持，以達成control flow FILE結構分析 所有的原始碼皆取自 glibc source browser : Glibc 2.31 Source code 當在C語言進行如 FILE *fp=fopen(...) 或是使用stdin/stdout/stderr時，glibc都是使用以下結構： struct _IO_FILE_plus { FILE file; const struct _IO_jump_t *vtable; }; 其中FILE在內部的實作如下： struct _IO_FILE_complete { struct _IO_FILE _file; #endif __off64_t _offset; /* Wide character stream stuff. */ struct _IO_codecvt *_codecvt; struct _IO_wide_data *_wide_data; struct _IO_FILE *_freeres_list; void *_freeres_buf; size_t __pad5; int _mode; /* Make sure we don't get into trouble again. */ char _unused2[15 * sizeof (int) - 4 * sizeof (void *) - sizeof (size_t)]; // 你可以把它當作padding }; 其中可以看到除了描述FILE結構相關的_file之外，還有許多用來描述Wide character的相關member, 其中可以看到*_wide_data，追進去看一下相關定義： ...

使用工具 VM 分析工具 : PEBear, DLL Export Viewer 組語除錯工具 : WinREPL C++ ROP Gadget : rp++ Debugger : x64dbg, Windbg Preview Windbg操作 | : Process Status ~ : Thread Status 顯示記憶體內容 : d{b|d|q|u} + Ln (顯示N個) 以某種資料結構解讀 : dt (module)!_name + rn (recursive) 對記憶體寫入 : 數值e{b|d|q}, 字串e{a|u|za|zu} (z : 指以NULL做結尾) 暫存器 : r, r [reg] = [val] 取值 : poi 反組譯 : u, uf 斷點 : bp [addr] .if [cond]{} .else{gc} 列出載入的模組 : lm 執行 : go, Step in : t, Step over : p Mapping : !address 查看權限 : !vprot 查看Error Code : !error Value [Flags], Flags=Win32, NTSTATUS… 查看Symbol : x module!symbol 呼叫慣例 流程控制 : call / ret 參數 : 使用 CX, DX, R8, R9, stack Prologue, Epilogue : 保存/恢復上一個frame的RBP Buffer Overflow 列舉一些危險的函數 ...