Present but Unreachable: Reducing Persistentlatent Secrets in HotSpot JVM

Abstract

Applications that manage sensitive secrets, including cryptographic keys, are typically engineered to overwrite the secrets in memory once they're no longer necessary, offering an important defense against forensic attacks against the computer. In a modern garbagecollected memory system, however, live objects will be copied and compacted into new memory pages, with the user program being unable to reach and zero out obsolete copies in old memory pages that have not yet been reused. This paper considers this problem in the HotSpot JVM, the default JVM used by the Oracle and OpenJDK Java platforms. We analyze the SerialGC and Garbage First Garbage Collector (G1GC) implementations, showing that sensitive data such as TLS keys are easily extracted from the garbage. To mitigate this issue, we implemented techniques to sanitize older heap pages and we measure the performance impactsometimes good, sometimes unacceptable. We also discuss how future garbage collectors might be designed from scratch with efficient heap sanitation in mind.

Removing Secrets from Android's TLS

“…To the best of our knowledge, there is no in-depth study of cryptographic secrets of TLS on Android, but, for other platforms, there have recently been several studies for extracting TLS secrets from a virtual machine [31], Windows OS [15], and Oracle's Java HotSpot JVM [22]. The first two studies look at extracting master secrets; the latter focuses on general data reconstruction from a garbage-collected runtime system.…”

“…Taubmann et al [31] provide a technique to extract master secrets at runtime using virtual machine introspection techniques, and Kambic [15] provides a similar analysis of Windows systems. Pridgen et al [22] investigate Java TLS implementations, finding key material remaining in memory as a consequence of the JVM's garbage collector. A copying garbage collector may leave multiple dead copies of a key behind in memory that are not "reachable" as live data, yet are still vulnerable to forensic extraction.…”

App-Agnostic Post-Execution Semantic Analysis of Android In-Memory Forensics Artifacts

“…Using the Android Dalvik virtual machine as a use case, this study demonstrated that it is possible to replicate the features of the Android framework to find instances of structured classes and fields from the process memory dump. This line of argument was further explored by [2,32,34,35,42] to recover and reconstruct in-memory forensics artifacts from different runtime environments that are built using different memory management algorithms. [32] extended the work of [7] to cover a newer version of Android DVM.…”

“…An object is allocated at the top of an available region as long as its size does not exceed the region's end. Prior work [2,32,34,35,42] has involved developing techniques for deconstructing a process memory image and reconstructing the memory allocation metadata, dumping the heap objects, and decoding the objects. However, the limitation of these approaches is the developed tools aggregate the allocation, but do not establish the relationships between allocated objects, and therefore they cannot be used to determine the origin or scope within which an object exists at runtime.…”

Total Recall: Persistence of Passwords in Android

“…Researchers have developed many solutions to address this. Chow et al handle this by secure deallocation [14], Pridgen et al aim at reducing encryption keys retained in the Java heap for desktops and servers [49], Dunn et al use ephemeral channels where data will be securely erased after a session finishes [18], and Lee and Wallach study the retention of TLS secrets in Android memory [34]. Different from existing work, our paper focuses on the study of password retention, and proposes effective fixes to address this problem.…”