###### Abstract  
We propose CanaryExp, an exploitability evaluation solution for vulnerabilities among binary programs protected by StackGuard. CanaryExp devises three novel techniques, namely canary leakage proof of concept generation, canary leaking analysis time exploitation, and dynamic canary-relocation-based exploitability evaluation. The canary leakage proof of concept input generation mechanism first traces the target program's execution, transforming the execution state into some canary leaking state, from which some canary leaking input is derived. This input can be deemed as proof that some vulnerability that can lead to canary leakage exists. The canary leaking analysis time exploit generation then performs incremental analysis based on the canary leaking input, crafting analysis time exploit that can complete vulnerability exploitation in the analysis time environment. Based on the analysis time exploit, the dynamic canary-relocation-based exploitability evaluation component collects the necessary metadata, on which an exploitation session is automatically constructed that can not only leak the runtime canary and relocate it in the input stream but also evaluate the exploitability of the desired vulnerability. Using a benchmark containing six test programs, eight challenges from some network challenging events and four real-world applications, we demonstrate that CanaryExp can generate canary leaking samples more effectively than existing test case generation methods and automatically evaluate the exploitability for vulnerabilities among programs where the StackGuard protection mechanism is deployed. vulnerability; canary; information leak; automatic exploit generation +
Footnote †: journal: _aciences_  
0000-0002-313-3000-3000-3000-3000-3000-3000-3000-3000-3000-3000-3000-3000-3000-3000-3000-30000-30000-3000-3000-30000-30000-3000-30000-3000-30000-30000-3  
While proven effective in addressing classical vulnerabilities in binary programs, including stack overflow [6; 7], heap overflow [8; 9; 10; 11], and use-after-free [12; 13; 14], the method remains adaptable under circumstances where exploitation mitigation options, including non-executable stack (abbr. NX) [15], address space layout randomization (abbr. ASLR) [16], and SafeSEH [17], are deployed. However, for vulnerable programs where the StackGuard [18] exploitation mitigation option is turned on and it is necessary to actively bypass this mitigation in the exploitability evaluation process, current methods generally fail in verifying the exploitability of the desired vulnerability. StackGuard prevents the return address from being changed by overflow vulnerabilities by inserting a 'canary' on the way from the local buffer variable to the return address stored on the stack. When the control returns after a function body's execution, it checks whether the canary is not altered by comparing it with its original copy saved somewhere else, before jumping to the function's return address. If the canary is determined to be overwritten, StackGuard terminates the execution immediately, therefore protecting the program from being attacked through buffer overflow vulnerabilities. Currently, this mechanism is taken as a default option in modern compilation systems [19; 20], and is widely adopted in real-world applications. To complete vulnerability evaluation under this condition, human analysts generally have to leak the canary first, then place the leaked canary at the exact location in the exploitation payload, hijacking the control flow through stack smashing while bypassing the runtime canary check enforced by StackGuard as if the desired canary has not been overwritten yet. We find that three key challenges should be resolved to make current AEG systems adaptable to this issue. These challenges are listed below. Challenge 1: canary leakage event forgeryAs StackGuard-protected programs would not explicitly manifest the canary value to the external analyst, POC input generally smashes the stack structure completely, leading the execution to termination.