Post History

Why does a lack of object encapsulation constitute a security breach?

In the current version of OpenJDK's [JEP 401: Value Classes and Objects (Preview)](https://openjdk.org/jeps/401), it is said that value classes can leak data stored in their fields, and that this is potentially a security concern. Quoting the two parts: 

> - The ability to compare value objects' fields means that a value object's private data is a little more exposed than it might be in an identity object: someone who wants to determine a value object's field values can (with sufficient time and access) guess at those values, create a new class instance wrapping their guess, and use == to test whether the guess was correct.

> - System.identityHashCode: The "identity hash code" of a value object is computed by combining the hash codes of the value object's fields. The default implementation of Object.hashCode continues to return the same value as identityHashCode. (Note that, like ==, this hash code exposes information about a value object's private fields that might otherwise be hidden by an identity object. Developers should be cautious about storing sensitive secrets in value object fields.)

Why is this relevant? If an application is running untrusted code, it is already compromised, at least to a certain degree. The [Security Manager is deprecated for removal](https://openjdk.org/jeps/411), because it's been deemed unfit for defending an application or system (IDEs still use it for running plugins), with the verdict that untrusted code should not be executed as part of the same process in the first place. If untrusted code is run nonetheless, it should be done as a separate process, since OS-level protections are more robust. That means no Java objects are shared between the processes, as they don't share the same memory space, so encapsulation has no effect. The conclusion then, is that this is only of concern when some code is running in the same process that uses these Java objects. 

When [JEP draft: Integrity by Default](https://openjdk.org/jeps/8305968) and other related JEPs speak of safety and security, it is more in the sense that an application cannot crash or invoke undefined behaviour (not the idea of UB in C++, etc). However, that doesn't seem the be the case with JEP 401, which describes two cases of collecting restricted data.

Even when _Integrity by Default_ does speak about security;

> - Security — Encapsulation is essential for any kind of robust security. Suppose, e.g., that a class in the JDK restricts a sensitive operation:
>
>   if (isAuthorized())
    doSensitiveOperation();
>
>   The restriction is robust only if we can guarantee that doSensitiveOperation() is only ever invoked after a successful isAuthorized() check. If we declare doSensitiveOperation() as private in its declaring class then we know that no code in any other class can directly invoke that method; in other words, the declaring class has integrity with respect to that method. Code reviewers thus need only ensure that all invocations of the method within the declaring class are preceded by an isAuthorized() check; they can ignore all the other code in the program.

– it is about a programming error issue, not an attacker, provided untrusted Java code is not being run in the same process.

But with the Security Manager already on to be removed, the assumption must be that the warnings in JEP 401 only apply in an environment where _trusted_ code is executed. Exploiting the leaks in 401, is an intentional decision, not a simple programmer error, so what is the threat in question?

If a framework or library developer is worried that clients can read data they stored in an object, object encapsulation would already not work, since the client developer can get a reference to the Java object in native code, then use this to inspect the data at the address where the fields are stored. That is provided the running Java code has access to call into native code, which is something any trusted code can give itself.

If any sort of executing malicious code has access to the memory, the only safe measure is to [not store the data in memory at all](https://stackoverflow.com/questions/29669479/are-passwords-stored-in-memory-safe). This also applies if an attacker can somehow exploit a vulnerability in a running application to execute Java bytecode. So why does it matter if a Java object leaks the values in its fields?