Present but Unreachable: Reducing Persistentlatent Secrets in HotSpot JVM
Present but Unreachable: Reducing Persistentlatent Secrets in HotSpot JVM
复制标题
存在但无法访问：减少 HotSpot JVM 中的持久潜在秘密
DOI：
--
复制
发表时间：
2017
期刊：
影响因子：
--
通讯作者：
D. Wallach
中科院分区：
文献类型：
--
作者：
Adam Pridgen;S. Garfinkel;D. Wallach
使用热点Java虚拟机（JVM）的两个最受欢迎的Java平台是Oracle和OpenJDK。为了充分消毒对象中的敏感数据并防止内存披露攻击，即可以读取包含Java对象的过程的记忆的攻击者。即使对象是垃圾，即使对象不可触及，它们也不是在多个堆中开发人员希望明确消毒关键数据，例如封闭网络连接的加密密钥，没有用于此活动的手动机制，因为数据不超出开发人员，因此可以从垃圾中提取此敏感数据。在本文中，我们可以使用Oracle的TLS 1.2实现从Java堆中恢复多达40％的TLS加密密钥。在最坏情况下，性能高达50％。
The two most popular Java platforms that use the HotSpot Java Virtual Machine (JVM) are Oracle and OpenJDK. The HotSpot JVM automatically manages application memory for the developer using generational garbage collection (GC). Unfortunately, this managed memory fails to give developers the power to adequately sanitize sensitive data in objects and defend against memory disclosure attacks, i.e., attackers who can read the memory of a process containing Java objects. This problem stems from two design flaws in the GC tasks. First, the generational GC allows more than one copy of an object to exist in multiple heaps, even though they are unreachable. Second, when objects become garbage, they’re not sanitized or zeroed by the garbage collector; they survive until the memory is reused for a new object. Even if a developer wants to explicitly sanitize critical data, such as cryptographic keys for closed network connections, there are no manual mechanisms for this activity because the data is out of the developers reach. Consequently, this sensitive data can be extracted from garbage after applying object reconstruction techniques to the heap. For this paper, we show that up to 40% of the observed TLS encryption keys can be recovered from a Java heap using Oracle’s TLS 1.2 implementation. This paper also shows how modest GC changes reduce the amount of recoverable data, albeit with performance overheads as high as 50% in the worst case.