PoLPer

Abstract

setuid system calls enable critical functions such as user authentications and modular privileged components. Such operations must only be executed after careful validation. However, current systems do not perform rigorous checks, allowing exploitation of privileges through memory corruption vulnerabilities in privileged programs. As a solution, understanding which setuid system calls can be invoked in what context of a process allows precise enforcement of least privileges. We propose a novel comprehensive method to systematically extract and enforce least privilege of setuid system calls to prevent misuse. Our approach learns the required process contexts of setuid system calls along multiple dimensions: process hierarchy, call stack, and parameter in a process-aware way. Every setuid system call is then restricted to the per-process context by our kernel-level context enforcer. Previous approaches without process-awareness are too coarse-grained to control setuid system calls, resulting in over-privilege. Our method reduces available privileges even for identical code depending on whether it is run by a parent or a child process. We present our prototype called PoLPer which systematically discovers only required setuid system calls and effectively prevents real-world exploits targeting vulnerabilities of the setuid family of system calls in popular desktop and server software at near zero overhead. CCS CONCEPTS • Security and privacy → Systems security; Software and application security;

Phoenix: Surviving Unpatched Vulnerabilities via Accurate and Efficient Filtering of Syscall Sequences

“…3) Comparison with existing stateful solutions: In this experiment, we compare Phoenix with existing solutions that can also perform stateful inspection of system calls [21], [34], [57] (these are re-implemented as no working code is publicly available). Specifically, VtPath [21] and Mutz et al [57] both leverage the call stack between pairs of consecutive system calls (namely, virtual paths) to learn the normal behavior and detect anomalous calls, while the latter also considers system calls arguments.…”

“…Specifically, VtPath [21] and Mutz et al [57] both leverage the call stack between pairs of consecutive system calls (namely, virtual paths) to learn the normal behavior and detect anomalous calls, while the latter also considers system calls arguments. PoLPer [34] blocks anomalous system calls in the setuid family by learning the calling process hierarchy, call context, and its arguments. For a fair comparison, we evaluate them both for a purpose similar to Phoenix, i.e., blocking a particular vulnerability (blacklisting), and for their intended usage, i.e., anomaly detection (whitelisting).…”

“…Blacklisting. In this first experiment, we apply each solution to learn the exploit of each vulnerability based on the used characteristics (i.e., the malicious virtual paths for [21] and [57], the string arguments for [57], and the malicious setuid calls context, hierarchy, and arguments for [34]). We then evaluate their effectiveness in capturing the same exploit executed again, a slightly modified exploit (detailed below) of the same vulnerability, and the normal behavior, respectively.…”

“…Our investigation shows this is due to their design choice of limiting the learning to 36 system calls (which is not sufficient to capture the exploits). Third, PoLPer [34] can only capture two out of five CVEs due to the fact that it is specifically designed to match system calls from the setuid family, which are only used by two of those exploits (the number of successfully matched setuid calls are reported between parenthesis). Moreover, like the other two works, PoLPer cannot capture the slightly modified exploit codes.…”

“…Comparison with Existing Stateful Solutions in terms of Response Time. We compare the overhead of VtPath [21], Mutz et al [57], and PoLPer [34] with that of our solution.…”