As more and more aspects of our society and economy rely on software, security vulnerabilities in programs have become an increasingly significant threat. One such class of vulnerabilities are out-of-bounds writes, which are still one of the most widespread and dangerous types of security bugs in memory-unsafe programming languages five decades after their initial conceptualization. Their discovery through automated methods like fuzzing, however, has gained substantial traction in the past years and facilitates their discovery in large numbers with minimal human intervention. On the other hand, the analysis following their initial discovery - triaging, root cause analysis, and patching - mostly requires human expertise and intuition. As this need for manual effort affects the time to assess a vulnerability's security implications and prioritize patching accordingly, partial automation of the triaging process is essential. A promising approach is the automatic extraction of vulnerability characteristics that provide vital clues for a bug's exploitability. Such characteristics, which typically require substantial effort to collect manually, can aid a human analyst in triaging and thereby speed up the process while, at the same time, making it more accessible. In this work, we investigate how the set of affected source code-level objects, which is a decisive indicator of an out-of-bounds write vulnerability's exploitability, can be automatically distilled from a program and an input suspected of causing an out-of-bounds write. As this poses unique challenges with regard to invasiveness, we propose a novel approach for out-of-bounds write detection that facilitates monitoring a compiled program for spatial memory safety violations without the need for instrumentation. We implement a prototype of our design and evaluate it on benchmarks and real-world vulnerabilities, showing that its detection performance is largely on par with state-of-the-art instrumentation-based detection approaches and even outperforms them in several scenarios at the cost of increased performance overhead and a higher rate of false positives.

Malware poses a serious security risk in today’s digital environment. The defense against malware mainly relies on proactive detection. However, antivirus products often fail to detect new malware when the signature is not yet available. In the event of a malware infection, the common remediation strategy is reinstalling the system. However, the user loses their personal data, and thus it is not an ideal solution. The academic works on malware remediation focus on system replay and recovery-oriented computing, which relies on heavy monitoring and is not suitable for a normal user’s personal computer. The work from Paleari et al. [31] proposed a remediation methodology that can be used entirely after the infection. They run the malware sample in the sandbox to observe the behavior and generate a revert operation for each action that modifies the system state. However, the limitation of such an approach is unable to deal with the potentially different behaviors in the sandbox and on the real hosts. In this work, we propose a system that can generate user-specific recovery procedures, without the need of any monitoring in advance. We extend the work from Paleari et al. [31] by combining information from the infected machine. We first extract the environment configuration from the infected computer and configure the same context to the sandbox virtual machine, in order to eliminate the environmental influence on the malware’s behavior. After getting the behavior from the sandbox, we combine forensic evidence to understand the exact actions that happened on the system and generate the user-specific recovery procedures. We implement a prototype based on Windows 10 and CAPE sandbox and perform an evaluation on 894 malware samples. We are able to recover 51.3% of the changes made by malware, which doubles the recovery rate compared to directly matching the sandbox result. Additionally, our experiment result also demonstrates significantly different actual behavior from the user’s machine and sandbox result. Our system design maximizes the use of information displayed in the sandbox, but the unshown behavior still leads to the biggest limitation of behavior-based recovery.