Modern JavaScript engines that power websites and even full applications on the Web are driven by the need for an increasingly fast and snappy user experience. These engines use several complex and potentially error-prone mechanisms to optimize their performance. Unsurprisingly, the inevitable complexity results in a huge attack surface and varioustypes of software vulnerabilities. On the defender's side, fuzz testing has proven to be an invaluable tool for uncovering different kinds of memory safety violations. Although it is difficult to test interpreters and JIT compilers in an automated way, recent proposals for input generation based on grammars or target-specific intermediate representations helped uncovering many software faults. However, subtle logic bugs and miscomputations that arise from optimization passes in JIT engines continue to elude state-of-the-art testing methods. While such flaws might seem unremarkable at first glance, they are often still exploitable in practice. In this paper, we propose a novel technique for effectively uncovering this class of subtle bugs during fuzzing. The key idea is to take advantage of the tight coupling between a JavaScript engine's interpreter and its corresponding JIT compiler as a domain-specific and generic bug oracle, which in turn yields a highly sensitive fault detection mechanism. We have designed and implemented a prototype of the proposed approach in a tool called JIT-Picker. In an empirical evaluation, we show that our method enables us to detect subtle software faults that prior work missed. In total, we uncovered 32 bugs that were not publicly known and received a $10.000 bug bounty from Mozilla as a reward for our contributions to JIT engine security.

The MATE (Man-At-The-End) model, in which an attacker has access to the target software and/or hardware environment to be exploited and the ability to observe and modify that environment, poses unique challenges for both defense and offense. The CheckMATE workshop focuses on exploration of both offensive and defensives techniques under this model. CheckMATE will provide a discussion forum for researchers and industrial practitioners that are exploring theorentical, practical, and emperical studies in this interesting area of security.

The growing dependence on software and the increasing complexity of such systems builds and feeds the attack surface for exploitable vulnerabilities. Security researchers put up a lot of effort to develop exploits and analyze existing exploits with the goal of staying ahead of the state-of-the-art in attacks and defenses. The urge for automated systems that operate at scale, speed and efficiency is therefore undeniable. Given their complexity and large user base, web browsers pose an attractive target. Due to various mitigation strategies, the exploitation of a browser vulnerability became a time consuming, multi-step task: creating a working exploit even from a crashing input is a resource-intensive task that can take a substantial amount of time to complete. In many cases, the input, which triggers a vulnerability follows a crashing path but does not enter an exploitable state.

Many modern defenses rely on address space layout randomization (ASLR) to efficiently hide security-sensitive metadata in the address space. Absent implementation flaws, an attacker can only bypass such defenses by repeatedly probing the address space for mapped (security-sensitive) regions, incurring a noisy application crash on any wrong guess. Recent work shows that modern applications contain idioms that allow the construction of crash-resistant code primitives, allowing an attacker to efficiently probe the address space without causing any visible crash. In this paper, we classify different crash-resistant primitives and show that this problem is much more prominent than previously assumed. More specifically, we show that rather than relying on labor-intensive source code inspection to find a few "hidden" application-specific primitives, an attacker can find such primitives semi-automatically, on many classes of real-world programs, at the binary level. To support our claims, we develop methods to locate such primitives in real-world binaries. We successfully identified 29 new potential primitives and constructed proof-of-concept exploits for four of them.