Erik, The fact that you have access to the objects involved (and to their contents) does not mean you already have access to the new information revealed by being able to check if a phantom reference refers to some specific object. Knowing "who uses what thing" is a lot more than just knowing "who exists" and "what are the things that exist"… Many security things leverage the fundamental difference between those sets of knowledge, and that's why we e.g. fear the effect that the emergence of quantum will likely have on on existing TLS ciphers...
I could probably come up with a "reasonable code" example that would make security or correctness assumptions based on the currently specified opaqueness of phantom references, and which one would then be able to write an exploit against if we change the specified behavior . E.g. it would currently be reasonable to make use of phantom references across APIs as forms of a weak and opaque identity handles (and opposed to WeakReference which would be a weak but non-opaque handle), and build security or correctness assumptions based on that presumed opaqueness. We could go through an exercise of actually building one of these to prove a point. But we don't need an actual example exploit or a proof that the change can lead to security or correctness issues. We just need enough of a worry that such issues can arise due to the change. What I'm pointing to is the worry, and suggesting that the change in semantics is not necessary. I could phrase the issue in reverse: "What are examples where being able to determine if a phantom reference refers to a specific object is useful?" I have a feeling that at least some of those examples would also provide us with the exploit examples you ask for ;-) — Gil. > On Apr 8, 2020, at 9:13 AM, Erik Österlund <erik.osterl...@oracle.com> wrote: > > Hi Gil, > > Do you have an example exploit, or at least the gist of it? As I already > said, any information exposed could have been just guessed (replace refersTo > with random() and brute force). So if you can create an exploit based on the > answer of refersTo, then your system is secure by chance. In other words, it > is already compromised. Or have I missed something? > > Thanks, > /Erik > >> On 8 Apr 2020, at 18:05, Gil Tene <g...@azul.com> wrote: >> >> Lifting out of response from the JIRA issue: >> >> I always worry when proposing a change to an existing invariant, and >> PhantomReference currently carries the stated and specified behavior >> of "the referent of a phantom reference is always inaccessible". >> >> I can imagine quite a few forms of gaining new information I do not otherwise >> have access to by using PhantomReference::RefersTo if it allowed me to >> examine >> the current referent of a phantom reference and test to see if it is (a) >> null or (b) a >> specific object I have a reference to. Both of those would provide me with >> information >> that is impossible for me to get according to current specifications. With >> that newly >> available information one can come up with all sorts of nice things to do... >> Think in >> terms of "side-channel" as an example of the sort of thinking black hats can >> apply >> to this new knowledge, but the potential attacks are not limited to >> side-channels. >> >> While it will be "obviously safe" to have Reference:RefersTo(obj) provide >> the same >> information that (Reference.get() == obj) would, providing more information >> than >> that would be a change to the specified behavior of Reference types, which we >> should be extra paranoid about. Since PhantomReference::get returns null by >> definition, we should remain consistent with that in >> PhantomReference::refersTo >> >>> On Apr 8, 2020, at 7:56 AM, Erik Österlund <erik.osterl...@oracle.com> >>> wrote: >>> >>> Hi Gil, >>> >>> Lifting out my reply to you from the JIRA issue: >>> >>> In terms of breaking existing logic, I am not worried. This is a new API, >>> that nobody is using yet. People that write new code that uses it, will >>> have to pay attention that they are doing the right thing. We are still not >>> exposing the phantom referent with this change. In terms of security, you >>> can only use this API to figure out what the referent is, if you already >>> have access to it. So that isn't really helpful for building exploits. What >>> it could do is allow you to check which one of N objects that you already >>> have access to is the one referred to from the PhantomReference. But in >>> terms of security, you could also have just guessed that without this API, >>> as you already have full access to the objects. Sounds like a classic case >>> of "I have an exploit. Given a compromised system... X". Or have I missed >>> something? >>> >>> Thanks, >>> /Erik >>> >>>> On 2020-04-08 16:25, Gil Tene wrote: >>>> A very welcome change overall. However, I have concerns about >>>> the semantic change to the PhantomReference specification. I propose >>>> that PhantomReference semantics remain unchanged, and that >>>> PhantomReference:RefersTo should return true only for null. >>>> >>>> See more in comment at >>>> https://bugs.openjdk.java.net/browse/JDK-8188055?focusedCommentId=14329319&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-14329319 >>>> >>>>> On Apr 7, 2020, at 5:25 PM, Kim Barrett <kim.barr...@oracle.com> wrote: >>>>> >>>>> [Note review on both core-libs and hotspot-gc-dev lists; try not to lose >>>>> either when replying.] >>>>> >>>>> Please review a new function: java.lang.ref.Reference.refersTo. >>>>> >>>>> This function is needed to test the referent of a Reference object >>>>> without artificially extending the lifetime of the referent object, as >>>>> may happen when calling Reference.get. Some garbage collectors >>>>> require extending the lifetime of a weak referent when accessed, in >>>>> order to maintain collector invariants. Lifetime extension may occur >>>>> with any collector when the Reference is a SoftReference, as calling >>>>> get indicates recent access. This new function also allows testing >>>>> the referent of a PhantomReference, which can't be accessed by calling >>>>> get. >>>>> >>>>> The new function uses a native method whose implementation is in the >>>>> VM so it can use the Access API. It is the intent that this function >>>>> will be intrinsified by optimizing compilers like C2 or graal, but >>>>> that hasn't been implemented yet. Bear that in mind before rushing >>>>> off to change existing uses of Reference.get. >>>>> >>>>> CR: >>>>> https://bugs.openjdk.java.net/browse/JDK-8188055 >>>>> https://bugs.openjdk.java.net/browse/JDK-8241029 (CSR) >>>>> >>>>> Webrev: >>>>> https://cr.openjdk.java.net/~kbarrett/8188055/open.04/ >>>>> >>>>> Testing: >>>>> mach5 tier1 >>>>> >>>>> Locally (linux-x64) verified the new test passes with various garbage >>>>> collectors. >>
