Hardening Java's Access Control by Abolishing Implicit Privilege Elevation
Philipp Holzinger, Ben Hermann, Johannes Lerch, Eric Bodden, Mira Mezini
摘要
While the Java runtime is installed on billions of devices and servers worldwide, it remains a primary attack vector for online criminals. As recent studies show, the majority of all exploited Java vulnerabilities comprise incorrect or insufficient implementations of access-control checks. This paper for the first time studies the problem in depth. As we find, attacks are enabled by shortcuts that short-circuit Java's general principle of stack-based access control. These shortcuts, originally introduced for ease of use and to improve performance, cause Java to elevate the privileges of code implicitly. As we show, this creates many pitfalls for software maintenance, making it all too easy for maintainers of the runtime to introduce blatant confuseddeputy vulnerabilities even by just applying normally semanticspreserving refactorings. How can this problem be solved? Can one implement Java's access control without shortcuts, and if so, does this implementation remain usable and efficient? To answer those questions, we conducted a tool-assisted adaptation of the Java Class Library (JCL), avoiding (most) shortcuts and therefore moving to a fully explicit model of privilege elevation. As we show, the proposed changes significantly harden the JCL against attacks: they effectively hinder the introduction of new confused-deputy vulnerabilities in future library versions, and successfully restrict the capabilities of attackers when exploiting certain existing vulnerabilities. We discuss usability considerations, and through a set of large-scale experiments show that with current JVM technology such a faithful implementation of stack-based access control induces no observable performance loss. void checkMemberAccess(Class clazz, int w) if (w != Member.PUBLIC) Class stack[] = getClassContext(); / * stack depth of 4 should be the caller * of one of the methods in java.lang.Class * that invoke checkMember access. * The stack should look like: * someCaller [3] * java.lang.Class.someReflectionAPI [2] * java.lang.Class.checkMemberAccess [1] * SecurityManager.checkMemberAccess [0] * / if ((stack.length<4) || (stack[3].getClassLoader() != clazz.getClassLoader())) checkPermission(CHECK_MEMBER_ACCESS);
问问这篇 Paper
智能体会读完全文。
Lune 把这篇 Paper 索引到了每一个公式,引用它的顶会 Paper 也一样。你提问,回答直接引用原文。
它引用的顶会 Paper1
相关 Paper
- FReD: Identifying File Re-Delegation in Android System ServicesSigmund Albert Gorski III, Seaver Thorn, William Enck, Haining ChenUSENIX Security 2022
- Improving Java Deserialization Gadget Chain Mining via Overriding-Guided Object GenerationSicong Cao, Xiaobing Sun, Xiaoxue Wu, Lili Bo 等ICSE 2023 · 被引用 24 次
- Automatic Policy Synthesis and Enforcement for Protecting Untrusted DeserializationQuan Zhang, Yiwen Xu, Zijing Yin, Chijin Zhou 等NDSS 2024
- Mind Your Keys? A Security Evaluation of Java KeystoresRiccardo Focardi, Francesco Palmarini, Marco Squarcina, Graham Steel 等NDSS 2018 · 被引用 9 次
- Precise and Effective Gadget Chain Mining through Deserialization Guided Call Graph ConstructionYiheng Zhang, Ming Wen, Shunjie Liu, Dongjie He 等USENIX Security 2025
