Abstract

CPU time-multiplexing is a common practice in multi-tenant systems to improve system utilization. However, the sharing of CPU and a single system clock makes it difficult for programs to accurately measure the length of an operation. Since a program is not always running in a time-sharing system but the system clock always ad- vances, time perceived by one program could be dilated as it may include the run time of another program. Applications employing time-based resource management face a potential security threat of time manipulation.

HotSpot, a widely used Java virtual machine (JVM), relies on timing garbage collections to infer an appropriate heap size. In this paper, we present a new active side-channel attack that exploits time dilation to break the heap sizing algorithm in parallel scavenge, the default garbage collector in JDK 8. We demonstrate that a deliberate attack targeting a specific type of GC is able to crash a Java program with out-of-memory errors, cause excessive garbage collection, and leads to signifi- cant memory waste due to a bloated heap.

Attack

In this paper, we demonstrate that a deliberate attacker can exploit the timing channel to break the heap management of a Java program. Most Java heap management schemes use measured GC time, which is based on wall-clock time, to determine an appropriate heap size. The attack interferes with GC timing to deceive the heap sizing algorithm such that the JVM mistakenly configures an insufficient or excessive heap.

Evaluation

Results show that attacking the pause time target causes a benchmark to spend as much as 60% more time in GC; attacking the through- put target leads to a bloated JVM which uses up to four times more memory. Furthermore, we are able to create an attack that consistently causes a benchmark, which never fails when not attacked, to crash due to OOM errors. Finally, we demonstrate the feasibility of launching a realistic attack on heap management. We leverage eBPF to trace JVM execution and deliberately affect GC timing by slowing down GC threads. All attacks except the one crashes the JVM can be reproduced on real Java programs from the SPECjvm2008 and DaCapo benchmarks.